I have replaced it with an HTC Desire.  It has a lovely big touch screen, which is a joy to use (a relief after having had very bad experiences with an LG Viewty), has built-in GPS, and synchronises with Outlook via HTC Sync like a dream.  It has enabled me to ditch my HP iPaq, which was relatively large, had battery life of only a few hours, and needed a separate GPS receiver (oh, and a separate phone if you wanted to make calls).

All in all I’m very happy with the new phone.  It runs on the Android operating system; I had heard a lot of good things about Android, and a lot of bad things about Windows Mobile 7, which probably influenced my decision.  I probably would have chosen the Microsoft route otherwise.

However, after upgrading to Android 2.2 (known as Froyo) the HTC Desire stopped sending MMS messages (though to be honest, I don’t know that this didn’t happen before the upgrade).

Every time I tried, I would receive one of the following errors, and the message would sit in my outbox:

Generic network failure
Message format corrupt

After a long investigation and a lot of hunting on Google (which led me down the red-herring route of setting up additional APNs), I discovered the problem: the default messaging app has issues sending MMS messages to contacts with spaces in the phone number.  For example, the app would send an MMS just fine to 07712123456, but would fail if the number was entered as 07712 123456 or +44 7712 123456.  The latter format is the one I favour, for both readability and functionality when dialling from abroad.

The problem is compounded because (for UK regional settings) Outlook forces a space into the number straight after the +44 country code and there’s no way to avoid it – and this gets transferred to the phone when it syncs.

I have found two solutions to this:

1. Reformat all your contact numbers to remove country codes and spaces
2. Download and use Handcent for all outgoing MMS messages

The first solution is a pain the backside because you need to remember the country code when abroad and dialing UK numbers (or when dialing foreign numbers from the UK), and the second solution is less than perfect because, while Handcent thankfully integrates with Android’s Share menu, it is not as polished and easy to use as the built-in messaging app.

As a possible third solution you could probably add an additional number to each contact you’re likely to want to send MMS messages to; this number would be the same as their mobile number, but formatted with no spaces.  If you sync with Outlook you’d also need to omit country codes (since Outlook will force a space after the country code).

I’m currently using solution #2, mainly because I rarely send MMS messages, so don’t want to go to too much effort – but I do want it to work on those rare occassions.

Yesterday I made the decision (read: mistake) to update my Netgear DG834G router (hardware v4, firmware v5.01.09) to firmware v5.01.14 – and, as is the way with these things, it brought trouble.  After the upgrade I couldn’t reach www.nikrivers.com from the LAN side of the router.

The problem is caused by the way the router handles traffic coming from an internal IP address and destined for the WAN (i.e. external) IP address.  In this situation it requires that the router first transfers the traffic from the internal network to the external network, and then immediately passes it back whilst applying any firewall or routing rules that are relevant to incoming external traffic.

This behaviour is called ‘NAT loopback’, and it seems the vast majority of routers built for the home market have this ability turned off, or do not have the ability at all.  It can be a big problem if you host a website and wish to access that same website using its domain name.  The domain name will resolve to the WAN IP address of your router, and any traffic headed there (such as an HTTP GET request on port 80) from the internal network will be ignored by the router.

There are a few ways to solve this, but none of them are ideal.

1. Use the server name instead of the domain name to access your website
2. Modify the list of known network hosts on each client to point your domain name straight to the server in question.
3. Run your own DNS server, using a view to return the server’s local IP address to requests for your domain name originating from your network.

Of course, the situation gets more complex if you’re also using your router to send TCP traffic on port 80 to your webserver and UDP traffic on port 8668 to a game server.

The solution is to get NAT loopback working on your router.  With some routers, such as the Touchspeed 535 as provided by Be Broadband, this feature can be enabled using a simple CLI command.  For other routers, such as the Netgear DG834G, it’s not quite so easy.

For the purposes of this post I’ll assume the internal network is on the 192.168.0.x range, the router is 192.168.0.254, and the web server is 192.168.0.1.  You will need to modify these IP addresses according to your own network setup.

The first thing to do is to enable debug mode on the router.  Simply go to http://192.168.0.254/setup.cgi?todo=debug and you’ll be rewarded with an appropriate message, “Debug Enable!”.  Nice.

Now connect to the router with ‘telnet 192.168.0.254′ to gain access to the router’s cut-down installation of Linux.  All that is required is to add one additional entry to the router’s iptables (which is a standard Linux feature; Google it or more info).  Type the following, amending any IP addresses according to the network setup:

iptables -t nat -A POSTROUTING -d 192.168.0.1 -s 192.168.0.0/24 -p tcp –dport 80 -j SNAT –to 192.168.0.254

This adds a rule to the POSTROUTING chain on the nat table which applies to all TCP traffic on port 80 (HTTP) coming from the private network and headed to the router.  The rule redirects the traffic to the server, and then processing jumps to the SNAT chain.

If the server is more than just a simple web server, such as an NTP server or mail server as well, the above step needs to be performed (changing the -p and –dport parameters accordingly) for each port and protocol combination you require.  Alternatively, those parameters could be omitted altogether, which will allow all traffic types on all ports through:

iptables -t nat -A POSTROUTING -d 192.168.0.1 -s 192.168.0.0/24 -j SNAT –to 192.168.0.254

If you do this, I recommend you run a firewall on your server, with only the appropriate ports opened.

There is more information in section 10 of Rusty Russell’s Linux 2.4 NAT Howto.

Unfortunately, the iptables change isn’t retained when the router restarts, so it is necessary to go through the process every time – which is a pain in the backside.  Fortunately, however, the Netgear support website has a download link for previous firmware versions, so I downgraded my router back to firmware v5.01.09 and everything worked fine again–including NAT loopback–with no iptables hack required.

A robust solution with DNS

Simply put, proper DNS is the best way to get around a router’s lack of/poorly implemented NAT loopback.

If you have the resources to host a website then you most likely also have the resources to host a DNS server for your internal network.  Simply create an ACL list describing all the clients on your internal network (probably as simple as specifying the CIDR block for your network, maybe something like 192.168.1.0/24).  Then create a view whose clients match that ACL, and define that view as a master DNS server for your website domain.  You then need to create a zone file for that domain – but instead of using an external IP for your webserver, use its internal IP.

All requests for other domains will be routed to the DNS forwarders, but requests for your webserver’s domain will be handled locally, and internal IP addresses will be returned.

The benefit is that you avoid traversing your gateway router to simply come back inside your network.  It doesn’t make sense that you rely on your gateway router to access a website within your own network.  In addition, the firewall on your router can be hardened to a much greater degree: for example, you needn’t leave FTP ports open on your router if you’re only connecting locally.  Or, to put it another way, you’re likely going to want to give yourself more access to your server than you want to give to the outside world; configuring a router’s firewall rules for this kind of conditional logic is simply asking for trouble.

Specifically, “The Bluetooth Radio failed to turn ON due to insufficient driver memory available”. Hmm. Fortunately we were only 1/2 a mile from home when we realised it wasn’t going play ball, so we went home. “It will only take 2 minutes to fix”, I claimed.

I was wrong.

A Google search only resulted in pages that seemed to think that the problem was the order in which software gets loaded into memory in Windows Mobile 5.0; the Bluetooth drivers always get loaded into a specific memory address, and if this address is already in use, the drivers don’t load and the Bluetooth stack doesn’t work.

But uninstalling everything from the iPaq and performing a million hard resets didn’t work. I decided that the Bluetooth hardware had broken, and Windows was giving the above error message by default.

So I resigned myself to buying a new PDA, because I lost my iPaq restore CD in a previous incident, and had no way to reinstall the OS from scratch.

Fortunately, I stumbled across a page for the 2790 on hardreset.eu, which describes the way in which the 2790 can be restored to factory settings; just hold the Calendar, Messaging, and power buttons, and then press the reset button until the iPaq reboots. It will then reformat its internal storage, and (presumably) copy the factory configuration from a neatly tucked away back-up ROM.

And now it works. Bluetooth, I mean. It works. It wasn’t broken, it just had an unidentified problem (which may or may not have been accurately described by the error message it caused).

I can now safely venture past the end of our road without the risk of getting lost.

But at the weekend it refused to upload anything successfully, complaining about PHP and web server upload limits – things over which I have no control. So I went back to using the clunky web interface to upload my photos, only to be greeted by the useless “Internet Explorer cannot display the webpage” page on each attempt.

Things didn’t look good. So I decided to download a cleaner-looking and simpler gallery application (Plogger) to give it a go. Still no luck.

Having ruled out the problem being Gallery2, I decided my website host had changed some things on their side. A quick Google later, and I realised that I couldn’t upload anything more than small text files to any server. So it’s not my website host.

Good job I didn’t send them that email.

But wait, I can upload files to the gallery using a machine on the other side of the corporate VPN… which uses the corporate Internet connection. So it must be my ISP. It must be. Surely? After another quick Google, I read that a number of ISPs have been caught sending fake TCP reset packets to their users so that ‘undesirable’ connections (ie. file sharing applications) are disconnected.

Knowing how to troubleshoot this kind of problem, I proceed to download Wireshark, a network protocol analyzer (formerly Ethereal). Sure enough, each time I try to upload a .jpeg or .bmp or… in fact almost any type of file, I receive a TCP RST message – surely the fake reset message sent to me by my interfering ISP!

However, it seems that my ISP is blameless after all.

It turns out the latest firmware for my Draytek 2800 router adds an innocent-looking option called “Drop non-http connection on TCP port 80″ which is enabled by default. I feel it should be more accurately called “break everything”. Disabling it fixed the problem, but it took an entire lunch break.