Re: 2.6.34: Problem with UDP traffic on lo + poll(?)

["Krzysztof Olędzki" <ole@ans.pl>]

On 2010-09-06 22:44, Krzysztof Olędzki wrote:
> On 2010-09-06 22:29, Eric Dumazet wrote:
>> Le lundi 06 septembre 2010 à 21:55 +0200, Krzysztof Olędzki a écrit :
>>
>>> Yes, conntrack is one of possibilities. However, this problem only
>>> manifests on 2.6.34 and never on 2.6.31 where iptables and conntrack
>>> configurations are identically. And of course, each time it is a
>>> different port.
>>>
>>> Please also note that this problem only exists when communication is
>>> handled over a loopback interface - I'm not able to trigger this from a
>>> remote host even if I run the test on two hosts (local&   remote)
>>> simultaneously.
>>>
>>
>> No particular error shown in "netstat -s" ?
> 
> No... :(
> 
> Udp:
>       8542243 packets received
>       489605 packets to unknown port received.
>       1 packet receive errors
>       4254527 packets sent
>       RcvbufErrors: 1
> 
>> port randomization on UDP changed in the past, and conntracking changed
>> a bit too ;)
> 
> I know but AFAIR all important changs were alredy included in 2.6.31.
> And again: there is no problem in quering DNS from a remote host:
>    [client 2.6.24.6]<-ethernet->  [server 2.6.34.6]
> 
> BTW: I have been able to reproduce this problem on a different, less
> critical host after upgrading its kernel to 2.6.34.6. Unfortunately I'm
> still not able to do in on my lab environment. :( Anyway, I'll try to
> catch "conntrack -E" output and see what conntrack thinks about such
> packets.

OK, got it:

*strace (1682.t.lan):
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.130.53")}, 28) = 0
poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "Gz\1\0\0\1\0\0\0\0\0\0\0041683\1t\3lan\0\0\1\0\1", 28, MSG_NOSIGNAL, NULL, 0) = 28
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])

* tcpdump:
1283805361.395859 IP (tos 0x0, ttl 64, id 47011, offset 0, flags [DF], proto UDP (17), length 56)
    192.168.130.53.49279 > 192.168.130.53.53: 27611+ A? 1682.t.lan. (28)
1283805361.395933 IP (tos 0x0, ttl 64, id 10738, offset 0, flags [none], proto UDP (17), length 112)
    192.168.130.53.53 > 192.168.130.53.49279: 27611* 1/1/1 1682.t.lan. A 127.0.0.1 (84)

* conntrack:
[1283805361.395862]         [NEW] ipv4     2 udp      17 30 src=192.168.130.53 dst=192.168.130.53 sport=49279 dport=53 [UNREPLIED] src=192.168.130.53 dst=192.168.130.53 sport=53 dport=49279 id=3423125776
[1283805361.395939]      [UPDATE] ipv4     2 udp      17 30 src=192.168.130.53 dst=192.168.130.53 sport=49279 dport=53 src=192.168.130.53 dst=192.168.130.53 sport=53 dport=49279 id=3423125776


Pozdrawiam,

			Krzysztof Olędzki