Deconstructing IPStar

This started out as a project to address peculiarities of the IPStar satellite modem's web interface. The interface only works in Internet Explorer. My ISP subsequently came up with a solution that works for me, leaving me with a logging script that was partially broken by a subsequent update of the modem's firmware.

The first step was to contact IPStar. When that went unanswered, I took a look at the page source of the iCON modem's interface file: xwebgateway.cgi (the link will work only on networks with an ipstar modem on the default address).

Reproducing the whole page would probably violate copyright, but one line caught my eye:
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">.
FrontPage was a consumer-grade HTML editor. That it was evidently employed in development of the interface gives no cause for confidence in the professionalism of the developers.

Next, I monitored the network with Wireshark. I'm new to the software, so I can't vouch for the adequacy of my efforts. Extracting relevant streams yielded these captures.

For IE, I haven't included files of TCP streams GETing individual graphics. Firefox fails pretty quickly, so I've followed every stream.

My first aim is to log data from the modem. It's been decades since I did any programming, so this will take a while.

18 May 2010
I've managed to log data from the first tab of the interface using Python. The script is now at, or at least near, final form and reasonably stable. The development version was created under Windows. I've created a Linux version, to run on an old laptop. Anyone wanting to use either will need to edit the paths, to suit their system setup. Python 2.6 is also required.

The script creates individual log files for each hour. To avoid problems caused by Daylight Saving and time zones, the file names are based on UTC (GMT).

On my Windows system, the log files have blank lines between each row of data. That seems to be a peculiarity of the Windows implementation of Python's csv module.

Some of the data logged is puzzling. For example: in the hour between 0700 and 0800 Australian Eastern Standard Time today, BytesReceived data in the log shows 3,282,192,069 at the beginning and 3,640,830,542 at the end, a difference of 358,638,473. If that is truly a measure of the number of bytes received, then about 300 megabytes came through in the time that the modem was messaging - approximately 4 minutes.

Changes in the BytesReceived data, however, indicate some activity while the modem was unresponsive. That complicates matters, but my download manager and peer-to-peer client show no such downloads. Even if Bluemaxx was providing the 128 kilobits per second (shaped) for which I'm paying, 300 megabytes in an hour is unlikely, even without the fragmentary service revealed in the log.

The TxRate and RxRate data are similarly confusing. They differ from the speeds reported by Internet Explorer. The BytesReceived figure, however, changes at rates consistent with variations in RxRate. I'll just have to figure out how Internet Explorer calculates what it displays from what the modem sends.

RXSignalStrength and EsN0 are pretty straightforward. They are apparently what they say: measures of the strength of the received signal and signal to noise ratio.

29 May 2010
Perusing the javascript returned by xwebgateway.cgi, it seems to make use of “BytesRecievedFiltered” and “Nettgain” status data items. I've amended the scripts to log those items. No idea what I'm doing, but I'll have the data if I figure out what it's used for.