dhcrelay over wireless mesh

[Luca Tavanti]

After a bit of sniffing and tuning I finally succeeded in having the 
server assing the IP to remote nodes (i.e. node 3).

As most of you pointed out, the dhcrelay agents forwards the discover 
towards the server as unicast packets. Similarly, the server 
communicates with the relay by means of unicast packets.
So, a "routing" protocol is therefore necessary to build a path between 
the relay and the server and to transport the unicast bootp packets.

Yet, by sniffing the traffic, I've seen that in the last hop, i.e. from 
node 1 to 0, there seems to be a loop. Node 1 re-sends the discover 
packet already relayed by node 2 to the server several times, each time 
with increased hop-count, until the hop count field reaches the limit 
(currently set to 10).
The packets following the first seems to have the correct GI addr value 
(node-2 IP, as this is the actual bootp relay), but the IP address is 
set to node 1, as if node 1 agent re-relayed the discover.
Since the same occurs also for the offer, request and ack packets, I 
have a lot of useless overhead.
I thought this was due to the "-m forward" option I previously passed to 
dhcrelay.
So I launched it with:
root[/]# dhcrelay -4 -i wlan0 -m discard 192.168.10.1
but the "loops" are still there, which is really confusing... (even more 
confusing as the log on node 1 reports a series of "daemon.err dhcrelay: 
packet to bogus giaddr 192.168.10.2")

Any idea of why this is happening and how to prevent it?

L


On 11/07/12 17:13, Simon Hobson wrote:
> Luca Tavanti wrote:
>
>> Now, my setup is as follwos:
>>
>> ((( 0 ))) ((( 1 ))) ((( 2 ))) ((( 3 )))
>>
>> I put the dhcp server on node 0, and both a dhclient and a dhcrelay on
>> nodes 1,2,and 3.
>> In this way both nodes 1 and 2 gets an IP from the server (directly
>> for node 1, through the relay on node 1 for node 2).
>> Yet, node 3 never gets an IP.
>
> Use <your preferred packet sniffer> at the various network points to see
> what's being transmitted. In particular, see if a packet from node 3 is
> reaching node 0 at all, and if so, what it's GI Addr field contains.
> Also, look at how nodes 1 and 2 are getting their addresses.
>
> My guesses at what's going wrong ...
>
> The relay agent on node 1 is changing the GI Addr value in the packet,
> hence the reply doesn't go back to node 2 and so doesn't get broadcast
> back to the client.
>
> The server is getting confused by the GI Addr being on a locally
> connected network, is broadcasting the reply, and the relay agent on
> node 1 is relaying it to node 2 (for node 2 getting it's address).
>