IP address conflicts

[David Bird]

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.

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

David