For the last 6 months or so, I’ve been running a free wireless access point for my neighborhood. In an effort to get my local community to know each other (and local goings-on), I’ve back-ended the system using the elgg social networking platform.
To use the free wifi, you have to register on the social site.
Uptime however has been a major pain – for quite some time NoCatSplash has been broken in DD-WRT. Ever since version 24 (at the very least), it’s been grouchy – all of the sudden not working and requiring a reboot (or possibly clearing and resetting the iptables targets and restarting splashd) to fix. The wiki documents a few workarounds, but I’ve gotten tired of the overall bugs.
Initially I planned on simply fixing it, but after a little bit of thought, I decided to give OpenWRT another look. I’m sure I could have gotten away with using the mini or micro versions of DD-WRT and adding to it, but last time I used OpenWRT’s build environment I was really impressed – so I spent this weekend working with it again.
Building your own image is simple – using the ImageBuilder system (I’m working with WRT-54G’s) simply “make image” setting the target PROFILE and PACKAGES via environment variables. This method uses existing binary packages to build a .bin or .trx file for easy installation (via the web interface or mtd command). “make info” will give you a long list of profiles, and packages that are readily available are contained in the packages subdirectory.
Recompiling packages is extremely easy – download the SDK:
mkdir ~/devel && cd ~/devel
wget http://downloads.openwrt.org/kamikaze/8.09.2/brcm-2.4/OpenWrt-SDK-brcm-2.4-for-Linux-i686.tar.bz2
tar xjvpf OpenWrt-SDK-brcm-2.4-for-Linux-i686.tar.bz2
If the package already exists, check it out via subversion:
cd OpenWrt-SDK-brcm-2.4-for-Linux-i686
svn export svn://svn.openwrt.org/openwrt/packages/net/<packagename> package/<packagename>
And to compile simply execute:
make package/<packagename>/compile V=99
(On older versions it’s “make package/<packagename>–compile V=99″)
After hitting my head against the nocatsplash package’s failure to build correctly, I finally opted to look at nodogsplash. “Because it will at least build” is probably not the best way to choose captive portal software, but it’s mine.
First thing requiring a fix is a bug that causes nodogsplash to crash when one sends a request to the auth-server without a “redir” GET variable being set – a bug evidenced by:
links “http://192.168.1.1:2050/nodogsplash_auth/?tok=fffffff”
Thankfully the crash is “gracefully” handled in safe.c’s safe_strdup()…. but it still causes the daemon to crash.
So – a quick patch, as well as some added “features” (including a magic token) and I’m set. Patches to source can be added to package/<packagename>/patches. Upon make, patches in this directory are first applied.
So instead of waiting around for a fix to NoCatSplash in DD-WRT, I’m moving on. So far NoDogSplash has proven effective – although I’m far from actually migrating to it (the old access point is still running for the time being). In the next few weeks I should have a custom web interface built, as well as pmacctd configured (I am exporting Netflow version 9 data to a collector as a C.Y.A measure), and bandwidth shaping properly enabled.
Custom patches to NoDogSplash are forthcoming.
Hey, How to use an external splash page with the token ?
What is this token for ?
thanks
The magic token is just a universally accepted token for any user. It was a fast and easy patch – generally the system checks that a submitted token is valid for that IP during the portal authentication phase. I found it was easier to do than storing the real token in Session data or as a cookie.
Ever have a chance to release your patches to nodogsplash?
Hey David,
Yeah, have a look here and other patches are here
Pretty basic patch, it adds the config item “magictoken”. If the end-users browser returns their unique token OR the magic token, they’re allowed access.
Did you find the problem with the GET request still exists in the latest nodogsplash code? Have you made any further improvements? Are you available to do any coding improvements?
At quick glance, it appears as though it does in 0.9_beta9.9.6, which I believe is the latest.
(My) only recent improvement was a patch to perform a find/replace on the redirected to URL (It replaces any instance of MACADDY in GET variables with the actual users MAC address).
I’ve written a plugin for Elgg that then logs the time a user logged onto the free wifi (along with their MAC address, which is now handed back via the redir URL). Previously, I had to dig through dnsmasq DHCP syslogs to glean that information.
What kind of improvements did you have in mind? I’m quite impressed with nodogsplash, it’s not overworked yet it’s complete enough to make minor modifications to it’s source a breeze.
Mainly I’m looking to increase the amount of users nodog can track. Right now we see roughly 60-70 users max before nodogsplash can no longer track users or it just crashes. Mos of the time it continues to run but new users are simply not tracked or seen with ndsctl status/clients. The user still gets an ip from dnsmasq/dhcp, but nodog has reached some sort of memory limit? This is on a wired gateway controller running openwrt with loads of cpu/ram. I believe the source code is the clue and that it simply needs adjusted to allow such high amounts of users. I suspect it was aimed at a smaller base of wireless users when equipment was not as powerful and more then likely only a few wireless clients were involved. You can easily duplicate this problem by creating a script that changes your MAC, request new dhcp, and pulls a web page every 20 or so seconds.
Forgot to mention, also in need of passing the real MAC to an external page system that sounds similar to what you mention. Actually we have a couple things, just wasn’t sure if you were still working with nodog. Thanks for the fast response.
What version of nodogsplash are you using? I’m assuming you’ve set MaxClients in the config file > 70.
Do you syslog anything to a remote server? There are some messages that get syslogged elsewhere that can give additional clues as to what’s going on under the hood.
For an example, if you exceed MaxClients the call to client_list_append() logs a message that the max is exceeded and returns NULL.
My install presently has had no more than 6 people online at a single time, usually averaging 2-3 people online at a single time, so I’ve not come across what you’re seeing yet. I’ll see if I can replicate what you’re referring to and get back to you shortly (ping me if I take too long).
Yeah, I’ve got a patch that hands the MAC off to an external page. It can also hand off the IP address, just haven’t made that modification just yet.
Would it be possible to contact you via email? I just for some reason now noticed what you were doing with nodog and elgg… very interesting.
I would like to have a similar setup for a high traffic area where we are trying to capture information and provide a social network service of sorts in exchange for free wireless.
Still trying to determine how or if it’s at all possible to correct nodog source and keep it from running out of program memory with lots of users.
Hello, Thanks for your helpful post. I want to clarify because I’m not sure I’ve followed and understood all of the post and comments correctly…
I am also having the problem with the daemon crashing via the GET variable issue that seems to be caused by some users’ iPhone or iPod Touch.
Have you managed to fix or work around that problem?
I have nodogspash installed on two routers and both are having this problem…
– 0.9_beta9.9.6 running on Backfire (10.03.1-rc4, r24045), Linux OpenWrt 2.6.32.25, WRT54GL 1.1
– 0.9_beta9.9 running on KAMIKAZE (8.09.2, r18961), Linux OpenWrt 2.4.35.4, WRT54GL 1.1
I’m running the second one on KAMIKAZE because I needed traffic control and, from what I understand, traffic control doesn’t work with nodogspalsh on Backfire.
I’m using the [form] method on my splash.html page on the router…
[form method=”GET” action=”$authaction”]
[input type=”hidden” name=”tok” value=”$tok”]
[input type=”hidden” name=”redir” value=”$redir”]
[input type=”submit” value=”Login/Enter”]
[/form]
Any help or guidance you can provide is appreciated.
Hello Bob –
Regarding the nodogsplash daemon crashing – yes, I’ve got a workaround for that. Have a look at my patch here [1]. I’ve simply added an additional test that verifies the end user sent a redir GET variable. If they don’t, it redirects the end user to whatever is value is set in the nodogsplash.conf.
Prior to that patch, I’d never actually encountered an instance in which someone crashed nodogsplash by not sending that variable. That bug only came to light during some fuzzing tests I was conducting. I don’t have an Iphone, but I know some browsers have a tendency to unfortunately not pass things along properly
**Slightly off topic – Hughesnet satellite internet is the WORST offender in waxing GET and POST variables from HTTP requests. It appears they put a web proxy inline to hold TCP sessions open due to high latency (as evidenced by an X-forwarded-for header added to requests). If SSL isn’t used on a site, they wax variables left and right. Good luck getting them to fix it.
I do have rate-limiting working fine under Backfire 10.03 without issue. There is a kernel version difference in what we’re running (mine appears to be 2.6.30.10, and I should probably update that). But I do frequently test things, and my rate-limit of 1M/128k definitely works.
Are you building from source or using pre-packaged releases? If from source, try throwing in my patch. I should probably contact Paul Kube (the author) and start contributing upstream.
[1]http://www.braindeadprojects.com/src/OpenWRT/001-allow-magic-token.patch
Thanks for your response. I am currently using the pre-packaged OpenWRT releases. I was hoping not to have to setup a box to compile on. Any suggestions (or do you know of a FAQ) of what to use for such a box?
I think the iPhone/iPad/Touch issue is connected to it’s “auto-login” feature.
Did you happen to test out doing a change of your MAC address over and over and requesting dhcp from nodog? You’ll find that it just stops working at X amount of clients show up under ndsctl status or clients. Actually the output of those commands will start to partially get chopped off in the console output. Soon after it will simply either stop tracking new clients or just crash.
The number seems to depend on how much ram is in the device, so 64mb ram gets me about 50 users – while 128mb ram has went as high as 80 clients show under it’s control. Most of the time i would guess not many users would be associated to one access point without other problems developing, but in my cause this solution is a wired connection (eth1) and does have a lot of people connecting.
Oh, you could run into this problem on a wireless access point if you don’t have the idle time out set to really low. If your in a populated area and lots of iphones walk past and gain dhcp even for a sec they will quickly fill up the buffer of nodog and you’ll expericance what I’ve seen. For now I’ve moved to coova which I’ve been able to get over 160 connections being tracked without a crash.
Hi there,
I would be interested in knowing if you could make the tokens encrypted. e.g. Set an encryption key in the config file and be able to decrypt it on a website once the user logs in (the website would be in PHP)
Otherwise the user can just sniff the pages and find the token and login straight away.
Regards,
Cody
Why not just enable SSL the entire way through? SSL on the nodogcat web controller and on the portal site? Seems a bit less convoluted.
Hello there,
I’m still trying to solve the crashing problem with nodogsplash on OpenWRT Backfire and Kamikaze.
I have never attempted to setup an OpenWRT build environment.
What are the chances you could help me get a patched nodogsplash package I can use on my deployed WRT54GL units either by providing instructions/suggestions for compiling myself, or (if you have a OpenWRT buildroot already setup) by sending me your nodogspalsh.ipk on the off chance we use compatible hardware.
Feel free to reply by e-mail.
Regards,
Bob
Moritz Warning contacted me this morning to let me know that the crash caused when a redirect parameter isn’t set has been FIXED.
https://dev.openwrt.org/changeset/32017/packages
Thanks for the heads up Moritz.
Same problem here. Nodogsplash keeps crashing if more then 60-70 users connect. Sometimes nodogsplash will just freeze, sometimes it takes down the entire router with it (It might still be running, but I cannot connect to it anymore through a tunnel remotely).
I’m using nodogsplash version 0.9_beta9.9.5 on Linux OpenWrt 2.6.32.10 / Backfire (10.03, r20728)
How do I apply this patch? I was reading http://wiki.openwrt.org/doc/devel/patches but that didnt help me at all. Could you explain it to me?
Hi David
I thought I read on another post that you patched nodogsplash to work with php pages (rather than just html as it does now) and also to pass through the macID as a variable that can be used like the $imagesdir variable.
Ive got two questions on the back of this:
1) Would you be able to share the php patch or patched version.
2) Do you know if it would be possible to also pass through the SSID as a variable that the user connected to, and if so how would I go about doing it?
Hello,
Actually nodogsplash can work with PHP pages in it’s stock configuration, no patch needed. The easiest way to do this is to alter the splash.html page and use it with a meta-refresh header to redirect the user to a local webserver that supports PHP.
Then, to authenticate the user you’ll need an HTML form that submits against the nodogsplash controller. The controller does verify that the token variable submitted is valid — http://www.braindeadprojects.com/src/OpenWRT/001-allow-magic-token.patch can be applied to allow a “Magic Token” (so that you don’t have to track the initial token, anyone that submits the “Magic Token” is granted access). This is how early incarnations of the Midtown Wifi project worked.
The MAC address patch is here: http://www.braindeadprojects.com/src/OpenWRT/002-redir-with-mac.patch
I’m fairly certain there is no way to track SSID.
I’ve not worked with nodogsplash in some time, so I am operating off memory and a few sporadic notes (as well as this writeup). Feel free to ping me if you need any help with anything, I’ll see what I can do.
you rock matthew, (sorry for calling you david), I think i was looking at the david that was also commenting through tired eyes…
Ill ping you if i get stuck… Ive modified a script btw to get the SSID from karma logs if you have the macid so this should work well, also the script gets the mac ID from ip address if you have that… but I think the script must chew resources so I was looking for something a little easier on the box.
= 0; $i–) {
$tmpstrpos = strrpos($karma[$i], “Successful”);
if(strrpos($karma[$i], “Successful”) > 0 ){
$client = array();
$tmparry = array();
$tmparry = explode(” “, $karma[$i]);
$client[0] = $tmparry[5];
$client[1] = substr($karma[$i-1], 71);
$exists = false;
for ($j = 0; $j
Hi
Great post really learned a lot reading it.
We just started using nodogsplash for T&C page alone and it works like a charm. We have two issues though and wanted to hear if any of you have the same problems and best case a solution for it.
It has all to do with how nodogsplash uses iptables rules to block users before accepting T&C.
1. iphones and mac os x.
When a user log on the wifi the normal behavior is that the iphone or laptop silent will try to access a apple webpage. If the webpage return a content with the work success nothing will happen (there is access to the internet and no captive portal). If the request give anything else the iOS or os x will popup a “login” screen with the content of the response.
The case with nodogsplash is that the request just gets blocked and no redirected.
2. safari and https
When a user log on the wifi and opens a browser med https://www.google.com nothing happens. It seems like the browser (safari) will not accept content with no or a different certificate than google.com. Don’t know exactly what happens here but it something if off.
I am wondering if you can make it so that instead of blocking if there is a url to the routers T&C page you can setup a iptables to rule and just forward to that. Then the url in the brewer will change but I think that both two of my issues will be solved?
Perhaps I am wrong in my debugging or some of you have the same issues please let me know.
Hey Robert,
I’ll have to fire up my Ipod Touch (it’s the only Apple device I’ve got) to look at item #1. Will see if I can find some time in the next week or so for that.
Regarding #2, that’s kind of a common problem, especially since more and more sites have moved to HTTPS (for good reasons). In theory, you could patch nodogsplash to do this (similar to what you’re proposing):
If the user is not authed, redirect any TCP:443 traffic to an HTTPS server under your control. Then, have that HTTPS server issue a 302 redirect back to the nodogsplash portal on port 80.
The problem with this is that when the user visits https://google.com and they’re redirected to your HTTPS server, your SSL certificate won’t match Google’s. This will prompt the user to “accept an invalid certificate” and most likely scare the user away.
If it doesn’t scare the user, they could accept the cert, the redirect shoots them to the portal and all is well. It’s kind of a kludgy solution and I’m not sure of any good way around it.
Let me know if you need any help with it.
Hi,
I am writting here, couse I could not find solution to my problem anywhere else.
I have a problem, that after installation of nodogsplash i get splash page only when I try to access my router trough Luci. If i navigate to any other page, i get no splash page.
Can anyone pleas help?
Thank you for your time.
Hey Filip,
It sounds as though you’re missing an IPTables rule to redirect all traffic to the gateway. Send me the results of “iptables-save”