[Dnsmasq-discuss] rfc3527 support
Takayuki Kaiso
tkaiso2 at thinktube.com
Fri May 6 05:14:26 BST 2011
Hi, Simon
Ok, I did the same test using dnsmasq-2.58test6. this version improves a bit , but not good enough.
I will show my test result with dnsmasq-2.58test6 and want you to look at your codes to push me ahead. thanks.
(1) dnsmasq-2.58test6 improved only for Server Identifier field problem, but siaddr is still left as 0.
Regarding Server Identifier field, I saw the following codes (line 714) in dnsmasq-2.58test6 contributed this
improvement.
--------------------------------------------------------------------------------------------------------------
/* If configured, we can override the server-id to be the address of the relay,
so that all traffic goes via the relay and can pick up agent-id info. This can be
configured for all relays, or by address. */
if (daemon->override && mess->giaddr.s_addr != 0 && override.s_addr == 0)
{
if (!daemon->override_relays)
override = mess->giaddr;
else
{
struct addr_list *l;
for (l = daemon->override_relays; l; l = l->next)
if (l->addr.s_addr == mess->giaddr.s_addr)
break;
if (l)
override = mess->giaddr;
}
}
-----------------------------------------------------------------------------------------------------------------
(2) To investigate the reason that "siaddr" is left 0 field,
I put the three my_syslog lines shown below. (around line 990 in rfc2131.c)
------------------------------------------------------------------------------
my_syslog(MS_DHCP | LOG_INFO, _("@@ set OPTION_SERVER_IDENTIFIER in dhcp_reply() @@ context->local=%s \n"),
inet_ntoa(context->local)) ;
my_syslog(MS_DHCP | LOG_INFO, _("@@ set OPTION_SERVER_IDENTIFIER in dhcp_reply() @@ context->router=%s \n"),
inet_ntoa(context->router)) ;
my_syslog(MS_DHCP | LOG_INFO, _("@@ set OPTION_SERVER_IDENTIFIER in dhcp_reply() @@ server_id=%s \n"),
inet_ntoa(server_id(context, override, fallback)) ) ;
option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ, ntohl(server_id(context, override, fallback).s_addr));
-----------------------------------------------------------------------------
then, got the following result.
mess->siaddr is actually filled in by just copying context->local (as you see, in do_options() )
and the last two my_syslog output below tell us the reason why mess->siaddr is left as 0.
this is just because context->local is 0.
Mar 4 21:50:14 RMRZOO-81 daemon.info dnsmasq-dhcp[31469]: @@ set OPTION_SERVER_IDENTIFIER in dhcp_reply() @@
context->local=0.0.0.0
Mar 4 21:50:14 RMRZOO-81 daemon.info dnsmasq-dhcp[31469]: @@ set OPTION_SERVER_IDENTIFIER in dhcp_reply() @@
context->router=0.0.0.0
Mar 4 21:50:14 RMRZOO-81 daemon.info dnsmasq-dhcp[31469]: @@ set OPTION_SERVER_IDENTIFIER in dhcp_reply() @@
server_id=10.0.1.81
Mar 4 21:50:14 RMRZOO-81 daemon.info dnsmasq-dhcp[31469]: @@ do_options() @@ context->local=0.0.0.0
Mar 4 21:50:14 RMRZOO-81 daemon.info dnsmasq-dhcp[31469]: @@ do_options() @@ context->router=0.0.0.0
(3) How to fix the siaddr problem described in (2),
In my mind, there are two candidate place to put the fix,
one place is complete_context() in dhcp.c and the another place
is around line 265 in rfc2131.c where context_new is built and
replaces context with it.
You suggested me that the latter is cleaner and I see your point.
If we do not need to maintain the target context earlier in dhcp.c,
I completely agree with you.
then,
to implement the fix in rfc2131.c, I think it is better to pass "iface_addr" from dhcp.c when
calling dhcp_reply() in order to avoid executing ioctl() to get the local interface address again
in rfc2131.c
what is your opinion ?
Please any kind of suggestions.
thanks a lot
Takayuki Kaiso
> Takayuki Kaiso wrote:
>> Hi, Simon
>>
>> Thank you for your suggestion.
>> let me explain more details.
>>
>> < configuration>
>> 1. DHCP client is iPod touch (supposed to be get 192.168.5.x
>> from DHCP server )
>> 2. DHCP relay is running on a WiFi AP (AP is 192.168.5.1 and
>> another interface
>> connected to the DHCP server is 10.0.1.82 ).
>> RFC3527 is implemented on this relay.
>> 3. DHCP server (actually, dnsmasq) is running on a openwrt
>> embedded board.
>> it is connected to DHCP relay and the interface is
>> configured 10.0.1.81
>>
>> therefore, giaddr is 10.0.1.82 and SUBNET_SELECT address is
>> 192.168.5.1
>> in DHCPDISCOVER message.
>>
>> < problem summary>
>>
>> - iPod send DHCPDISCOVER and received DHCPOFFER, but in the DHCPOFFER
>> message, siaddr field is blank and Server identifier option field
>> has 0.
>> I believe both of these field must have valid address in DHCPOFFER.
>>
>> When iPod received such incomplete reply, it did not send
>> DHCPREQUEST.
>>
>> - I used wireshark to investigate the those problematic field in
>> DHCPDISCOVER and
>> DHCPREQUEST.
>>
>> < investigation around the source codes>
>>
>> - Yes, I looked around line216 and line 2216 in rfc2131.c
>> and also put some prrinf for debugging.
>> - such debugging showed me context-local was 0
>> even though codes in rfc2131 successfully located the
>> target context using SUBOPT_SUBNET_SELECT.
>>
>> - Why context-local was 0 ? then I looked into dhcp.c to find
>> the place the context filed is built.
>> I think it is complete_context() function, then I put printf
>> debugging here again
>> and found it failed to locate the target context because
>> param-relay.s_addr
>> is 10.0.1.82.
>>
>> I am not confident that my patch is clean because I have not yet had
>> big and precise picture on those codes. So please correct me if I miss
>> something.
>>
>> I updated dhcp.c in my patch because context-router and context-local
>> are checked in other places and (ex. line 968 in dhcp.c ) and I thought
>> setting up those two fields in dhcp.c looks safer for me.
>>
>> I definitely need your suggestion, Simon.
>>
>> Thanks
>> Takayuki Kaiso
>>
>>
> The "server identifier is zero when using a DHCP relay" rings bells.
> This came up here:
>
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2011q1/004806.html
>
> and was fixed the 2.58test series:
>
> http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.58test6.tar.gz
>
> I don't think your problem is identical, but it may very likely have the
> same underlying cause and the difference in symptoms is because you are
> using subnet select. Please could you try dnsmasq-2.58test6 as a
> baseline, and we'll take the debugging process from there?
>
> Cheers,
>
> Simon.
>
>
>
More information about the Dnsmasq-discuss
mailing list