Sunday, November 25, 2007
Saturday, November 17, 2007
In my recent trip to San Jose (Sep/Oct), I was waxing ebulliently about VoIP ATA adapters to my friend Ramesh Panuganty when the topic of putting the VoIP phone in another room came up. These ATA adapters (Linksys PAP2T, Grandstream Handytone 503 etc) come with a regular ethernet port. Both our homes don't have a wired LAN configured, so this was a problem. When we looked at wireless bridging options, we found the solutions to be quite expensive and supported only one port (See Linksys WET54G for example, 90 bucks for 1 ethernet port!).
Compare that to the price of Linksys WRT54GL for only $64 at the same website. You can get other brands like Netgear or Buffalo for even cheaper. So the question of whether you can use these devices for bridging to LAN segments came up. A bit of googling and reading confirmed that this is called "Client-Bridge" mode and is supported by all of the open source firmware options for the WRT54G.
Incidentally, I was feeling a dire need for a ethernet hub to debug the SIP registration problems (no low end home networking switch seems to support span). Wouldn't it be nice to run tcpdump right on the WRT54G for this purpose? So it was time to dust out my little box and play with it. It turned out to be surprisingly simple. I initially downloaded the DD-WRT version which seemed to be more popular. Following the advice in the wiki pages, I first downloaded flashed the mini generic version of v23 SP2. Without even checking it out immediately upgraded to the WRT54G "voip" version (no good reason, the "voip" just sounded attractive :-). Wireless bridging worked beautifully. Just configured my SSID and my WEP key and everything worked flawlessly.
There was one small problem. After wasting half an hour on it I realized that my 4MB box had no free space to install tcpdump. So I switched to the mini WRT54G version which gave me enough space. After wasting another half an hour on it because I didn't configure the IP router and DNS correctly, I managed to install tcpdump package using ipkg. Only, tcpdump didn't work. I always got a bus error. Okay, what next?
Fortunately I had already downloaded X-WRT image bundled with the OpenWRT "White Russian" firmware. I download the X-WRT because it promised a better Web UI and I didn't really want to muck around with the CLI trying to configure the box. This one worked great. The original settings from the DD-WRT firmware worked fine for the OpenWRT firmware too. I was able to get tcpdump working. OpenWRT is more Linux/Debian like (more software options and no weird Microsoft like SP2 naming for the image). So everything is hunky-dory now :-).
Friday, November 16, 2007
So it turned out that the BSNL Huawei modem had a messed up NAT. Response to the outgoing registration packets from the Linksys were coming to the PC! So I rebooted the modem but that didn't help either. I just retyped my password in the Linksys and that did the trick. I am reasonably confident that it was NAT translation issue; so BSNL is not at fault on this occasion. At least not since yesterday.
Thursday, November 15, 2007
Some one commented to my previous post that BSNL is blocking specific range of IP addresses which may very well be true. I tried logging out my PPPoE session a couple of times to get a new IP Address. It didn't seem to help, I didn't have the patience to keep trying. But really, this sucks.
Saturday, November 03, 2007
On a related note, it's pretty painful to debug what exactly going on with these headless devices. This is not just a Grandstream device issue. I face the same issue with the Linksys PAP2. Grandstream did provide logging to an external server which helped me quite a bit. However, I need either a hub or a low-end switch that can do span. I do have a Linksys WRT54G, I can put openwrt firmware and do tcpdump right on the box. That's a project for another day.
Incidentally the Grandstream box appears to be running Linux though Grandstream website makes no mention of it. I'd love to get a shell prompt on it. It's a very small and sleek device.
Suddenly, BSNL appears to blocking SIP ports. The clue is your device fails to register with the SIP server. For all I know this may be a regular thing because the problem keeps popping up for me once in a while in the short time I've used the device. I always thought it's a device issue but today I decided to dig deeper and here's what I found. Outgoing port 5060 (the SIP port) is definitely blocked for both tcp and udp (I test with an external BSD box where I have ssh access). So I found another VoIP provider called Callcentric which conveniently provides SIP port 5080 and SIP registration appears to go through fine.
The summary above looks simple but I had to go through a lot of trial and error. At first it appeared that ports 5061 through port 5080 were also blocked but right now just after I started posting this I was successfully able to get through to callcentric. I am using an excellent utility called sipsak to help me with debugging this. Any way, if BSNL is indeed blocking SIP calls that's really bad. VoIP is legal in India for individual users and BSNL has no right to do this. Ganesan