Re: Sockets and changing IP addresses
Archie Cobbs wrote: I'm curious what -net's opinion is on PR kern/38544: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 In summary: if you have a connected socket whose local IP address is X, and then change the interface IP address from X to Y, then packets written out by the socket will continue to be transmitted with source IP address X. Do people agree that this is a bug and should be fixed? Yes. The other end can't possibly reply to address X, so the connection is broken at this point. Do people agree that my suggestion of returning ENETDOWN is reasonable? Wow. There are other possibilities, EADDRNOTAVAIL or ECONNABORTED. It doesn't matter so long as it the errno is unique to this situation across all syscalls that might encounter it; ENETDOWN seems to meet this criteria. If so, what would be the most efficient way to implement this? Obviously we'd like to avoid searching the entire IP address list for every outgoing packet. Would it work to only do that search if the socket's cached route is invalid? Etc. My initial reaction is this should take care of the problem, but I haven't backed that up with any testing. SIOCSIFADDR on an interface does remove all routes for the interface and then rebuild routes for all now-existing addresses, so any cached routes on that interface will now be invalid. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
RE: Sockets and changing IP addresses
From: Wes Peters [mailto:[EMAIL PROTECTED]] Archie Cobbs wrote: I'm curious what -net's opinion is on PR kern/38544: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 In summary: if you have a connected socket whose local IP address is X, and then change the interface IP address from X to Y, then packets written out by the socket will continue to be transmitted with source IP address X. Do people agree that this is a bug and should be fixed? Yes. The other end can't possibly reply to address X, so the connection is broken at this point. I think the current behaviour is correct. Since the IP-MAC lookup will remain cached, the communication will continue to work to the old IP. Changing the IP on the connected socket will make the connection drop. The best case is the the way it works. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Sockets and changing IP addresses
On Thursday, November 21, 2002, at 01:16 PM, Wes Peters wrote: Archie Cobbs wrote: I'm curious what -net's opinion is on PR kern/38544: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 In summary: if you have a connected socket whose local IP address is X, and then change the interface IP address from X to Y, then packets written out by the socket will continue to be transmitted with source IP address X. Do people agree that this is a bug and should be fixed? Yes. The other end can't possibly reply to address X, so the connection is broken at this point. Do people agree that my suggestion of returning ENETDOWN is reasonable? Wow. There are other possibilities, EADDRNOTAVAIL or ECONNABORTED. It doesn't matter so long as it the errno is unique to this situation across all syscalls that might encounter it; ENETDOWN seems to meet this criteria. A thought: An attempt to reconnect will succeed, given the scenario above, and ENETDOWN implies that the network is unavailable, so I don't think this is a good response. ECONNABORTED might be better (and EADDRNOTAVAIL isn't really germane). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| If you're not confused, | You're not paying attention *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Sockets and changing IP addresses
Don Bowman wrote: I'm curious what -net's opinion is on PR kern/38544: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 In summary: if you have a connected socket whose local IP address is X, and then change the interface IP address from X to Y, then packets written out by the socket will continue to be transmitted with source IP address X. Do people agree that this is a bug and should be fixed? Yes. The other end can't possibly reply to address X, so the connection is broken at this point. I think the current behaviour is correct. Since the IP-MAC lookup will remain cached, the communication will continue to work to the old IP. Changing the IP on the connected socket will make the connection drop. The best case is the the way it works. What you're saying doesn't make sense to me. First of all, this has nothing to do with ARP tables (although you are right that the router's ARP entry for the old IP address will remain valid). Secondly, the communiation will NOT work because the host will drop packets sent to it with the (now) wrong IP address. The current behavior is bad because the application does not ever receive any notification that the socket it's using is no longer valid. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
RE: Sockets and changing IP addresses
From: Archie Cobbs [mailto:[EMAIL PROTECTED]] Sent: November 21, 2002 16:54 To: Don Bowman Cc: 'Wes Peters'; Archie Cobbs; [EMAIL PROTECTED] Subject: Re: Sockets and changing IP addresses Don Bowman wrote: I'm curious what -net's opinion is on PR kern/38544: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 In summary: if you have a connected socket whose local IP address is X, and then change the interface IP address from X to Y, then packets written out by the socket will continue to be transmitted with source IP address X. Do people agree that this is a bug and should be fixed? Yes. The other end can't possibly reply to address X, so the connection is broken at this point. I think the current behaviour is correct. Since the IP-MAC lookup will remain cached, the communication will continue to work to the old IP. Changing the IP on the connected socket will make the connection drop. The best case is the the way it works. What you're saying doesn't make sense to me. First of all, this has nothing to do with ARP tables (although you are right that the router's ARP entry for the old IP address will remain valid). Secondly, the communiation will NOT work because the host will drop packets sent to it with the (now) wrong IP address. The current behavior is bad because the application does not ever receive any notification that the socket it's using is no longer valid. I guess I was thinking of the transparent proxy case (e.g. Squid) where I have a ipfw fwd rule, and the socket is terminated locally. Changing the IP address of the interface shouldn't drop my proxied connection. --don ([EMAIL PROTECTED] www.sandvine.com) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Sockets and changing IP addresses
Wes Peters wrote: I'm curious what -net's opinion is on PR kern/38544: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 In summary: if you have a connected socket whose local IP address is X, and then change the interface IP address from X to Y, then packets written out by the socket will continue to be transmitted with source IP address X. Do people agree that this is a bug and should be fixed? Yes. The other end can't possibly reply to address X, so the connection is broken at this point. Now I've got a patch that fixes this problem for review, it's attached to the PR (please review at the above URL if interested). I chose EADDRNOTAVAIL as the error code because: (a) The phrase Can't assign requested address seems most appropriate (b) It's consistent with what happens when you try to use an IP address that never existed in the first place, e.g., with IP_SENDSRCADDR. (c) You don't normally get this error from a send/write, which is when you'll get it The implementation simply keeps a pointer in the inet PCB to the 'struct in_ifaddr' associated with the local IP address (if any). When this address is removed from the interface, we set the RTF_REJECT flag on it, and this is detected by the TCP and UDP layers. So the per-packet cost is the testing of one flag bit. Note that 'struct in_ifaddr' structures are reference counted, so they continue to exist even after being removed from the interface. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
