linux-kernel - Re: routing bug?

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: <alpine.DEB.2.02.1111181346480.17023@aurora>
Date:	Fri, 18 Nov 2011 13:48:03 +0100 (CET)
From:	Sven-Haegar Koch <haegar@...net.de>
To:	Pozsár Balázs <pozsy@...linux.hu>
cc:	Linux-Kernel-Mailinglist <linux-kernel@...r.kernel.org>,
	Tamási János <janusz@...linux.hu>,
	netdev@...r.kernel.org
Subject: Re: routing bug?

Added netdev list to CC:, there you should have a higher chance of a
usefull answer.

On Fri, 18 Nov 2011, Pozsár Balázs wrote:

> Hi all,
> 
> I have been struggling with this not easily reproducible issue since a while.
> I am using linux kernel v3.1.0, and sometimes routing to a few IP addresses
> does not work. What seems to happen is that instead of sending the packet to
> the gateway, the kernel treats the destination address as local, and tries to
> gets its MAC address via ARP.
> 
> For example, now my current IP address is 172.16.1.104/24, the gateway is
> 172.16.1.254:
> 
> |# ifconfig eth0 eth0      Link encap:Ethernet  HWaddr 00:1B:63:97:FC:DC
>           inet addr:172.16.1.104  Bcast:172.16.1.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:230772 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:171013 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:191879370 (182.9 Mb)  TX bytes:47173253 (44.9 Mb)
>           Interrupt:17
> 
> # route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 0.0.0.0         172.16.1.254    0.0.0.0         UG    0      0        0 eth0
> 172.16.1.0      0.0.0.0         255.255.255.0   U     1      0        0 eth0
> |
> 
> I can ping a few addresses, but not 172.16.0.59:
> 
> |# ping -c1 172.16.1.254
> PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
> 64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.383 ms
> 
> --- 172.16.1.254 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.383/0.383/0.383/0.000 ms
> root@...sybook:~# ping -c1 172.16.0.1
> PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
> 64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.54 ms
> 
> --- 172.16.0.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 5.545/5.545/5.545/0.000 ms
> root@...sybook:~# ping -c1 172.16.0.2
> PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
> 64 bytes from 172.16.0.2: icmp_seq=1 ttl=62 time=7.92 ms
> 
> --- 172.16.0.2 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 7.925/7.925/7.925/0.000 ms
> root@...sybook:~# ping -c1 172.16.0.59
> PING 172.16.0.59 (172.16.0.59) 56(84) bytes of data.
> From 172.16.1.104 icmp_seq=1 Destination Host Unreachable
> 
> --- 172.16.0.59 ping statistics ---
> 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
> |
> 
> When trying to ping 172.16.0.59, I can see in tcpdump that an ARP req was
> sent:
> 
> |# tcpdump -n -i eth0|grep ARP
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 15:25:16.671217 ARP, Request who-has 172.16.0.59 tell 172.16.1.104, length 28
> |
> 
> and /proc/net/arp has an incomplete entry for 172.16.0.59:
> 
> |# grep 172.16.0.59 /proc/net/arp
> 
> 172.16.0.59      0x1         0x0         00:00:00:00:00:00     *        eth0
> |
> 
> Please note, that 172.16.0.59 /is/ accessible from this LAN from other
> computers.
> 
> 
> Does anyone have any idea of what's going on? Thanks,
> 
> 
> Balazs Pozsar
> 
> ps: I think it is related to this one: https://lkml.org/lkml/2011/11/16/292
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

-- 
Three may keep a secret, if two of them are dead.
- Ben F.