netdev - Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 23 Oct 2012 01:27:59 +0400
From:	Andrew Savchenko <bircoph@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a
 waiting application

Hi,

On Mon, 22 Oct 2012 08:48:09 +0200 Eric Dumazet wrote:
> On Mon, 2012-10-22 at 07:36 +0400, Andrew Savchenko wrote:
[...]
> > This host has four NICs:
> > 2x Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (10ec:8139)
> > 2x D-Link System Inc DGE-528T Gigabit Ethernet Adapter (1462:223c)
> > 
> > One D-Link card is operating on 1Gbit/FD with mtu 7000, other cards
> > are used as 100Mbit/FD mtu 1500.
> > 
> > 2 D-Link and 1 Realtek card are forming a bridge and remaining Realtek
> > card is used for an uplink. This host serves as a NAT between
> > the bridge and the uplink (both MASQUERADE and DNAT are used). Also it
> > has several ipsec tunnels for multiple hosts (mostly AH), l2tp tunnel
> > (independent from ipsec) and serves as a multicast router using
> > mrouted. Rather sophisticated ebtables, iptables and ipset setup is
> > used.
> 
> Some driver or protocol stack is messing with skb->truesize, as
> your /proc/net/udp file contains anomalies :
> 
> $ cat /proc/net/udp
>   sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops
> ...
>   323: 074A070A:007B 00000000:0000 07 FFFDF700:00000000 00:00000000 00000000   123        0 254469 2 ffff88003d581880 0
> ...
>   323: 00FCA8C0:007B 00000000:0000 07 FFFFF900:00000000 00:00000000 00000000     0        0 5187 2 ffff880039993880 0
> 
> Its clearly not possible to get tx_queue = 0xFFFDF700 or 0xFFFFF900
> 
> So what drivers handle following IP addresses : 192.168.252.0 , 10.7.74.7  ?

192.168.252.0 is handled by eth0 interface running on Realtek
Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (10ec:8139) NIC.
Kernel driver 8139too. This interface handles multiple subnetworks:

# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 
link/ether 00:80:48:30:ca:f3 brd ff:ff:ff:ff:ff:ff
inet 10.51.15.126/25 brd 10.51.15.127 scope global eth0
inet 192.168.252.0/31 scope global eth0

10.7.74.7 is an l2tp connection handled by ppp over l2tp:
CONFIG_PPPOL2TP=y
It is running on top of eth0 described above.

# ip addr show ppp0
65: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp 
inet 10.7.74.7 peer 10.7.2.18/32 scope global ppp0

I don't know why both interfaces have unknown state: they are up and
running.

> lspci -v

Attached.

> lsmod

lsmod returns nothing: I compiled everything needed for daily use
into the kernel.

Best regards,
Andrew Savchenko

Download attachment "lspci-v" of type "application/octet-stream" (5774 bytes)

Content of type "application/pgp-signature" skipped