IP address conflicts

[Gunther Mayer]

David Bird wrote:
>
> On Sep 12, 2007, at 10:32 AM, Gunther Mayer wrote:
>>> That net for chilli is probably ok, but misleading as chilli does 
>>> not actually calculate its dhcp range from the CIDR network (like it 
>>> should).
>> How the heck does chilli calculate its range then if dhcpstart and 
>> dhcpend is not given?
>
> Both the options have defaults.... so, it isn't very optimal. This 
> part of chilli needs more attention as there are numerous places where 
> the uamlisten (or dhcplisten) is assumed to be net + 1 (meaning, the 
> first IP in your net range).
>
> I took a closer look at this part of chilli and found a few more 
> places where the wrong assumption (net + 1) is made. I also made some 
> changes in that dhcpstart and dhcpend will default to off (i.e. 0) and 
> the entire net will be used for DHCP otherwise (minus, the _correct_ 
> uamlisten which does not have to be net + 1). The start and end 
> options can then be used together or separately to limit the range.
Awesome, that sounds more like the behaviour I would expect. Thanks for 
making those changes, I will give them a spin in 1.0.8 ;-)
>
>>> I don't believe anything relevant was change din 1.0.7, but the 
>>> current svn version has some more cleanups.
>> Ok, after some more digging in my logs I think I found the culprit 
>> (not coova's fault). I'm trying to run "repeaters" to extend my 
>> wireless coverage, but they are actually the ones causing all the 
>> havoc. You see, I run my "repeaters" in client/ap mode on a WRT54GL, 
>> that is, one client interface  (wl0) associating with the 
>> uplink(main) a/p, one a/p interface (wl0.1) for distributing the 
>> signal locally, both being attached to the standard br-lan bridge.
>>
>> root at OpenWRT:~# brctl show
>> bridge name     bridge id                STP enabled     interfaces
>> br-lan                8000.001839bc7965       no            eth0.0
>>                                                                       
>>             wl0
>>                                                                       
>>             wl0.1
>>
>> Now here's the problem: One particular such node has a wl0 (or wl0.1) 
>> mac address of 00-18-39-BC-79-82. This is what I see in my logs on 
>> numerous occasions:
>>
>> Sep 12 04:07:12 41.245.146.170 chillispot[566]: chilli.c: 2602: New 
>> DHCP request from MAC=00-18-39-BC-79-82
>> Sep 12 04:07:12 41.245.146.170 chillispot[566]: chilli.c: 2564: 
>> Client MAC=00-18-39-BC-79-82 assigned IP 172.25.0.119
>>
>> followed by successful logins of certain users. Note that the MAC is 
>> of the repeater, not the client. Therefore the first client to 
>> associate to the repeater and request a dhcp lease from the network 
>> gets assigned a correct one by chilli, subsequent clients on that 
>> same repeater get assigned the duplicate one since chilli sees the 
>> same mac. These people then have no way of connecting.
>>
>> To the best of my knowledge a pure bridge just transparently forwards 
>> packets on layer 2 and *does not* mess with mac addresses of these 
>> packets. In this case my bridge does, so I think I found a bug in 
>> kamikaze 7.07.
>>
>> I don't necessarily expect people in this list to help me out here, 
>> perhaps I should rather post this on the OpenWRT forums.
>
> Hmm.. what kind of iptables config do you have (in filter and nat)?
Silly me, it isn't a bug but rather comes down to client/ap "repeater" 
mode not being able to bridge properly because of the very nature of 
802.11 headers. WDS must be used if correct dhcp operation is required. 
And I thought I was being clever by using "repeater" mode to get around 
the chores of setting up WDS on either side... Back to the drawing board 
for me :-(

More information here: 
http://forum.openwrt.org/viewtopic.php?pid=53924#p53924

Gunther