Has anyone tried to take the repaired NoCatSplash from E-wrt and build it within openwrt?  The makefiles in Ewrt call some different variables and libraries that openwrt does not use.  We have been trying to diff the two and come up with a new makefile.   It would be really easy, however, if someone has used ipkg and made an ipk file of the E-wrt NoCatSplash distribution.  Anybody ever made an ipk of the Ewrt NoCat? Suggestion?

Why is NoCatSplash even still in the package lists since it appears that:
1- It doesn't work as supplied, or even after a lot of tweaking.
2- It segfaults frequently.
3- When it crashes, it takes down the entire network.
4- It seems to require a router reboot to clear the mess it leaves behind when it dies.
5- Nobody appears to be fixing it.

I got annoyed enough with Nocatsplash breaking on recent White Russian releases, and with the infrastructure complexity of Wifidog and Chilispot, to write a Nocatsplash replacement derived from the Wifidog code base.  Being a kind of mashup of Nocatsplash and Wifidog, it's called Nodogsplash.

I've been testing it on a mostly stock OpenWRT White Russian 0.9 system, and it's been working well here.  I'd be happy to hear if it's useful to others. 

For the ipk package, a source tarball, and some documentation, see http://kokoro.ucsd.edu/nodogsplash/.

Let me know what you think...

Thanks,

Paul
nodogsplash (at) kokoro.ucsd.edu

This is great.  I had tried nocatsplash, but I immediately ran into the segfault problem.  I am having a little problem, however, with the nodogsplash authentication link.  Instead of being redirected to the page I originally requested, it appears that I'm being ridirected to whatever was the last URL to hit nodogsplash (or maybe the first).  In a couple of cases I was redirected to the favicon.ico for Google.  The last time I tried it, I was redirected to a URL used by Google browser sync.

Neil

Neil,

Glad to hear it is basically working!

Let me explain what nodogsplash is doing to get a redirect URL from clients.

When nodogsplash first sees a port 80 request from an IP on the interface it is managing, it creates an entry on its client list for that IP (it also gets the MAC address from the ARP cache and remembers that as well).  It gets the host and path in the request, and puts that in the entry, as the redirect URL.  And it serves back the splash page.

Now if another port 80 request comes from that IP before the user responds to the splash page, nodogsplash gets the host and path out of that request, and puts it in the existing client list entry, updating the previous redirect URL.

So, the last port 80 request from a client before they click on the splash page will be the one they are redirected to.

Why do it that way?  Well, browsers these days automatically generate all kinds of port 80 requests.   For example polling RSS feeds, etc.  A lot of these can hit nodogsplash before the user consciously goes to a page, so I was thinking that the most recent request is most likely to be the one the user really wants.  But that's a heuristic that is sure to be wrong in many cases.  Any suggestions for a better heuristic?  (Ignoring requests to paths that end in .xml seems kind of extreme...)

As for favicon.ico requests... That is an example of a browser's automatically generated request.  But that is one I can easily detect, and modify to be a request to the containing directory.  In fact I have made that change (along with a few other small things like making the ndsctl status output more informative) and posted the new version on the web page. So I recommend you upgrade!   (Up to beta2 already...:)

Cheers,

--Paul

OK, it's configurable now whether certain initial web requests are ignored, based on the extension in the path of the request.  Default .ico and .xml are ignored; this seems to give better behavior, but if you don't like that it is configurable in the .conf file.

Also there was a bug causing segfaults when parsing blocked or trusted MAC lists.

beta3 now... release early, release often, as they say.

Cheers,

Paul

Okay, no more favicon.ico, but now it is picking up Google Browser Sync.  I'm getting sent to this URL:

http://browsersync.google.com/browsersync

Unfortunately, no extension.

I'm curious.  You said you based nodogsplash on Wifidog.  Didn't Wifidog have a method for dealing with this already?

Neil

No, not really.  At least in wifidog-1.1.3_beta6, which I started with, they just use the requested path.  And that's if the request 404's against the libhttpd sever; if it's a request with a hostname and no path, they won't even try to redirect to your requested page, so far as I can see.

Anyway, I think what I should do is to issue a splash page encoding a different redirect in response to each request, instead of trying to guess which in a stream of requests is the 'right' one to redirect to.  That is, a redirect target per-splash page, instead of per-client.

(Assuming that Google Browser Sync won't choke if it gets something like a nodogsplash splash page as a reply...)

--Paul

OK, Neil got me to rethink that, and the result  now (in 0.7beta4)  is much nicer from the user's point of view, IMO.

Thanks for the feedback.

--Paul

Seems to work great now.  Google Browser Sync doesn't seem to mind.  I'm going to play with it a little more over the next week, so I will let you know if I see anymore issues.

Thanks.

Neil

A memory leak squashed and a few minor changes, now 0.7beta6, at http://kokoro.ucsd.edu/nodogsplash/.

Anybody using the package, I'd be interested to know what version of OpenWRT and what hardware you're using, and if you see any problems.

--Paul