Cisco WLAN controller 4400 and dhcp relay

[wlanmac]

I updated the Subversion with the latest changes.. I checked the ARP
replies... looks like I already fixed it. 

The new chilli does some things a bit differently. You'll find a new
utility, called chilli_opt, which is the only binary that is linked with
the configuration parsing (code generated by gengetopt). chilli server
will launch this to parse out and build up a binary configuration file.
chilli server will then re-read this configuration file, loading in the
new configuration without any delays (no more stalling for DNS
lookups). 

Enjoy,
David


On Mon, 2009-07-06 at 11:38 +0200, Thomas Liske wrote:
> Hi,
> 
> karczewski cyrill wrote:
> > Hello everyone!! I hope you are fine!!
> > 
> > I have a problem with coova-chilli 1.0.13 and i will be so gratefull for anyone find a solution.
> > 
> > I use a cisco WLAN controller 4400 with vlans configured. in order to transmit dhcp requests in that vlan, cisco has a dhcp relay.
> > 
> > the problem is that before transmit dhcp requests to chilli, the cisco controller does an ARP request to chilli.
> > 
> > Chilli reply, but the cisco controller doesn't like this answer.
> > 
> > In fact, when chilli reply, in the ARP target address field, chilli put 0.0.0.0 instead of the cisco controller ip address. It send the ARP reply in broadcast mode.
> > 
> > So, the cisco controller send an ARP request again and again...
> > 
> > here is the cisco request:
> > 
> > http://picasaweb.google.com/cyrill51/Chillispot#5355257375354395602
> > 
> > here is the reply
> > 
> > http://picasaweb.google.com/cyrill51/Chillispot#5355257377945980914
> > 
> > Anyone has an idea to correct this in chilli or in the cisco controller.
> > 
> 
> it seems to be an issue on the WLC implementation. According to RFC826 
> the WLC should accept the arp reply with an zero target address:
> 
> 
> ==============================[RFC826]==============================
> ?Do I have the hardware type in ar$hrd?
> Yes: (almost definitely)
>    [optionally check the hardware length ar$hln]
>    ?Do I speak the protocol in ar$pro?
>    Yes:
>      [optionally check the protocol length ar$pln]
>      Merge_flag := false
>      If the pair <protocol type, sender protocol address> is
>          already in my translation table, update the sender
> 	hardware address field of the entry with the new
> 	information in the packet and set Merge_flag to true.
>      ?Am I the target protocol address?
>      Yes:
>        If Merge_flag is false, add the triplet <protocol type,
>            sender protocol address, sender hardware address> to
> 	  the translation table.
>        ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
>        Yes:
> 	Swap hardware and protocol fields, putting the local
> 	    hardware and protocol addresses in the sender fields.
> 	Set the ar$op field to ares_op$REPLY
> 	Send the packet to the (new) target hardware address on
> 	    the same hardware on which the request was received.
> ==============================[RFC826]==============================
> 
> There are no checks on the target address for ARP replies. The arp reply 
> is btw not send as a broadcast, there is the WLC's ARP address specified 
> as the destination address in the ethernet header.
> 
> I'd just checked Linux's implementation on sending ARP replies, it sets 
> the target IP address to the original request source address. Maybe it 
> should be fixed in cc to perform as other common ARP implementations 
> perform.
> 
> 
> Regards,
> Thomas
>