Hi Simon
Thank you.
I did the test with dnsmasq-2.58test8, which gave me the URL and
got the following problem with DHCPREQUEST.
Mar 4 21:23:17 RMRZOO-81 daemon.info dnsmasq-dhcp[19120]: DHCPDISCOVER(wlan1)
00:1e:52:ab:77:fd
Mar 4 21:23:17 RMRZOO-81 daemon.info dnsmasq-dhcp[19120]: DHCPOFFER(wlan1)
192.168.5.161 00:1e:52:ab:77:fd
Mar 4 21:23:18 RMRZOO-81 daemon.info dnsmasq-dhcp[19120]: DHCPREQUEST(wlan1)
192.168.5.161 00:1e:52:ab:77:fd
Mar 4 21:23:18 RMRZOO-81 daemon.info dnsmasq-dhcp[19120]: DHCPNAK(wlan1)
192.168.5.161 00:1e:52:ab:77:fd wrong network
Mar 4 21:23:18 RMRZOO-81 daemon.info dnsmasq-dhcp[19120]: DHCPREQUEST(wlan1)
192.168.5.161 00:1e:52:ab:77:fd
Mar 4 21:23:18 RMRZOO-81 daemon.info dnsmasq-dhcp[19120]: DHCPNAK(wlan1)
192.168.5.161 00:1e:52:ab:77:fd wrong network
As long as I saw the source code, (after line 1100 in rfc2131.c) ,
it checks the validity of DHCPREQUEST with "context", but it failed
because we still did not update target context in complete_context().
Just for making sure of my thought, I added the following two lines
temporarily where
context->local is updated with fallback and did the same test again.
then, it worked and got DHCPACK.
------------------------------------------------------------
case DHCPREQUEST:
+ backup_context_local = context->local;
+ context->local = fallback ;
if (ignore || have_config(config, CONFIG_DISABLE))
return 0;
..........
..........
+ context->local = backup_context_local ; /* really necessay ? */
------------------------------------------------------
I do not think this temporary update can be a clean solution, but
this is what came up to my mind to complete "fallback" solution
as you are now taking.
Simon, I think your codes has so much dependency on "context" objects and
stand on the assumption "context". correct ?
Thanks,
Takayuki Kaiso
P.S.
When a DHCP server has more than one interfaces from which DHCP packets
come in, single context should have multiple "local" addresses corresponding
to
each interface.
