VLAN support on NEW coova-chilli 1.0.14

Thu, 07/23/2009 - 16:18 — albertix

Hi,
Thanks of great work of CoovaChilli team - make suport of VLAN !
I've just installed new version of CoovaChilli on my Ubuntu 9.04 server. Unfortunately is no dettailed documentation how make implementation of multiple VLAN's on single CoovaChilli or make multiple istances of CoovaChilli at the same server. This is intended to use with multiple AP's on the same interface where CoovaChilli is running.

Can someone post some examples ?

Thanks, Alberto.

CoovaChilli Development

Sun, 07/26/2009 - 05:49 — mctiew

I did some testings on the

I did some testings on the VLAN capability against 1.0.14 and this is my observation :-

1. The client connection to the coova chilli DHCP interface can be VLAN tagged,
and it will then work as before without any changes needed on coova chilli

2. However the radius server does not seem to received anywhere in the
session authentication or radius accounting about the identity of the client
coming from which VLAN.

3. There are these things which I don't understand :-

--ieee8021q <== put or don't put, don't seem to make any difference
--vlan=xx <== also don't seem to make any difference
radius attribute: ChilliSpot-VLAN-Id <== also don't know what's the significance

Sun, 07/26/2009 - 08:02 — david

You should enable the

You should enable the ieee8021q option. Once you do, it will detect the VLAN tag and send it in RADIUS with Chillispot-VLAN-Id and in the redirect query string as vlan=#. The vlan option is actually used should you NOT want to use 8021q directly, but want the vlan= query string parameter sent to the portal anyway (for instance, if you are running multiple chilli instances on VLAN interfaces you already separated, but still want the vlan tag to specify the network).

Sun, 07/26/2009 - 14:57 — mctiew

My previous tests were based

My previous tests were based on mac authentication. It seems that without or without ieee8021q option, it's not make any difference. Subsequently I tested using uam authentication, without ieee8021q option, I could get authenticated. However with ieee8021q option, the browser is stucked somewhere and the uam login page never appear. Below is the debug info from chilli -fd --ieee8021q :-

main-opt.c: 345: 0 (Debug) DHCP Listen: 10.2.0.1 main-opt.c: 346: 0 (Debug) UAM Listen: 10.2.0.1 garden.c: 62: 0 (Debug) Uamallowed 192.168.130.205 garden.c: 45: 0 (Debug) Uamallowed IP address #0:128: proto=0 host=192.168.130.205 port=0 garden.c: 62: 0 (Debug) Uamallowed 10.2.0.1:80 garden.c: 45: 0 (Debug) Uamallowed IP address #1:128: proto=0 host=10.2.0.1 port=80 garden.c: 62: 0 (Debug) Uamallowed 10.2.0.1:443 garden.c: 45: 0 (Debug) Uamallowed IP address #2:128: proto=0 host=10.2.0.1 port=443 chilli.c: 3905: 0 (Debug) ChilliSpot version 1.0.14 started.

tun.c: 497: 0 (Debug) TX queue length set to 100
ippool.c: 228: 0 (Debug) Hashlog 8 253 256

chilli.c: 4087: 0 (Debug) Waiting for client request...
chilli.c: 2522: 0 (Debug) Received access request confirmation from radius server

dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=00:55:00:00:00:22 prot=0800
dhcp.c: 2071: 0 (Debug) Address not found (10.2.0.2)
dhcp.c: 326: 0 (Debug) DHCP newconn: 00:11:44:00:00:31
chilli.c: 3031: 0 (Debug) New DHCP request from MAC=00-11-44-00-00-31
chilli.c: 3034: 0 (Debug) New DHCP connection established
dhcp.c: 2006: 0 (Debug) IEEE 802.1Q: 00:11:44:00:00:31 on VLAN 10
chilli.c: 2906: 0 (Debug) DHCP request for IP address
chilli.c: 617: 0 (Debug) Starting mac radius authentication
dhcp.c: 2110: 0 (Debug) dropping packet; ip not known: 10.2.0.2
chilli.c: 2522: 0 (Debug) Received access request confirmation from radius server

chilli.c: 2544: 0 (Debug) Received access reject from radius server
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=ff:ff:ff:ff:ff:ff prot=0800
dhcp.c: 2054: 0 (Debug) dhcp/bootps request being processed
chilli.c: 2906: 0 (Debug) DHCP request for IP address
chilli.c: 2978: 0 (Debug) Requested IP address when already allocated
ippool.c: 334: 0 (Debug) Requesting new static ip: 0.0.0.0
ippool.c: 334: 0 (Debug) Requesting new dynamic ip: 0.0.0.0
chilli.c: 2994: 0 (Debug) Client MAC=00-11-44-00-00-31 assigned IP 10.2.0.2
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=ff:ff:ff:ff:ff:ff prot=0800
dhcp.c: 2054: 0 (Debug) dhcp/bootps request being processed
chilli.c: 2906: 0 (Debug) DHCP request for IP address
dhcp.c: 1374: 0 (Debug) !!! dhcp server : !!!
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=ff:ff:ff:ff:ff:ff prot=0800
dhcp.c: 2054: 0 (Debug) dhcp/bootps request being processed
dhcp.c: 1374: 0 (Debug) !!! dhcp server : !!!
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=ff:ff:ff:ff:ff:ff prot=0800
dhcp.c: 2054: 0 (Debug) dhcp/bootps request being processed
dhcp.c: 1374: 0 (Debug) !!! dhcp server : !!!
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=ff:ff:ff:ff:ff:ff prot=0806
dhcp.c: 2503: 0 (Debug) ARP: 00-11-44-00-00-31 asking about 10.2.0.1
dhcp.c: 2443: 0 (Debug) ARP: Replying to 10.2.0.2 / 00-11-44-00-00-31
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=00:55:00:00:00:22 prot=0800
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=00:55:00:00:00:22 prot=0800
chilli.c: 1427: 0 (Debug) cb_tun_ind. Packet received from tun/tap
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=00:55:00:00:00:22 prot=0800
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=00:55:00:00:00:22 prot=0800
redir.c: 2153: 0 (Debug) Calling redir_getstate()
redir.c: 2179: 0 (Debug) Get HTTP Request
redir.c: 1223: 0 (Debug) http-request: GET /start HTTP/1.1
chilli.c: 1427: 0 (Debug) cb_tun_ind. Packet received from tun/tap
redir.c: 1251: 0 (Debug) The path: start
redir.c: 1320: 0 (Debug) Host: dslos.com
redir.c: 1339: 0 (Debug) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061102 BonEcho/2.0
redir.c: 1457: 0 (Debug) -->> Setting userurl=[http://dslos.com/start]
redir.c: 2188: 0 (Debug) Process HTTP Request
redir.c: 2312: 0 (Debug) Processing received request
redir.c: 2507: 0 (Debug) redir_accept: Original request
redir.c: 2513: 0 (Debug) ---->>> resetting challenge: e42792024b95b0d46fb2de7800037dca
redir.c: 2524: 0 (Debug) ---->>> challenge: e42792024b95b0d46fb2de7800037dca
chilli.c: 1427: 0 (Debug) cb_tun_ind. Packet received from tun/tap
net.c: 227: 22 (Invalid argument) ioctl(d=5, request=35106) failed
dhcp.c: 197: 22 (Invalid argument) sendto(fd=5, len=1518) failed
chilli.c: 1427: 0 (Debug) cb_tun_ind. Packet received from tun/tap
chilli.c: 1427: 0 (Debug) cb_tun_ind. Packet received from tun/tap
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=00:55:00:00:00:22 prot=0800
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=00:55:00:00:00:22 prot=0800
chilli.c: 1427: 0 (Debug) cb_tun_ind. Packet received from tun/tap
net.c: 227: 22 (Invalid argument) ioctl(d=5, request=35106) failed
dhcp.c: 197: 22 (Invalid argument) sendto(fd=5, len=1518) failed
chilli.c: 1427: 0 (Debug) cb_tun_ind. Packet received from tun/tap
net.c: 227: 22 (Invalid argument) ioctl(d=5, request=35106) failed
dhcp.c: 197: 22 (Invalid argument) sendto(fd=5, len=1518) failed
dhcp.c: 2215: 0 (Debug) dhcp_decaps: src=00:11:44:00:00:31 dst=00:55:00:00:00:22 prot=0800

The subsequent messages just repeat of the last few lines, it goes on and on, but the login
page never appear.

Tue, 07/28/2009 - 08:49 — mctiew

OK I found quite a lot of

OK I found quite a lot of info about this problem.

The problems are two :-

1) the mac authenticated clients won't push up ChlliSpot-VLAN-Id even when ieee8021q is enabled.

This will require a small patch. I have created a patch which seems to work, kindly review :-

--- a/src/dhcp.c 2009-07-27 12:07:08.000000000 -0600
+++ b/src/dhcp.c 2009-07-27 12:07:36.000000000 -0600
@@ -381,6 +381,12 @@

dhcp_hashadd(this, *conn);

+ if (options()->ieee8021q && is_8021q(pkt)) {
+ uint16_t tag = get8021q(pkt);
+ if (tag != (*conn)->tag8021q)
+ (*conn)->tag8021q = tag;
+ }
+
/* Inform application that connection was created */
if (this->cb_connect)
this->cb_connect(*conn);

2) the uam authentication clients won't get login page,

this is not a bug of coova-chilli. Certain network cards and driver does not support oversized MTU 1518. Find the right network card and driver. There is a small problem with VLAN after coova chilli increase the mtu size, if it get aborted and restarted, there will be an error about the MTU mismatch or something like that. 'down.sh' should resize the MTU back to normal.

Regards.

Wed, 07/29/2009 - 08:27 — david

Thanks. For 1), this is

Thanks. For 1), this is perhaps better:
dhcp_checktag(*conn, pkt);

For 2), for a network card/driver that does not auto-adjust to a hiigher MTU, you will have to ensure that packets are smaller than normal, to account for the extra VLAN tagging. You can do this now with the tcpmss option to chilli - which will clamp down TCP connections to a smaller MSS (set it to something like 1400, for instance).

Thu, 07/30/2009 - 04:06 — mctiew

There are many places in the

There are many places in the dhcp.c file have dhcp_checktag() and perhaps with the inclusion of check_tag into dhcp_newconn(), some other dhcp_checktag() maybe redundant ?

Navigation