[Chilli] Disassociate clients that don't authorize themselves via portal?

[Eric Chaves]

Hi Ben,

You can run scripts when a client is connect,disconnect, authenticated and
logoff. Take a look at macup/macdown/conup and condown parameters. macup
and macdown happens when a client connects (get a lease) and disconnects
from the controller (release a lease).

Cheers,

Eric


2014-03-08 22:01 GMT-03:00 Ben West <ben at gowasabi.net>:

> Thank you, David, for the clarification.
>
> Yes, I do agree that trying to kick off lingering unauthorized wifi
> clients (i.e. using "iw wlan0 station del ...") would probably just prompt
> the client to automatically reconnect, and be ineffective.  The underlying
> motivation for my question was observation of a few client apparently
> parking themselves on an AP for long periods of time and never clicking
> thru the portal.  OpenWRT tools like "iw wlan0 station dump" and "bmon"
> seem to show some of these clients downloading substantial traffic
> (Mbytes), comparable to other clients on the same AP that are authorized.
> Snooping the nf_conntrack table for these clients only yields port 3990
> connections to the HS_UAMLISTEN address and DNS queries to HS_DNS1.
> Possibly, these misbehaving clients are doing something sneaky like DNS
> tunneling, i.e. to bypass RADIUS auth (and thus the bandwidth caps).  Or,
> they're just repeatedly hitting the captive portal and going no further.
>
> However, instead of trying to pursue a whack-a-mole game, I'm more curious
> about the prospect of applying bandwidth caps to *unauthorized* clients,
> at least so that anyone who may be attempting casual DOS attacks or DNS
> tunneling would have an upper limit placed on the bandwidth available to
> them (i.e. comparable to the limit they would otherwise see by clicking
> thru the portal). Traffic shaping under OpenWRT that is tagged to a
> specific destination IP or MAC address does indeed look to be possible.  I
> think the key here would be to deploy such shaping to each unauthorized
> client upon issuance of a DHCP lease, and then use coovachill's conup
> script to flush those iptables rules upon session authorization, i.e where
> coovachilli takes over the session's bandwidth control.
>
> I'm guessing there is no ability to have coovachilli launch an external
> script upon each lease issued. So, I would need to have an external tool
> with such capability (i.e. dnsmasq) handle clients' DHCP, right?
>
> Also, Jed, the open APs are operated so by intention, i.e. to provide
> limited free wifi comparable to that found in coffeeshops, grocery stores,
> etc.  My coovachilli/firmware config is nearly identical to that used by
> Cloudtrax and WifiMesh.  Additionally, I use RADIUS to assert bandwidth
> caps and session lengths.  (Closed APs with WPA2 encryption are also used
> where desired.)
>
> Thank you again.
>
>
>
> On Sat, Mar 8, 2014 at 1:18 PM, David Bird <dbird at google.com> wrote:
>
>> No, there isn't such a feature. You could disassociate clients perhaps
>> through the driver, but chances are the client will just re-associate
>> (unless there is another network it knows). You could have chilli drop
>> everything for the station, but that will not prevent the client from still
>> taking up airtime trying to (re)send packets. However, depending on the
>> client, it may drop the signal itself if it thinks it lost layer2
>> connectivity.
>>
>>
>> On Sat, Mar 8, 2014 at 7:21 AM, Ben West <ben at gowasabi.net> wrote:
>>
>>> I"m curious if coovachilli v1.3.0, in my instance running under OpenWRT
>>> Attitude Adjustment, offers a way to actively disassociate clients who do
>>> not authorize themselves via the captive portal, but which still remain
>>> associated with the hotspot.
>>>
>>> The particular scenario I'm envisioning is someone's phone or tablet
>>> that automatically associates to an open SSID, but where the user doesn't
>>> bother clicking through the captive portal.  The device continues to try to
>>> periodically pull down content (e.g. app updates), sometimes quite
>>> furiously, causing a fair amount of useless traffic over the wifi channel,
>>> chewing up airtime.
>>>
>>> Or, instead of actively dissociating such an unauthorized client,
>>> perhaps instead have coovachilli run an iptables script after some
>>> inactivity timeout to begin throttling traffic to the client?
>>>
>>> Thank you.
>>>
>>> --
>>> Ben West
>>> http://gowasabi.net
>>> ben at gowasabi.net
>>> 314-246-9434
>>>
>>> _______________________________________________
>>> Chilli mailing list
>>> Chilli at coova.org
>>> http://lists.coova.org/cgi-bin/mailman/listinfo/chilli
>>>
>>>
>>
>
>
> --
> Ben West
> http://gowasabi.net
> ben at gowasabi.net
> 314-246-9434
>
> _______________________________________________
> Chilli mailing list
> Chilli at coova.org
> http://lists.coova.org/cgi-bin/mailman/listinfo/chilli
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.coova.org/pipermail/chilli/attachments/20140308/f4b3b2b9/attachment.html>