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

Sun Mar 9 01:55:36 UTC 2014

Hi Eric, thank you very much for the tip!  Yes, such macup/macdown script
hooks should work quite well. I only saw the conup/condown options on the
man page here (possibly out of date?):
http://coova.org/CoovaChilli/chilli.conf

Looks like macup/macdown were introduced in v1.2.5:
http://coova.org/CoovaChilli/ChangeLog

On Sat, Mar 8, 2014 at 7:17 PM, Eric Chaves <eric at craftti.com.br> wrote:

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

-- 
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/9f477fd9/attachment-0001.html>