[Chilli] Fixed IP addresses for APs and DHCP for clients

Felipe Augusto van de Wiel felipe.wiel at hpp.org.br
Mon Jan 11 20:57:31 UTC 2010

Hash: SHA512

Hello! :)

On 10-01-2010 04:52, David Bird wrote:
> On Fri, 2010-01-08 at 19:41 -0200, Felipe van de Wiel wrote:
>> 	When I first deployed it where I work I was
>> thinking about using ISC DHCP (at that time, it was not
>> clear to me how Coova works). The idea was to provide,
>> from DHCP, the IP address for the APs, that way they
>> will have a "fixed IP", but once we need to change the
>> range we could do it remotely and automatically.
>> 	In other words, I would like to have a static
>> IP range that DHCP will send to the access points and
>> a dynamic IP range that DHCP will send to the clients,
>> but those ranges don't necessarily have to be a full
>> subnet like /25 or /28. The APs don't necessarily have
>> to access the Internet, we just need to access them to
>> check radio settings and config options.
>> 	With this message, I'm searching for some
>> orientation on the best approach to deal with the IPs.
>> From the documentation and forums I had the impression
>> that there are three possible approaches to achieve
>> the above described scenario.
>>  1) Use dynip and statip config options
>>  2) Use macallowed and Framed-IP-Address
>>  3) Use macauth and Framed-IP-Address
>> 	I think (2) would be the easiest to maintain
>> when we need to add more APs and would not waste IPs
>> from a subnet, since it is a moderately large change,
>> I'm checking with the list before trying to deploy it.

> It sounds like your APs will be in bridge mode?

	Not really. :)

	We are using a bunch of 3Com OfficeConnect
Wireless 54Mbps 11g (Model: WL-524), when we first
deployed them we were going to use static IPs,
defining it manually on each AP, the discussion led
us to the decision of use DHCP and based on the MAC
addresses give "static IPs".

	In that sense, APs are not in bridge mode,
but we don't expect them to navigate or anything
like that, my plan is jut to have access to their
management interfaces remotely.

> Either way, it isn't obvious really what solution
> is the "right" one. Changes are, you could have
> some options how you set it up.

	I was imagining something along those lines.

> If you are going to use Framed-IP-Address in MAC
> auth, then you will also need the option (in
> chilli 1.2.0) --strictmacauth ... this option was
> added to keep chilli doing what it does now: when
> DHCP request comes in, the first one is ignored
> while RADIUS is performed for MAC authentication.
> The DHCP is ignored, because chilli *might* learn
> of the correct IP to return from RADIUS. This,
> however, makes all clients connect a bit slower...
> as they all have to reissue a DHCP request after
> a timeout. Chilli was changed per default to just
> return the DHCP reply without waiting (MAC auth
> still happens, just after the client has an IP,
> which means Framed-IP-Address in MAC auth now
> requires the new option).
> I hope this is clear.

	This is clear, but it raises another question. :)

	We have a very particular setting here, we
provide Free Wi-Fi service to the company area (which,
BTW, is a hospital) using CoovaChilli, the idea is that
employees, patients, families and guests can use free
internet, for that reason we basically have a single
user and a modified captive portal that just requires a

	If I understood correctly, when I opt for
macauth the MAC addresses are used as users for RADIUS
and that is not what I want based on the previous
scenario, considering that I didn't like to waste some
address because of the range allocation (statip/dynip)
I'm inclined to use macallowed, that will mix the fixed
IP addresses with the single user web auth, and
eventually, if the company decides to auth more users
or limit some of them, the "mixed" solution still work.
Does it sound like a good plan? (At least until the
new options similar to ethers come to production).

Kind regards,
- -- 
Felipe Augusto van de Wiel <felipe.wiel at hpp.org.br>
Tecnologia da Informação (TI) - Complexo Pequeno Príncipe
http://www.pequenoprincipe.org.br/    T: +55 41 3310 1747
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Chilli mailing list