I would have put a disclaimer here. But if you break your iBurst modem you have only yourself to blame, so no disclaimer. This was posted on the MyADSL forums, and people wanted to keep it secret, for fear of dimwits breaking their modems. Realistically, what difference is it going to make?

It is possible to telnet into you iBurst UT-D. Its quite simple:

* Connect UT-D via ethernet cable
* Set your ethernet connections’ IP to 192.168.250.5
You can also do this by simply adding an additional IP under the “Advanced Tab” under TCP/IP properties, if you don’t feel like changing your main IP.
* Open a command prompt (Start->Run->cmd.exe) Then type:

telnet 192.168.250.10 1234


If everything went well you should see a prompt from the UTD. If your networking is *incorrectly* configured, you will see a message saying “Connecting To 192.168.250.10… and it will appear to freeze there. Check everything again, if that’s the case.

!At the UTD prompt:
* Type “rfScan debug 2”, without the quotes. Hit enter.
* You will be presented with the base station # and the signal strength in dB and the distance and load of the BS.
* Once you are done type “rfScan debug 0”
* Kill the telnet session.

You should technically just be able to reboot the UTD too, to disable the debug mode.

So, recently Vox Telecom released their Viral Marketing based Voice over IP service late this year.

Their standard VOIP phone is a nifty device, based on the Thomson SpeedTouch 7G device, incorporating a DECT Phone, Wireless Router (Broadcom based) and also an ADSL modem.

My problem is – I have a neat Linux-based ADSL setup already, and didn’t really want to use the VOX phone as my ADSL to Ethernet Bridge (I have my reasons).

After some reverse engineering, it turns out, that using the CLI interface of the router, it can be convinced to not use it’s own ADSL connection as the upstream towards the VOX sip service. Instead it can be forced to use the “LAN” ethernet ports and by simply doing a bit of route adding, and forcing the voice service to use the LAN interface, the phone can happily work with Vox’s service across some other internet gateway.

Caveat Emptor: Of course, you have to be sure that your Internet gateway supports the proper QoS, otherwise the VOX service will suffer. And please, don’t call VOX’s support if you’re having problems with this kinda config. It is (and rightfully so) an unsupported configuration.

You will need to do all the NAT Traversal bits, and cleverness for this to work too, which is beyond the capability of your regular user – so, again. Consider it “unsupported”.

That said it still works…

Here’s the configuration

ip ipadd intf=LocalNetwork addr=192.168.0.201
ip rtadd dst=0.0.0.0 gateway=192.168.0.1 intf=LocalNetwork
dns client dnsadd addr=192.168.0.1
dns server config WANDownSpoofing=disabled
dns server route add dns=192.168.0.1 intf=LocalNetwork
voice config intf=LocalNetwork
system config defaultconnection=LocalNetwork
config save filename=user


A series of tweaks for the Win32 USB drivers of the IPWireless modem, and some more tweaks for the “Wireless Broadband Dialler”

Getting rid of the debug overhead in the drivers:

The USB drivers log a lot of useless information about the USB protocol used to communicate with the modem, using the win32 DbgPrint kernel function-call. This causes some serious overhead, and can amount to quite a bit of extra CPU cycles when running at high speeds. This “spam” is quite obvious when you run a tool such as DebugView. (Try it, you’ll note the spam, and remember to ‘Capture Kernel Events (Ctrl+K)’) In addition the kernel has to buffer any DbgPrint data in an internal buffer until it overflows, or an application such as DebugView reads it off the stack. This incurs even more ring 0 overhead on systems using the USB driver.

The DbgPrint spam is controlled via a registry entry in the ipw_*.inf files… It’s easier, to just find the keys, after installation and change the debug flags, than reinstalling the drivers with modified .inf files.

By disabling the debug information and the extra overhead when talking to the USB device, I’ve managed to shave around 5-8ms off my ping times. (A completely subjective measurement) [YMMV] <— Under profiling conditions, with a kernel debugger the call overhead per USB poll dropped from 230 cycles to 89 cycles which is a considerable saving in CPU cycles wasted. (This was an objective measurement).

I find it quite insane that a company such as MCCI can distribute drivers for production release with full debugging turned on.

Hopefully, once I patch the drivers this may drop to around 3-4% levels since there is still considerable overhead in checking the debug flags.

In the meantime, to at least reduce the syscall overhead when using the drivers, the following can be done:

_Warning, the StandardDisclaimer applies when attempting any of the following:_

Disabling the debug information (Win2000,WinXP):

*Fire up regedit.exe
*Do a search for the string “~MCCIUSB_~DebugLevel” by pressing Ctrl+F (enter it without the quotes)
*Once you’ve found the value (the default will be 0xffffffff), change it by double clicking on it.
*Change the value to 0 (decimal, or hexadicimal)
*Click ok.
*Press F3 to find the next occurrence of “~MCCIUSB_~DebugLevel” and keep on changing the values to 0.
*Once there are no more entries found, reboot your PC.

Getting the dialer to print more information

The dialler application, has a few registry entries to show more “debug” information in it’s window. This kind of information is actually useful, and has very little overhead, since the debug info is only printed during the connection establishment phase. If you’re like me and want to see what your modem is doing, then turn on the debugging for the dialler as described below.

To turn on full debugging for the dialler application:

*Fire up regedit.exe
*Navigate to HKEY_LOCAL_MACHINESOFTWAREIPWireless Inc.IPWireless PC Software
*Right click on “IPWireless PC Software” in the tree, and on the popup menu select New->Key
*Type in “Debug” (without the quotes) and hit enter, to create a new Key.
*Now, left click on HKEY_LOCAL_MACHINESOFTWAREIPWireless Inc.IPWireless PC SoftwareDebug in the tree.

__theloop__
*Right click in the blank area (NOT in the tree) and click on New->String Value
*Enter ATCMD, and hit enter
*Double click the ATCMD entry and type in “Enable” (without the quotes)

*Repeat starting at __theloop__ for the following values:
**ATRES
**ATRESP
**~RasTrace

Now, when you use the “Wireless Broadband Modem Dialler” application, some more debugging information will be shown in the “ISP” window.

Getting the dialler to retry more than 5 times after disconnect:

The “Wireless Broadband Modem Dialler” has an option on the “ISP” tab to “Reconnect if line dropped”
When you turn this checkbox on, the dialler will retry for a maximum amount of 5 times to reconnect to the Sentech network.

This is pretty useless, since we all know: _When it goes down, it goes down for a while_
To increase the number of attempts that the dialler will use when attempting to redial do the following:

*Fire up regedit.exe
*Navigate to HKEY_LOCAL_MACHINESOFTWAREIPWireless Inc.IPWireless PC Software
*Find the entry named RECONNECT_ATTEMPTS on the right-hand side.
*Double click the RECONNECT_ATTEMPTS entry, and change the value to 10000
*This will cause the dialler to retry 65536 times when the line gets disconnected.