>> >> This patch is just a start, there are two remaining calls to >> "clear_packet" >> which I did not feel comfortable with touching: >> >> - line 439 : the subsequent call to do_options() forcibly passes NULL as >> the agent_id, so it seems the Relay Agent info is discarded => why? > > That code is BOOTP (as opposed to DHCP) specific. Agent Ids aren't > relevant there, and agent_id will always be NULL at that point. OK and the code is now clearer with your clear_packet(mess, end, NULL) call. > I guess this para from RFC 3046 indicates that it supercedes 2131: > > The relay agent MAY use this field in addition to or instead of the > Agent Circuit ID field to select the circuit on which to forward the > DHCP reply (e.g., Offer, Ack, or Nak). DHCP servers SHOULD report > this value in any reports or MIBs associated with a particular > client. > Agreed, and it's a good thing the RFC leans this way, because otherwise the relay agent would not be able to figure out where to relay the DHCPNAK! In my case I am using the Circuit Agent ID to store the interface on which the DHCP Request was received. > I've made a test release at > http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.42test3.tar.gz > > which I think addresses everything. Please could you try it? That's a > tarball which includes a /debian directory. Shout if you'd rather have > a .deb > I have just picked up and tried your test release, and it works fine for me, both for a DHCPOFFER and a DHCPACK.
Mar 31 11:46:44 blini dnsmasq[9536]: sent size: 6 option: 82:agent-id 01:04:00:00:00:03 Any idea how can I trigger a DHCPNAK to test that case too? Cheers, Jeremy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
