DHCP Relay Agent Not Forwarding DHCPOFFER
I have written a custom DHCP server intended for the provisioning of SIP handsets. When tested locally (with broadcast requests), it works perfectly, but when used via a relay agent, the DHCPOFFER messages are not being forwarded from the relay to the client (the DHCPDISCOVER messages arrive at the server just fine).
I have absolutely no idea why this is. I have eliminated the router as the cause by testing it with several different networks and I can only assume that the problem is due to the contents of the DHCPOFFER message. Is there a specific way in which these need to be different from a normal broadcast response in order to be accepted?
I've checked the flags, giaddr, hops, lease time (option 51), tried ignoring and echoing option 82, you name it - makes no difference.
I have absolutely no idea why this is. I have eliminated the router as the cause by testing it with several different networks and I can only assume that the problem is due to the contents of the DHCPOFFER message. Is there a specific way in which these need to be different from a normal broadcast response in order to be accepted?
I've checked the flags, giaddr, hops, lease time (option 51), tried ignoring and echoing option 82, you name it - makes no difference.
fmonroy
I don't know that RFC, but, have you tried to capture and compare packets from both, your DHCP server, and from an "official" DHCP server?
The DHCP Discover message is broadcast from the client and picked up by the relay agent, the relay agent then sends a unicast to the DHCP server. The DHCPOffer is sent as a unicast message from the DHCP server to the relay agent, then the relay agent sends it out as a broadcast. Your comment "When tested loaccly (with broadcast requests, it works perfectly.." would indicate that there is not an issue with accepting broadcasts. Just a thought, and apologies if "sucking eggs" comes to mind!
ASKER
Just to clarify: the local / broadcast I was referring to was without a relay agent in which case everything works.
THe unicasts from the relay are picked up correctly. The unicasts sent back to the relay (DHCPOFFER) never reach the client.
get ethereal, catch the packets and compare them
Gotta agree with fmonroy, ethereal would be my next point of call to identify what is happening
ASKER
I have done traces at both ends. Traffic is fine between the relay and server, but there is definately nothing being returned from the relay to the client. I have also compared the packets with those from other dhcp servers and theyre identical.
What else could would cause the packets to be rejected by the relay?
What else could would cause the packets to be rejected by the relay?
Wolfy, what is your relay agent (make / model) and any chance we can see one of the packets from the DHCP server to the relay agent (i.e. one which is not being forwarded after receipt on the relay agent)
ASKER
This one is not ideal but it should give you what you need:
http://www.stonewolfsoft.co.uk/projects/sipswitch/dhcptest.pcap (wireshark trace)
Client: Snom 320
Relay: Solwise SAR600EW (192.168.1.1)
Server: Local PC (192.168.1.4)
Because everything here is on the local network the server is set to ignore broadcast packets and only respond to the relay.
http://www.stonewolfsoft.co.uk/projects/sipswitch/dhcptest.pcap (wireshark trace)
Client: Snom 320
Relay: Solwise SAR600EW (192.168.1.1)
Server: Local PC (192.168.1.4)
Because everything here is on the local network the server is set to ignore broadcast packets and only respond to the relay.
Cheers Wolfy I will look at it at and get back to you
ASKER
I'm upping the points for this as I need an answer soon.
Wolfy, just taking a look at the trace, sorry for the delay. Just a quick question again apologies if "sucking eggs" comes to mind, you have allowed UDP 67 OUT of the relay on the client side and not just IN on the client?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I also tested it on an external server (different network) with the same results. The reason I'm sticking with the local tests is because its less hassle (have to remote desktop to the other one).
The only other thing I can think of was when I first tested it, my PC's firewall had some issues with UDP checksums - but I dont know how to check that.
The only other thing I can think of was when I first tested it, my PC's firewall had some issues with UDP checksums - but I dont know how to check that.
ASKER
Finally got it working!
I needed to forward incoming traffic on port 67 to 192.168.1.1 (you would think the router would have done that seeing as it was set for relay and all).
DeanC30: What you said about the server being on the same subnet is correct because the above only worked using an external server meaning traffic going straight to 192.169.1.1 from the local network was being ignored - so the points are yours. Enjoy :)
I needed to forward incoming traffic on port 67 to 192.168.1.1 (you would think the router would have done that seeing as it was set for relay and all).
DeanC30: What you said about the server being on the same subnet is correct because the above only worked using an external server meaning traffic going straight to 192.169.1.1 from the local network was being ignored - so the points are yours. Enjoy :)
cheers Wolfy, appreciate it.