lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom C. Barker
Subject: RE: [lwip-users] DHCP and changing the MAC address
Date: Fri, 25 Jun 2004 09:57:31 -0700

Leon,

1. UDP or TCP?

   The pcbs being zeroed are tcp. They are listening for connections
   for FTP and HTTP. I have other services (UDP), but they are not
   running currently. I'll check them on the next implementation round.

2. Can you submit back what you did?
   lwIP is running as, among other things, an FTP server and an HTTP server.
   When the client browses to my server project, the arp entry is set. If I 
   then change the MAC, the client will never find the new MAC IF the DHCP 
   server gave the same IP to the new MAC. ( I think this may have been what
   was confusing in what I said last time ).

   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,
   I clean my arp table and browse to the FTP server and I get a proper 
response.
   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"

   Hope that makes sense.

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.
  
   That does not look like the case right now and I hope it is not a new 
strategy
   because the way the code works now is giving a good response.

   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.

If I can answer any questions of comment on anything else I've done or observed,
let me know.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]