Results 1 to 1 of 1

Thread: wfemu v0.1b (beta release)

  1. #1

    Join Date
    Sep 2009
    Posts
    4,389
    Thanks
    11,127
    Thanked 3,881 Times in 2,188 Posts
    Rep Power
    48

    Default wfemu v0.1b (beta release)

    Credit goes to ps2chiper for this file.

    This Linux app acts like a "Weather Forecastor"
    It will allow you to use your Viewsat with normal SSSP clients by
    converting the "Weather Forecastor" format into a more usable "Captiveworks"
    SSSP format.

    This is compiled for i386 basic CPU type, and will run on any Intel-like
    Linux system. With x86_64 you will probably need the 32-bit compatibility
    packages installed, however you do that on your distro.

    Usage:
    ./wfemu <serial device>

    If no serial device is given, the default is /dev/ttyS0
    You must provide the entire path to the device (include /dev/ always)
    You need to use a "null modem" cable between the Viewsat and your Linux box.

    Upon launch, it will report which PTY device (fake serial port) it has
    created for use by your SSSP client software. Configure your SSSP client
    to use that port instead of a normal serial device, and make sure it also
    supports normal "Captiveworks" type SSSP format, as that is what this app
    outputs. Of course you also need to configure your SSSP client to give
    it some card sharing server(s) or not much will happen.

    This has only been tested with rq-sssp-client v1.03, but there should be
    no reason any other SSSP client shouldn't work as well, as long as you can
    get them to use a specific device. Some may require symlinks or fiddling
    to trick them into opening the PTY device rather than a more standard one.
    (hint: "sudo ln -s /dev/pts/8 /dev/ttyS5" and then set your SSSP client to
    use /dev/ttyS5 or "COM6" or such, depending on what it expects)

    Note the menus on the Viewsat will show normal information as expected, and
    any networking changes are accepted but silently ignored. They don't matter
    anyway and you should be configuring your Linux box as normal, so it can get
    to the servers you use in your SSSP client.

    You must run this app and the SSSP client app on the same Linux box, in case
    you thought you didn't. The PTY device is only available locally. So just
    use "screen" or pop another terminal/console window and be sure to run wfemu
    first (since it dynamically creates the PTY device) and the SSSP client next.
    Also if you stop wfemu make sure to quit the SSSP client or it will camp out
    on the previous PTY device and the next time you run wfemu it will pick the
    next available one (and they won't be talking to each other anymore).

    Proper Setup Procedure (must follow this EXACTLY or it won't work):
    1) IF YOU HAVE AN ULTRA: Obtain these three bins and put them on USB stick:
    VIEWSAT_ULTRA_V0146.PGM ("factory" bin)
    PFTAUSW-100322U.PGM (the "322" bin)
    PFTAUSW-100320U.PGM (the "320" bin)
    IF YOU HAVE AN ULTRA LITE: Same as above just the ones for the UL instead.
    2) Connect the USB stick to the front USB port, fire up the STB
    3) Go to menu "System Information" -> "Receiver Upgrade" -> "USB"
    4) Navigate to the factory bin, select it, install
    5) Wait for it to finish and reboot. Sometimes it will sit there with 0000
    on the front panel, press the remote power button if so (it's in soft-off)
    6) Go to menu "System Information" -> "Factory Default", enter PIN, say yes
    7) Repeat step 3-5 but with the "322" bin instead
    8) Connect serial. Fire up wfemu. Double check /dev/pts/ path and set it in
    your SSSP client. Fire up the SSSP client. (use "screen" or two terms)
    9) Go to menu "Installation" -> "Serial Setup" -> "Network S/W Upgrade" ->
    "Network S/W Version" and verify it comes back with "wfemu v0.1b"
    This verifies your serial connection and that wfemu is ready.
    10) Observe the wfemu output and make sure it has sent the "CaID Map" packet
    (it will continually do this every 5 seconds or so, and will also do it
    following a "Connection Control" command from the VS)
    11) Once you have seen the "Connection Control" packet from the VS and a few
    of the "CaID Map" responses, leave wfemu running and continue at step 12
    12) Repeat step 3-5 but with the "320" bin this time (yes, downgrade)
    The "322" bin doesn't work with the real WF either so this is required.
    The "320" bin doesn't accept the "CaID Map" packet which is why you must
    install "322", feed it the "CaID Map", and then downgrade to "320"
    13) Once you are back up with "320", set up your satellites and do an autoscan
    14) Go to a channel you know your IKS provider handles, watch TV.

    Basically if you don't feed the CaID Map to "322" then downgrade to "320" then
    do your fresh channel scan, the VS will not mark the channels as needing to
    send the ECM to wfemu, so you will be wondering why it never does. If the VS
    has seen the "CaID Map" it remembers and applies the "send ECM" flag for each
    channel it finds using that CaID, during the next autoscan. It's pretty dumb
    but you have to do all this to make the real WF work too, so blame the WF crew
    and not us. We tried to find shorter/smarter ways to do it and nothing else
    worked.

    Enjoy!
    Attached Files Attached Files
    To become a VIP Member the cost is $6.00 for 3 month. Please Help to support the Site

    Warning:
    Information used here is for Educational Discussion Only. I do not use and/or condone any use of third party software to hack encryption communication between any providers.

  2. The Following User Says Thank You to irocjuno For This Useful Post:

    redneckyankee (04-26-2010)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •