08 Nov

Why airport wifi sucks?




Sitting at Kolkata airport. Noticed the usual “Free Wifi in the area!” message and connected to Tata Docomo Free wifi. Performance was quite poor.


Two key issues with wifi: 

  1. Using of only 2.4Ghz (802.11b/g/n with 20Mhz channel). No AP with 5Ghz box. (Click here to view scanner data). Should have been 5Ghz
  2. Entire traffic is getting tunnel via Mumbai i.e West India (while I am sitting on Eastern side). Adding up to latency and performance significantly.


Here are some of traces to random locations:




So no matter wherever I push packets for, then hit hop 5 – Mumbai / VSNL AS4755 router because likely that is where the core L3 device (MSC/central authentication box) for this network is. This is big issue because likely Tata Docomo would be tunneling entire wifi traffic from anywhere in India, going to anywhere globally via Mumbai because that is where they put their wifi central box. What we need in India is more simpler deployments, more open source stuff so cost doesn’t becomes point of selection for keeping such devices central. And most important we need networks to peer at internet exchanges so atleast East region traffic stays within East and doesn’t has to travel thousands of kilometers to Mumbai just to hop on to another network.



Overall speeds seems to be capped at 1Mbps which is too low these days and here’s 100 packet ping to first hop ( showing how poor is the wireless signal performance.


Since latency min is 48ms, quite clearly L3 end is far off in Mumbai and likely would be running ipsec or some other kind of VPN tunnels to the APs. This is ground level performance of what we hear in media “wifi business strategies“. Wifi as a technology is excellent but does take decent homework to deploy properly. Just hanging bunch of boxes and routing traffic from one MSC/central server placed far off doesn’t really helps. Wifi as a technology can help to offload stress on 3G/4G significantly as long as it is done in right way keeping in assumption that Wifi runs on “unlicensed spectrum” and interference can very much happen.

Time to catch up flight to next hop!

23 Oct

Night fun task: OpenVPN, Quagga, Rasberry Pi and more!

I have been using OpenVPN from quite sometime and very much like it. Earlier I was running OpenVPN client on TP Link 1043nd router and that worked great. But recently I switched home routing to Microtik Map2N which has much better VLAN & IPv6 support. Since then I had trouble in getting VPN back live. I can always use VPN client on laptop but that’s ugly for daily use specially when this is my primary work location!


It’s hard to put in this blog but there are number of issues and limitations which come up if I try to use Microtik itself as OpenVPN client. Eventually gave up on that. Now, comes Raspberry Pi which is just a tiny Debian box running quite nicely. I configured OpenVPN on it and connected it as client to my server. It works fine. Next, pointed a static route for a sample test IP from core router to Rasberry Pi, and it did not work. I realized IPv4 forwarding isn’t enabled on it by default. 🙂


Once IPv4 forwarding is enabled, still connectivity doesn’t works because of usual private addressing issues. Both home LAN and VPN tunnel works over private IPs and hence packets do hit my server but it cannot return since it’s unsure on return path. This brings me to do usual source NAT on home LAN pool going towards VPN server via tunneled interface. And vola! it works.

iptables -t nat POSTROUTING -s -o tun0 -j SNAT –to-source


Now, a big issue which comes here is that for private addresses which I use for random applications/testing etc it works fine but there are certain public IPs as well which I route via OpenVPN. In this setup, I have to put static route at router end to push towards Raspberry Pi for each case and worst – if VPN tunnel breaks, connectivity will go down completely for those pools.

Thus I decided to rather use “dynamic routing” here. My lovely Quagga comes to rescue. Next, I configured a iBGP session between Quagga and core router and passed “redistribute kernel” in BGP config to redistribute all routes Raspberry Pi learn while connecting to VPN (in form of pushed routed in openvpn config on the server). And it works! 🙂

In this way as long as VPN is up, it’s prefered for public pools and when VPN is down, they take their usual path without having to manually disable any static routes.


So here comes a “State of Art” site to site VPN using OpenVPN, Quagga and Raspberry Pi. Time taken to setup: ~5 mins (Less then time taken to write this post 😛 😉 )


Quagga Config:


Have fun!