dhcrelay over wireless mesh
luca.tavanti at iet.unipi.it
Wed Jul 18 09:46:41 UTC 2012
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
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?
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).
More information about the dhcp-users