[Dnsmasq-discuss] rfc3527 support

[Takayuki Kaiso]

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




> Takayuki Kaiso wrote:
>> Hi,
>>
>> I needed to apply the following patch to work with decp relay which is using
>> rfc3527 link selection sub option.
>>
>> As far as I looked around dhcp.c, complete_context() failed to locate the
>> target context because parm.relay is set to be mess->giaddr even though
>> we should use the subnet address specified in link-selection sub option.
>>
>> I think we also need to do the similar thing also for rfc3011 handling,
>> and I will take care of it if I get review on this patch by any of you.
>>
> What was the problem you are fixing? Confusingly, RFC3527 and RFC3011
> subnet selection are handled much later in the call-chain: the code
> starts around line 190 in rfc2131.c. If there's a problem (which is, of
> course, possible) it should be fixed in that code.
>
> Cheers,
>
> Simon.
>