Very slow change of IP in kernel (slow socket?).

Very slow change of IP in kernel (slow socket?).

[Andrea G Forte]

Hi all,

after some talking I decided to try again and post a specific thread for 
this problem.
I noticed that when I change IP address for the same wireless card 
(since I am moving to a different subnet I need a new IP), the actual 
change in the kernel happens between 300 to 500 ms later. In particular, 
after changing the IP (ip route add...) and updating route table and 
default gw, the actual data packets are sent using the new IP only after 
300 to 500 ms after setting all the above.
Does anyone of you know what this could be related to? Or, does anyone 
of you know where in the kernel code I could start looking for some answers?
I have already had some feedback with suggestions to look into the 
route_cache, however this does not seem to me as a route problem but 
more as a socket problem and perhaps some kind of timer that is set to 
refresh the socket info in the kernel.

Any help would be really appreciated.

Thanks all,
Andrea

Re: Very slow change of IP in kernel (slow socket?).

[bert hubert]

On Tue, Dec 21, 2004 at 04:29:58PM -0500, Andrea G Forte wrote:

> Does anyone of you know what this could be related to? Or, does anyone 

'ip route flush cache' may help.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

Re: Very slow change of IP in kernel (slow socket?).

[Martijn van Oosterhout]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

Seems long, but have you condered other possible delays, like ARP,
routing daemons, etc. BTW, I don't quite understand what you mean by
changing IPs, because "ip route add" adds routes, not IPs. Presumably
you're using an unbound UDP socket. You need to be a bit clearer about
what you're actually trying to do...

On Tue, Dec 21, 2004 at 04:29:58PM -0500, Andrea G Forte wrote:
> Hi all,
> 
> after some talking I decided to try again and post a specific thread for 
> this problem.
> I noticed that when I change IP address for the same wireless card 
> (since I am moving to a different subnet I need a new IP), the actual 
> change in the kernel happens between 300 to 500 ms later. In particular, 
> after changing the IP (ip route add...) and updating route table and 
> default gw, the actual data packets are sent using the new IP only after 
> 300 to 500 ms after setting all the above.
> Does anyone of you know what this could be related to? Or, does anyone 
> of you know where in the kernel code I could start looking for some answers?
> I have already had some feedback with suggestions to look into the 
> route_cache, however this does not seem to me as a route problem but 
> more as a socket problem and perhaps some kind of timer that is set to 
> refresh the socket info in the kernel.
> 
> Any help would be really appreciated.
> 
> Thanks all,
> Andrea
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Very slow change of IP in kernel (slow socket?).

[Andrea G Forte]

Yes, I apologize for the confusion.
I am trying to achieve a faster L3 handoff on a wireless network. Right 
now it seems like one of the biggest bottlenecks is in the kernel.
After I change IP address of the client (ip address add 
xxx.xxx.xxx.xxx/yy dev wlan0) and update all the routing info (ip route 
replace default via zzz.zzz.zzz.zzz, ip route replace kkk.kkk.0.0/yy dev 
wlan0 proto kernel src xxx.xxx.xxx.xxx), the old IP is still used to 
send packets as I mentioned earlier.
Note that I did not delete the old IP, I just set a new IP and changed 
the routing info. The old IP however it is invalid in the new subnet, 
but the kernel does not seem to realize it at all, at least for about 
500ms (even though I have changed all the routing info with the new IP).
Yes, perhaps it could be a problem related to the routing table being 
slow to update.
I will do some more testing and let you know.

Thank you,
Andrea



Martijn van Oosterhout wrote:

>Seems long, but have you condered other possible delays, like ARP,
>routing daemons, etc. BTW, I don't quite understand what you mean by
>changing IPs, because "ip route add" adds routes, not IPs. Presumably
>you're using an unbound UDP socket. You need to be a bit clearer about
>what you're actually trying to do...
>
>On Tue, Dec 21, 2004 at 04:29:58PM -0500, Andrea G Forte wrote:
>  
>
>>Hi all,
>>
>>after some talking I decided to try again and post a specific thread for 
>>this problem.
>>I noticed that when I change IP address for the same wireless card 
>>(since I am moving to a different subnet I need a new IP), the actual 
>>change in the kernel happens between 300 to 500 ms later. In particular, 
>>after changing the IP (ip route add...) and updating route table and 
>>default gw, the actual data packets are sent using the new IP only after 
>>300 to 500 ms after setting all the above.
>>Does anyone of you know what this could be related to? Or, does anyone 
>>of you know where in the kernel code I could start looking for some answers?
>>I have already had some feedback with suggestions to look into the 
>>route_cache, however this does not seem to me as a route problem but 
>>more as a socket problem and perhaps some kind of timer that is set to 
>>refresh the socket info in the kernel.
>>
>>Any help would be really appreciated.
>>
>>Thanks all,
>>Andrea
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-net" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>    
>>
>
>  
>