Re: wrt54g

On Wed, 2005-05-18 at 11:20 -0600, Ian White wrote:
> For example, we've been looking at nocat on ewrt, and deciding if we
> can add
> a simple pin code to the process so that for wifi cafe, someone has to
> get
> today's pin to get access. Now I could add the pin to the conf file,
> and
> read it on restart, but restart wipes the current status and iptables.
> 

I've looked a little at implementing something where it receives a HUP
signal and reloads the conf file.  There is some work that needs to be
done there because with the way it is set up now, if the hash table that
holds the configuration is destroyed, then there are some variables
still pointing to that data that need to be reinitialized.  If the hash
table isn't destroyed, and a new one is simply added, then you have 1) a
memory leak, and 2) many variables are still pointing to the old values.

I was looking into this earlier for a different reason.  If the splashd
daemon is simply stopped and started--even with a short sleep--rather
than signalled for a configuration reload, there is a chance for the
"Bind: Address Already in Use" error to occur when restarting.  This is
due to the TIME_WAIT status of a TCP connection to the splashd that may
be in effect [1].  I encountered this many times, so I looked at writing
the configuration reload.  However, I wasn't sure how great others' need
was for it, so I left it alone.

> The other option is to add a signal handler that tells nocat to pick
> up a
> new config/command file. i.e. on pin change, signal nocatsplash,
> signal
> handler picks up the new pin, and stores it for login checking.
> 

We're currently using NoCatSplash with flatfile passwd authentication,
but are looking to move towards using a service (e.g., RADIUS) to
authenticate, as capabilities are added.  Regardless, one thing we've
done is have the splashd check periodically to make sure that logged in
users are still valid (rather than simply wait until their time
expires).  This process involved associated a particular userid to a
"peer" (MAC, ip address tuple).  This would be in case, for any reason,
somebody has had their access revoked, but we didn't want to affect all
users by simply restarting the daemon.  Again, I'm not sure what kind of
overhead this produced or if there is any other interest for it.

> If you don't want radius inbedded then go the LW route, and call an
> external
> script which calls wget/curl and gets a valid/not valid from an
> external.

> I'd also be interest in signal to pick up commands... i.e. disconnect
> this
> mac, ban this mac etc....

This would be an interesting addition.
> 
> My issue would be working with the tpool etc as I'm not used to that
> process.

tpools are no longer used.  Instead the glib main_loop is used [2].  It
is much less complicated than working with threads.
> 
Casey Deccio
Sandia National Laboratories
Livermore, CA

[1] http://hea-www.harvard.edu/~fine/Tech/addrinuse.html
[2]
http://developer.gnome.org/doc/API/glib/glib-the-main-event-loop.html