RE: [lwip-users] DHCP and changing the MAC address

[Tom C. Barker]

Leon,

Gratuitous ARP: Up through 0.7.2, I show no code in netif_set_ipaddr
that uses etharp_query(netif, ipaddr, NULL). Outside of the cmp for 
different addresses this code would otherwise get called on 
initialization ( but fails because the link output function is not set up yet).

Implemented in dhcp at the end of dhcp_bind, 

  /* netif is now bound to DHCP leased address */
  dhcp_set_state(dhcp, DHCP_BOUND);

  etharp_query(netif, &dhcp->offered_ip_addr, NULL);

The arp entry on my PC client _does_ get updated! 
Following is a dump ( which performs 4 calls ) is this correct?

No. Time        Source           Destination      Protocol Info
51  9.375649  Qualstar_ff:ff:07  Broadcast        ARP      Who has 
216.101.63.200?  Tell 0.0.0.0
52  9.805944  Qualstar_ff:ff:07  Broadcast        ARP      Who has 
216.101.63.200?  Tell 0.0.0.0
53  10.314237 Qualstar_ff:ff:07  Broadcast        ARP      Who has 
216.101.63.200?  Tell 0.0.0.0
55  10.822746 Qualstar_ff:ff:07  Broadcast        ARP      Who has 
216.101.63.200?  Tell 216.101.63.200


I have also added etharp_query(netif, &dhcp->offered_ip_addr, NULL) to my
change-MAC-on-a-static-IP routine also and that works as well.

Let me know if there is any other testing I might be able to do.

Tom








-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf
Of Leon Woestenberg
Sent: Sunday, June 27, 2004 9:41 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] DHCP and changing the MAC address


Tom,

Tom C. Barker wrote:
> Leon,
> 
> 1. UDP or TCP?
> 
>    The pcbs being zeroed are tcp.
 >
OK.

> 2. Can you submit back what you did?

>    If I have "216.101.63.206        00-08-4f-ff-ff-0f     dynamic" in my 
>    client arp table and I change the MAC in the FTP server to 
> 00-08-4f-ff-ff-0e,
>    the DHCP server may give the FTP server 216.101.63.206 for an arp entry of
>    "216.101.63.206        00-08-4f-ff-ff-0e     dynamic". At this point the
>    client would never find the server until the arp entry timed out. To 
> expedite,
 >
OK, I am assuming the server is running lwIP here and the client is some 
other host. What the server (lwIP) could do is emit a "gratuitious ARP" 
message to update the ARP table of hosts on the local network.

You may want to enable this piece of code in netif_set_ipaddr():
#if 0 /* only allowed for Ethernet interfaces TODO: how can we check? */
   /** For Ethernet network interfaces, we would like to send a
    *  "gratuitous ARP"; this is an ARP packet sent by a node in order
    *  to spontaneously cause other nodes to update an entry in their
    *  ARP cache. From RFC 3220 "IP Mobility Support for IPv4" section 4.6.
    */
   etharp_query(netif, ipaddr, NULL);
#endif

It sends an ARP request which always carries its own IP/MAC source 
address. The contents of the rest of the message do not really care BTW.

All local hosts should update their ARP table.

>    I clean my arp table and browse to the FTP server and I get a proper 
> response.
 >
Using the above, you should no longer need to do this manually.

>    Clearly there would be no issue if the new MAC address were awarded a 
> previously
>    unbound arp entry such as "216.101.63.207        00-08-4f-ff-ff-0e     
> dynamic"
>
OK, understandable. But we neatly released the DHCP *.206 lease, so we 
cannot really control what DHCP gives us.

> 3. Look in netif_set_addr() or whatever it is called. I think we try to 
> maintain 
>    UDP PCB over an IP address change, and close TCP PCBs.
>
Only connected TCP PCBs are closed. See netif_set_ipaddr(). I am not 
sure if it is safe to carry over connected PCB's to a new address.

>    Also, I think that it is release() that does what I was needing done: 
> zeroing 
>    the lpcb local addresses so that the newly assigned address will be 
> transferred
>    due to the fact that the lpcb local address of zero is equal to the new 
> netif
>    local address of zero.
>
I am not sure if this was intentional by design.

When netif_set_ipaddr(netif, 0.0.0.0) is called on a non-0.0.0.0 
interface, I think we should act in a defined manner. (and maybe follow 
hat BSD is doing - which I have no clue of in this particular case).

What we really want is an interface UP and DOWN state, to work around
abusing 0.0.0.0 as DOWN.

> If I can answer any questions of comment on anything else I've done or 
> observed,
> let me know.
> 
You might try enabling the gratuitous ARP implementation to see if it 
works and telling me so :-)

Regards,

Leon.

> Thanks for your help,
> Tom
> 
> 
> 
> 
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf
> Of Leon Woestenberg
> Sent: Friday, June 25, 2004 5:44 AM
> To: Mailing list for lwIP users
> Subject: RE: [lwip-users] DHCP and changing the MAC address
> 
> 
> Tom,
> 
> On Fri, 2004-06-25 at 01:45, Tom C. Barker wrote:
> 
>>I think I have found the issue. Your original suggestion 
>>of using dhcp_release was the way to go. Again, because
>>it was a static and not listed in the .h file, I assumed 
>>I was not to use it. 
>>
> 
> The code is not fully clean there yet; we really should delete
> state information in dhcp_release().
> 
> Also, I intended to allow dhcp_start() on existing leases; this
> is not handled properly yet without a dhcp_stop() and release().
> 
> I will submit some code in the next week or so that fixes this.
> You may want to keep an eye on that.
> 
> 
>>My listening pcbs are zeroed now so the new Ip address 
>>is transferred properly!
>>
> 
> UDP or TCP?
> 
> 
>>The only other issue was fixing up my local arp table after I 
>>change the MAC. Deleteing the arp entry in the client and 
>>performing a ping on the ( lwIP-based ) server gets the arp
>>table entry corrected. From there I am able to access my services.
>>
> 
> Can you submit back what you did? I think an arp_query() is more
> clean to do here instead of the ping.
> 
> 
>>Can you confirm how the zeroing of the lpcb takes place? 
>>I could not find it. (Or at least confirm what I'm seeing is true?)
>>
> 
> Look in netif_set_addr() or whatever it is called. I think we try
> to maintain UDP PCB over an IP address change, and close TCP PCBs.
> 
> I am not sure though, I do not have the time to inspect the source
> code right now.
> 
> Regards, Leon.
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users