Strange Networking Woes

So today is the first day of Auscon. The organisers have choosen to use GRASE Hotspot to manage Internet access at the venue. The machine running the hotspot had been tested at an alternative site successfully, and the interface modified slightly to suit the event. (Which won’t need to be done as much with some new changes in the next version)
However, the day didn’t look good with the hotspot not functioning properly. Everything BUT WWW (http, port 80) traffic was working. Investigating Squid showed that it was attempting to connect to 1.0.0.0, which most keen observers would notice is a network address not a device address. Strangely enough, squid was trying to connect to 1.0.0.0 via ipv6! It was thinking it was an ipv6 address.

The quick solution was in to install dnsmasq on the hotspot machine, and point it to a public DNS server I know to be working, and restart squid with it using the local dnsmasq instance. Everything is good now.

But is that the real issue? There is an overlapping netmask. Coova Chilli is setup to use 10.0.0.0/24 (so 10.0.0.1-254) for it’s addresses. However, the upstream network interface was setup on a 10.0.0.0/8 which overlaps the Coova Chilli network. It’s very possible that this overlap is causing problems. An example of a squid log message when the problem occurs is below.

GET http://api.twitter.com/1/direct_messages.xml? - DIRECT/1.0.0.0 text/html

So maybe if you are pulling your hair out, try changing the upstream network if you can. It could also be the upstream DNS (adsl modem) returning faulty values.

Edit: So on follow up, the overlapping netmasks aren’t the issue. Yes, if there was something on the upstream network that was in the overlap range, then it would be inaccessible to hosts behind the hotspot. However, this issue was caused by the upstream DNS server. I believe it is a dlink running dproxy, which has a bug that causes it to start returning 1.0.0.0 after it gets an ipv6 dns request or something like that. Of course, this then caused squid to try and contact 1.0.0.0 as that was what the DNS had resolved to, which of course leads to a timeout. Forcing the hotspot to use the local dnsmasq with a known good public DNS server fixes the problem as we bypass the faulty DNS proxy upstream.

Preliminary Support for Localisation and Translations

Preliminary support has been added for translations and localisation. Using php-gettext (the php version, not the module) so that the locales don’t need to be installed on the system hosting it, and using php-intl, we now can support numbers and currencies formatted correctly, as well as translations.
I’m hoping that the Strings are “semi frozen” for now, so feel free to pull the .po files from bzr (http://sourceforge.net/projects/grase/develop) and start translating!
I’ll add the code shortly to select the current language and locale.

Also coming soon are the much awaited “Chilli Config” pages, where you can tweak the config that CoovaChilli runs off, all from within the web interface. It’ll use the RADIUS Config attributes so that your don’t need to open your config file up for the webserver to write to. This will allow greater flexability in defining uamallowed domains, MAC password, idle time, and just about anything you could change in the coova chilli config files!

Migration to WordPress

After a few months of sticking it out with mediawiki, I’ve given in and started migrating the contents of the wiki to this wordpress install. I originally choose Mediawiki as I wanted a wiki so others could contribute. However, even with Captcha’s in place, I am still spending lots of time cleaning up spam content on the wiki. Using wordpress, I will still allow users to register and edit content, however all registrations will need confirmation, and edits will be moderated until I know that the user is a real person with something good to contribute. It is sad that it has come to this. Please be patient as all old content is moved, the wiki is taken down and redirects are setup.

Thanks

Tim