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

[Eric Dumazet <eric.dumazet@gmail.com>]

On Mon, 2012-10-22 at 07:36 +0400, Andrew Savchenko wrote:

> 
> I'll try 3.7 branch in a week or so. New kernel will require some
> reconfiguration.
> 
> > What NIC are you using ?
> 
> 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.
> 
> Best regards,
> Andrew Savchenko

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  ?

lspci -v
lsmod