We help IT Professionals succeed at work.

DHCP Relay Agent Not Forwarding DHCPOFFER

LordWolfy
LordWolfy asked
on
1,666 Views
Last Modified: 2008-01-09
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.
Comment
Watch Question

Commented:
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?

Commented:
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!

Author

Commented:

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.

Commented:
get ethereal, catch the packets and compare them

Commented:
Gotta agree with fmonroy, ethereal would be my next point of call to identify what is happening

Author

Commented:
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?

Commented:
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)

Author

Commented:
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.

Commented:
Cheers Wolfy I will look at it at and get back to you

Author

Commented:
I'm upping the points for this as I need an answer soon.

Commented:
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?
Commented:
Unlock this solution and get a sample of our free trial.
(No credit card required)
UNLOCK SOLUTION

Author

Commented:
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.

Author

Commented:
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 :)

Commented:
cheers Wolfy, appreciate it.  

Gain unlimited access to on-demand training courses with an Experts Exchange subscription.

Get Access
Why Experts Exchange?

Experts Exchange always has the answer, or at the least points me in the correct direction! It is like having another employee that is extremely experienced.

Jim Murphy
Programmer at Smart IT Solutions

When asked, what has been your best career decision?

Deciding to stick with EE.

Mohamed Asif
Technical Department Head

Being involved with EE helped me to grow personally and professionally.

Carl Webster
CTP, Sr Infrastructure Consultant
Empower Your Career
Did You Know?

We've partnered with two important charities to provide clean water and computer science education to those who need it most. READ MORE

Ask ANY Question

Connect with Certified Experts to gain insight and support on specific technology challenges including:

  • Troubleshooting
  • Research
  • Professional Opinions
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.