Scammer
Banned
C & P
thanks to jrandal
wfemu v0.23mex
--------------
("mex" version with experimental CaID-Map support for SKY mexico)
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.04, 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. This app does not do any actual
network socket connection, it is only a bridge between the Viewsat WF format
and the Captiveworks SSSP format (your SSSP client is what connects to the
server). This also has nothing to do with the server(s) the real WF would
connect to, it just allows you to use the WF-enabled STB firmware to do the
same thing most other generic SSSP-enabled receivers can do.
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 with CTRL-C, it will automatically locate and kill the
SSSP client (or whatever is on the other end of the PTY), so no more worries
about it camping out on the device for the next launch of wfemu.
You do still need to manually fire up the SSSP client when you start wfemu
again - and wfemu will complain rather loudly if nothing is picking up the
other end of the PTY, to remind you.
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!
C & P
By jrandal
View attachment wfemu-0.23mex.zip
thanks to jrandal
wfemu v0.23mex
--------------
("mex" version with experimental CaID-Map support for SKY mexico)
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.04, 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. This app does not do any actual
network socket connection, it is only a bridge between the Viewsat WF format
and the Captiveworks SSSP format (your SSSP client is what connects to the
server). This also has nothing to do with the server(s) the real WF would
connect to, it just allows you to use the WF-enabled STB firmware to do the
same thing most other generic SSSP-enabled receivers can do.
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 with CTRL-C, it will automatically locate and kill the
SSSP client (or whatever is on the other end of the PTY), so no more worries
about it camping out on the device for the next launch of wfemu.
You do still need to manually fire up the SSSP client when you start wfemu
again - and wfemu will complain rather loudly if nothing is picking up the
other end of the PTY, to remind you.
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!
C & P
By jrandal
View attachment wfemu-0.23mex.zip