netdev - Re: Possible networking regression in 3.6.0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5069C27A.3090706@googlemail.com>
Date:	Mon, 01 Oct 2012 17:19:06 +0100
From:	Chris Clayton <chris2553@...glemail.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	gpiez@....de
Subject: Re: Possible networking regression in 3.6.0



On 10/01/12 16:31, Eric Dumazet wrote:
> On Mon, 2012-10-01 at 16:13 +0100, Chris Clayton wrote:
>>
>> On 10/01/12 10:15, Eric Dumazet wrote:
>>> On Mon, 2012-10-01 at 09:36 +0100, Chris Clayton wrote:
>>>>
>>>
>>>>        0 ICMP messages received
>>>>        0 input ICMP message failed.
>>>>        ICMP input histogram:
>>>>        0 ICMP messages sent
>>>>        0 ICMP messages failed
>>>>        ICMP output histogram:
>>>
>>>>
>>>> After:
>>>>
>>>> $ netstat -s
>>>> Icmp:
>>>>        4 ICMP messages received
>>>>        4 input ICMP message failed.
>>>>        ICMP input histogram:
>>>>            echo replies: 4
>>>
>>> So icmp replies come back and are delivered to host instead of being
>>> forwarded.
>>>
>>> I wonder if MASQUERADE broke...
>>>
>>> Could you send
>>>
>>> iptables -t -nat -nvL
>>
>> $ iptables -t -nat -nvL
>> iptables v1.4.15: can't initialize iptables table `-nat': Table does not
>> exist (do you need to insmod?)
>> Perhaps iptables or your kernel needs to be upgraded.
>>
>>> conntrack -L   # while ping is running from guest
>>
>> $ conntrack -L
>> conntrack v1.2.2 (conntrack-tools): Operation failed: invalid parameters
>>
>
> Thats not expected, you described you used MASQUERADE target, so
> "iptables -t nat -nvL" should display something.
>

To check this I've booted a 3.5.4 kernel. I get the same response to the 
two commands. I also double checked that, with a 3.5.4 kernel, pinging 
the router and browsing the internet from the client work and they do.

Except for the packets and bytes columns, the command iptables -nvL 
gives the following output under both 3.5.4 and 3.6.0 kernels:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source destination
  3757 3240K ACCEPT     all  --  *      *       0.0.0.0/0 0.0.0.0/0 
        state RELATED,ESTABLISHED
    14   840 ACCEPT     all  --  *      *       127.0.0.1 127.0.0.1
    41  4362 ACCEPT     all  --  *      *       192.168.0.0/24 0.0.0.0/0
    90 12780 ACCEPT     all  --  *      *       192.168.200.0/24 0.0.0.0/0
     0     0 ACCEPT     all  --  *      *       192.168.201.0/24 0.0.0.0/0
     0     0 DROP       all  --  *      *       0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 4470 packets, 3065K bytes)
  pkts bytes target     prot opt in     out     source destination

Chain OUTPUT (policy ACCEPT 3243 packets, 349K bytes)
  pkts bytes target     prot opt in     out     source destination
    64  8344 ACCEPT     all  --  *      *       0.0.0.0/0 192.168.200.0/24
     0     0 ACCEPT     all  --  *      *       0.0.0.0/0 192.168.201.0/24

>
>> Forgive me for asking, but why is the problem not down to the change
>> that I identified by bisecting? The title of the patch is "ipv4: Cache
>> local output routes" and, although I'm a million miles from being an
>> expert here, to me it does make it look a good candidate.
>> http://marc.info/?l=linux-netdev&m=134797809611847&w=2
>
> Because I cant reproduce your problem at all, using your setup.
>
OK, thanks.
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html