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

[Leon Woestenberg]

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