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

[Ben West]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.coova.org/pipermail/chilli/attachments/20140308/1e01a428/attachment-0001.html>