16 Responses

• anonimous

  Hey, How to use an external splash page with the token ?

  What is this token for ?

  thanks

• admin

  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.

• david

  Ever have a chance to release your patches to nodogsplash?

• admin

  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.

• shawn

  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?

• admin

  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.

• shawn

  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.

• shawn

  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.

• admin

  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).

• admin

  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.

• shawn

  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.

• Bob

  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.

• admin

  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

• Cody Cooper

  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

• Matthew Gillespie (admin)

  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.

• Bob

  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

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website

CAPTCHA Code *