return of ip_rt_bug()

Tom (CC'd) has been hitting that ip_rt_bug() WARN_ON() since 3.0rc

Here's the latest report.

------------[ cut here]------------

WARNING: atnet/ipv4/route.c:1714 ip_rt_bug+0x5c/0x62()
Hardware name: 74585FU
Modules linked in: fuse

ip6table_filter ip6_tables ebtable_nat ebtables ppdev parport_pc lp parport
ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state
nf_conntrack xt_CHECKSUM iptable_mangle tun bridge stp llc sunrpc rfcomm bnep
usblp arc4 uvcvideo videodev media snd_usb_audio snd_usbmidi_lib snd_rawmidi v4l2_compat_ioctl32 iwlagn microcode i2c_i801 btusb iTCO_wdt
iTCO_vendor_support mac80211 bluetooth snd_hda_codec_conexant cfg80211
thinkpad_acpi snd_hda_intel snd_hda_codec rfkill snd_hwdep snd_seq
snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc e1000e virtio_net
kvm_intel kvm uinput wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video[last unloaded: scsi_wait_scan]
Pid: 5492, comm: xsane Not tainted 3.1.0-0.rc0.git12.1.fc17.x86_64 #1

Call Trace:
 [<ffffffff8105c5ec>] warn_slowpath_common+0x83/0x9b
 [<ffffffff8105c61e>] warn_slowpath_null+0x1a/0x1c
 [<ffffffff8142f485>] ip_rt_bug+0x5c/0x62
 [<ffffffff81437091>] dst_output+0x19/0x1d
 [<ffffffff814387c0>] ip_local_out+0x20/0x25
 [<ffffffff81439695>] ip_send_skb+0x19/0x3e
 [<ffffffff81455ea2>] udp_send_skb+0x239/0x29b
 [<ffffffff8145763f>] udp_sendmsg+0x5a1/0x7d4
 [<ffffffff813f67d5>] ? release_sock+0x35/0x155
 [<ffffffff8143718c>] ? ip_select_ident+0x3d/0x3d
 [<ffffffff81062703>] ? local_bh_enable_ip+0xe/0x10
 [<ffffffff814f1231>] ? _raw_spin_unlock_bh+0x40/0x44
 [<ffffffff813f68ec>] ? release_sock+0x14c/0x155
 [<ffffffff8145eb58>] inet_sendmsg+0x66/0x6f
 [<ffffffff813f1d92>] sock_sendmsg+0xe6/0x109
 [<ffffffff8108f1c8>] ? lock_acquire+0x10f/0x13e
 [<ffffffff8110dd34>] ? might_fault+0x5c/0xac
 [<ffffffff8108f08c>] ? lock_release+0x1a4/0x1d1
 [<ffffffff8110dd7d>] ? might_fault+0xa5/0xac
 [<ffffffff813f2ad7>] ? copy_from_user+0x2f/0x31
 [<ffffffff813f496d>] sys_sendto+0x132/0x174
 [<ffffffff8124ef6e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff814f80c2>] system_call_fastpath+0x16/0x1b
---[ end trace 0e82aef47f8d8552 ]---
------------[ cut here ]------------

all the traces he's hit so far seem to be caused by udp, and they all seem to be going from 192.168.2.5 -> 255.255.255.255

https://bugzilla.redhat.com/show_bug.cgi?id=712632 is his full report with similar traces.

Dave

From: Dave Jones <[email protected]>
Date: Tue, 2 Aug 2011 13:09:42 -0400

It should have been fixed by the patch below, but apparently not:

--------------------

From: Julian Anastasov <[email protected]>
Date: Sat, 18 Jun 2011 07:53:59 +0000
Subject: [PATCH] netfilter: Fix ip_route_me_harder triggering ip_rt_bug

Avoid creating input routes with ip_route_me_harder.
It does not work for locally generated packets. Instead, restrict sockets to provide valid saddr for output route (or unicast saddr for transparent proxy). For other traffic allow saddr to be unicast or local but if callers forget to check saddr type use 0 for the output route.

The resulting handling should be:

- REJECT TCP:
- in INPUT we can provide addr_type = RTN_LOCAL but better allow rejecting traffic delivered with local route (no IP address => use RTN_UNSPEC to allow also RTN_UNICAST).
- FORWARD: RTN_UNSPEC => allow RTN_LOCAL/RTN_UNICAST saddr, add fix to ignore RTN_BROADCAST and RTN_MULTICAST
- OUTPUT: RTN_UNSPEC

- NAT, mangle, ip_queue, nf_ip_reroute: RTN_UNSPEC in LOCAL_OUT

- IPVS:
- use RTN_LOCAL in LOCAL_OUT and FORWARD after SNAT to restrict saddr to be local

---
 net/ipv4/netfilter.c            |   60 ++++++++++++++------------------------
 net/ipv4/netfilter/ipt_REJECT.c |   14 ++------
 2 files changed, 26 insertions(+), 48 deletions(-)

index 4614bab..2e97e3e 100644
@@ -17,51 +17,35 @@ int ip_route_me_harder(struct sk_buff *skb, unsigned addr_type)
 	const struct iphdr *iph = ip_hdr(skb);
 	struct rtable *rt;
 	struct flowi4 fl4 = {};
-	unsigned long orefdst;
+	__be32 saddr = iph->saddr;
+	__u8 flags = 0;
 	unsigned int hh_len;
-	unsigned int type;
 
-	type = inet_addr_type(net, iph->saddr);
-	if (skb->sk && inet_sk(skb->sk)->transparent)
-		type = RTN_LOCAL;
-	if (addr_type == RTN_UNSPEC)
-		addr_type = type;
+	if (!skb->sk && addr_type != RTN_LOCAL) {
+		if (addr_type == RTN_UNSPEC)
+			addr_type = inet_addr_type(net, saddr);
+		if (addr_type == RTN_LOCAL || addr_type == RTN_UNICAST)
+			flags |= FLOWI_FLAG_ANYSRC;
+		else
+			saddr = 0;
+	}
 
 	/* some non-standard hacks like ipt_REJECT.c:send_reset() can cause
 	 * packets with foreign saddr to appear on the NF_INET_LOCAL_OUT hook.
 	 */
-	if (addr_type == RTN_LOCAL) {
-		fl4.daddr = iph->daddr;
-		if (type == RTN_LOCAL)
-			fl4.saddr = iph->saddr;
-		fl4.flowi4_tos = RT_TOS(iph->tos);
-		fl4.flowi4_oif = skb->sk ? skb->sk->sk_bound_dev_if : 0;
-		fl4.flowi4_mark = skb->mark;
-		fl4.flowi4_flags = skb->sk ? inet_sk_flowi_flags(skb->sk) : 0;
-		rt = ip_route_output_key(net, &fl4);
-		if (IS_ERR(rt))
-			return -1;
-
-		/* Drop old route. */
-		skb_dst_drop(skb);
-		skb_dst_set(skb, &rt->dst);
-	} else {
-		/* non-local src, find valid iif to satisfy
-		 * rp-filter when calling ip_route_input. */
-		fl4.daddr = iph->saddr;
-		rt = ip_route_output_key(net, &fl4);
-		if (IS_ERR(rt))
-			return -1;
+	fl4.daddr = iph->daddr;
+	fl4.saddr = saddr;
+	fl4.flowi4_tos = RT_TOS(iph->tos);
+	fl4.flowi4_oif = skb->sk ? skb->sk->sk_bound_dev_if : 0;
+	fl4.flowi4_mark = skb->mark;
+	fl4.flowi4_flags = skb->sk ? inet_sk_flowi_flags(skb->sk) : flags;
+	rt = ip_route_output_key(net, &fl4);
+	if (IS_ERR(rt))
+		return -1;
 
-		orefdst = skb->_skb_refdst;
-		if (ip_route_input(skb, iph->daddr, iph->saddr,
-				   RT_TOS(iph->tos), rt->dst.dev) != 0) {
-			dst_release(&rt->dst);
-			return -1;
-		}
-		dst_release(&rt->dst);
-		refdst_drop(orefdst);
-	}
+	/* Drop old route. */
+	skb_dst_drop(skb);
+	skb_dst_set(skb, &rt->dst);
 
 	if (skb_dst(skb)->error)
 		return -1;

index 1ff79e5..51f13f8 100644
@@ -40,7 +40,6 @@ static void send_reset(struct sk_buff *oldskb, int hook)
 	struct iphdr *niph;
 	const struct tcphdr *oth;
 	struct tcphdr _otcph, *tcph;
-	unsigned int addr_type;
 
 	/* IP header checks: fragment. */
 	if (ip_hdr(oldskb)->frag_off & htons(IP_OFFSET))

@@ -55,6 +54,9 @@ static void send_reset(struct sk_buff *oldskb, int hook)
 	if (oth->rst)
 		return;
 
+	if (skb_rtable(oldskb)->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST))
+		return;
+
 	/* Check checksum */
 	if (nf_ip_checksum(oldskb, hook, ip_hdrlen(oldskb), IPPROTO_TCP))
 		return;

@@ -101,19 +103,11 @@ static void send_reset(struct sk_buff *oldskb, int hook)
 	nskb->csum_start = (unsigned char *)tcph - nskb->head;
 	nskb->csum_offset = offsetof(struct tcphdr, check);
 
-	addr_type = RTN_UNSPEC;
-	if (hook != NF_INET_FORWARD
-#ifdef CONFIG_BRIDGE_NETFILTER
-	    || (nskb->nf_bridge && nskb->nf_bridge->mask & BRNF_BRIDGED)
-#endif
-	   )
-		addr_type = RTN_LOCAL;
-
 	/* ip_route_me_harder expects skb->dst to be set */
 	skb_dst_set_noref(nskb, skb_dst(oldskb));
 
 	nskb->protocol = htons(ETH_P_IP);
-	if (ip_route_me_harder(nskb, addr_type))
+	if (ip_route_me_harder(nskb, RTN_UNSPEC))
 		goto free_nskb;
 
 	niph->ttl	= ip4_dst_hoplimit(skb_dst(nskb));

1.7.6

Hello,

Tom, what kind of netfilter rules do you have in
LOCAL_OUT/OUTPUT hooks? We eliminated one ip_route_input call from net/ipv4/netfilter.c (ip_route_me_harder) but it looks like in your kernel ip_route_input is called again from this hook. It is interesting why only broadcasts get such input route.

I assume 192.168.2.5 is an existing local address that
is present during the test? Any additional modules that use ip_route_input ? Are nf_queue, IPVS, br_netfilter or tproxy used?

Regards

--
Julian Anastasov <[email protected]>

Here is what 'route' says:

[root@tlondon ~]# route
Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         tlondon         0.0.0.0         UG    0      0        0 eth0
192.168.2.0     *               255.255.255.0   U     1      0        0 eth0
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0

[root@tlondon ~]#

and 'ifconfig':

eth0 Link encap:Ethernet HWaddr 00:1F:16:0B:56:A8

          inet addr:192.168.2.6  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::21f:16ff:fe0b:56a8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4269 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3503 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3948798 (3.7 MiB)  TX bytes:517347 (505.2 KiB)
          Interrupt:20 Memory:f2600000-f2620000

Here is what is in /etc/sysconfig/iptables:

[root@tlondon sysconfig]# cat iptables
# Generated by iptables-save v1.4.9 on Mon Jan 17 06:36:35 2011 *security
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:DNS - [0:0]
:INTERNET - [0:0]
:INTRANET - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j CONNSECMARK --restore -A INPUT -s 255.255.255.255/32 -j INTRANET
-A INPUT -s 127.0.0.0/8 -j INTRANET
-A INPUT -s 10.0.0.0/8 -j INTRANET
-A INPUT -s 172.16.0.0/16 -j INTRANET
-A INPUT -s 224.0.0.0/24 -j INTRANET
-A INPUT -s 192.168.0.0/16 -j INTRANET
-A INPUT -j INTERNET
-A OUTPUT -m state --state RELATED,ESTABLISHED -j CONNSECMARK --restore -A OUTPUT -d 255.255.255.255/32 -j INTRANET
-A OUTPUT -d 127.0.0.0/8 -j INTRANET
-A OUTPUT -d 10.0.0.0/8 -j INTRANET
-A OUTPUT -d 172.16.0.0/16 -j INTRANET
-A OUTPUT -d 224.0.0.0/24 -j INTRANET
-A OUTPUT -d 192.168.0.0/16 -j INTRANET
-A OUTPUT -p udp -m udp --dport 53 -j DNS
-A OUTPUT -p tcp -m tcp --dport 53 -j DNS
-A OUTPUT -j INTERNET
-A DNS -j SECMARK --selctx system_u:object_r:dns_internet_packet_t:s0 -A DNS -j CONNSECMARK --save
-A DNS -j ACCEPT
-A INTERNET -j SECMARK --selctx system_u:object_r:internet_packet_t:s0 -A INTERNET -j CONNSECMARK --save
-A INTERNET -j ACCEPT
-A INTRANET -j SECMARK --selctx system_u:object_r:intranet_packet_t:s0 -A INTRANET -j CONNSECMARK --save
-A INTRANET -j ACCEPT
COMMIT
# Completed on Mon Jan 17 06:36:35 2011
# Generated by iptables-save v1.4.9 on Mon Jan 17 06:36:35 2011 *nat
:PREROUTING ACCEPT [35:3434]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [812:64159]
:POSTROUTING ACCEPT [810:63177]
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE COMMIT
# Completed on Mon Jan 17 06:36:35 2011
# Generated by iptables-save v1.4.9 on Mon Jan 17 06:36:35 2011 *mangle
:PREROUTING ACCEPT [83178:89234503]
:INPUT ACCEPT [83176:89234439]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [52780:3860973]
:POSTROUTING ACCEPT [52919:3899453]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill COMMIT
# Completed on Mon Jan 17 06:36:35 2011
# Generated by iptables-save v1.4.9 on Mon Jan 17 06:36:35 2011 *filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [52780:3860973]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 631 -j ACCEPT -A INPUT -p udp -m state --state NEW -m udp --dport 631 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Mon Jan 17 06:36:35 2011
[root@tlondon sysconfig]#

and here is what 'iptables -L' says:

[root@tlondon ~]# iptables -L
Chain INPUT (policy ACCEPT)

target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.122.0/24     state
RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     anywhere
ACCEPT     all  --  anywhere             anywhere
REJECT     all  --  anywhere             anywhere

reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere
reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@tlondon ~]#

Regarding additional modules, I believe I'm running a 'stock' Fedora Rawhide system. Here is what 'lsmod' says:

[root@tlondon ~]# lsmod

Module                  Size  Used by
fuse                   70196  3
ip6table_filter        12815  0
ip6_tables             23088  1 ip6table_filter
ebtable_nat            12807  0
ebtables               27075  1 ebtable_nat
ipt_MASQUERADE         12880  3
iptable_nat            13383  1
nf_nat                 25795  2 ipt_MASQUERADE,iptable_nat
nf_conntrack_ipv4      14700  4 iptable_nat,nf_nat
nf_defrag_ipv4         12673  1 nf_conntrack_ipv4
xt_state               12578  1
nf_conntrack           81778  5
ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4,xt_state
ppdev                  13616  0
parport_pc             24112  0
xt_CHECKSUM            12549  1
lp                     22009  0
iptable_mangle         12695  1
parport                40823  3 ppdev,parport_pc,lp
tun                    19023  1
bridge                 85889  0
stp                    12946  1 bridge
llc                    14197  2 bridge,stp
rfcomm                 65661  4
bnep                   19857  2
usblp                  18206  0
arc4                   12529  2
uvcvideo               63617  0
videodev               85806  1 uvcvideo
media                  20522  2 uvcvideo,videodev
snd_usb_audio         108696  1
v4l2_compat_ioctl32    16677  1 videodev
snd_usbmidi_lib        24835  1 snd_usb_audio
snd_rawmidi            25641  1 snd_usbmidi_lib
snd_hda_codec_conexant    62115  1
snd_hda_intel          28992  3
iwlagn                370621  0
snd_hda_codec          91636  2 snd_hda_codec_conexant,snd_hda_intel
snd_hwdep              13595  2 snd_usb_audio,snd_hda_codec
snd_seq                57219  0
snd_seq_device         14173  2 snd_rawmidi,snd_seq
mac80211              282558  1 iwlagn
btusb                  20161  2
microcode              31412  0
i2c_i801               17765  0
snd_pcm                85340  4 snd_usb_audio,snd_hda_intel,snd_hda_codec
iTCO_wdt               17808  0
iTCO_vendor_support    13474  1 iTCO_wdt
cfg80211              161253  2 iwlagn,mac80211
bluetooth             215033  23 rfcomm,bnep,btusb
snd_timer              29131  2 snd_seq,snd_pcm
snd_page_alloc         14039  2 snd_hda_intel,snd_pcm
thinkpad_acpi          71386  0
rfkill                 21648  4 cfg80211,bluetooth,thinkpad_acpi
snd                    70856  19
snd_usb_audio,snd_usbmidi_lib,snd_rawmidi,snd_hda_codec_conexant,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer,thinkpad_acpi
soundcore              14562  1 snd
e1000e                182622  0
virtio_net             19157  0
kvm_intel             125225  0
kvm                   348016  1 kvm_intel
uinput                 17722  0
wmi                    18697  0
i915                  403560  3
drm_kms_helper         36330  1 i915
drm                   201826  4 i915,drm_kms_helper
i2c_algo_bit           13246  1 i915
i2c_core               34077  6

videodev,i2c_i801,i915,drm_kms_helper,drm,i2c_algo_bit
video 19174 1 i915
[root@tlondon ~]#

How else can I help?

tom

Tom London

Hello,

From your bug report at
https://bugzilla.redhat.com/show_bug.cgi?id=712632 I see that the application is xsane, "Manufacturer: EPSON". I downloaded some sources and in sane-backends-git20110804/sanei/sanei_udp.c I see some UDP usage.

	For example, sane-backends-git20110804/backend/epson2.c

calls sanei_udp_open_broadcast (UDP socket with SO_BROADCAST). The socket is not bound, not connected, application sends packet to 255.255.255.255:3289 in blocking mode and waits for reply for 1 second. It is done for "net autodiscovery" config. As the socket is not bound, kernel should search source address for every packet. Nothing special so far. Not sure why your report has 2 oopses in period of 1 second, may be config has 2 lines "net autodiscovery" and 2 packets are sent?

	Your first report was for 192.168.2.5 but

I don't see the IP from your last report that is with kernel-3.1.0-0.rc0.git12.1.fc17.x86_64. Now you show local IP is 192.168.2.6. Do you have 192.168.2.5 as local IP, what shows 'ip addr' ?

Can you confirm that the IP you see in oops is always
configured (ip addr). Or may be it comes from DHCP and now is 192.168.2.6?

Can you start 'ip monitor' in one console while
attaching the USB device, so that we can know if any IP addresses are reconfigured due to some events. For example, script that restarts DHCP.

Regards

--
Julian Anastasov <[email protected]>

Sure. I'll set this up when I get back home this evening.

Not sure about the 192.168.2.5 vs 192.168.2.6 confusion. My laptop is connected to a Belkin router, and uses DHCP. I sometimes have the wireless interface connected as well, so perhaps this sometimes occurs when only the wired NIC is connected and sometimes when both the wired and wireless NICs are connected? I'll also see if I can uncover any DHCP history

I'll try to follow the above instructions, and will report out about 8PM PDT.

tom

Tom London

OK. Booted up. Here is what 'ifconfig' says:

[root@tlondon ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1F:16:0B:56:A8

          inet addr:192.168.2.6  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::21f:16ff:fe0b:56a8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2101 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1814 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1719912 (1.6 MiB)  TX bytes:268153 (261.8 KiB)
          Interrupt:20 Memory:f2600000-f2620000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:79 errors:0 dropped:0 overruns:0 frame:0 TX packets:79 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:19162 (18.7 KiB) TX bytes:19162 (18.7 KiB)

virbr0 Link encap:Ethernet HWaddr 52:54:00:B9:89:30
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

wlan0 Link encap:Ethernet HWaddr 00:21:5D:AC:C6:92
inet addr:192.168.2.9 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::221:5dff:feac:c692/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22 errors:0 dropped:0 overruns:0 frame:0 TX packets:26 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
RX bytes:2767 (2.7 KiB) TX bytes:5705 (5.5 KiB)

[root@tlondon ~]#

'ip addr' says:
[root@tlondon ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:1f:16:0b:56:a8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.6/24 brd 192.168.2.255 scope global eth0
    inet6 fe80::21f:16ff:fe0b:56a8/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:21:5d:ac:c6:92 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.9/24 brd 192.168.2.255 scope global wlan0
    inet6 fe80::221:5dff:feac:c692/64 scope link
       valid_lft forever preferred_lft forever
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN
    link/ether 52:54:00:b9:89:30 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop master virbr0
state DOWN qlen 500
    link/ether 52:54:00:b9:89:30 brd ff:ff:ff:ff:ff:ff

[root@tlondon ~]#

I ran 'ip monitor' in one terminal window, ran 'inotail -f
/var/log/messages' in another, started 'gimp', and did a 'create from usb:epson'.

I got this in the 'ip monitor' window:

[root@tlondon ~]# ip monitor
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE

I got this in the 'inotify -f /var/log/messages' window:

Aug  4 19:29:27 tlondon kernel: [  305.997223] usb 3-1: new full speed
USB device number 2 using uhci_hcd
Aug  4 19:29:28 tlondon kernel: [  306.581320] usb 3-1: New USB device
found, idVendor=04b8, idProduct=010a
Aug  4 19:29:28 tlondon kernel: [  306.581332] usb 3-1: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Aug  4 19:29:28 tlondon kernel: [  306.581340] usb 3-1: Product: Perfection1640
Aug  4 19:29:28 tlondon kernel: [  306.581346] usb 3-1: Manufacturer: EPSON
Aug  4 19:29:28 tlondon mtp-probe: checking bus 3, device 2:
"/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
Aug  4 19:29:28 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device
Aug  4 19:30:07 tlondon kernel: [  345.300960] ------------[ cut here
]------------
Aug  4 19:30:07 tlondon kernel: [  345.300977] WARNING: at
net/ipv4/route.c:1714 ip_rt_bug+0x5c/0x62()
Aug  4 19:30:07 tlondon kernel: [  345.300984] Hardware name: 74585FU
Aug  4 19:30:07 tlondon kernel: [  345.300989] Modules linked in: fuse

ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM ppdev iptable_mangle parport_pc lp parport tun bridge stp llc rfcomm bnep usblp arc4 snd_usb_audio snd_usbmidi_lib snd_hda_codec_conexant snd_rawmidi uvcvideo videodev snd_hda_intel snd_hda_codec media v4l2_compat_ioctl32 snd_hwdep snd_seq snd_seq_device iwlagn snd_pcm btusb microcode iTCO_wdt i2c_i801 iTCO_vendor_support thinkpad_acpi mac80211 snd_timer bluetooth cfg80211 snd_page_alloc rfkill snd soundcore e1000e virtio_net kvm_intel kvm uinput wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]

Aug  4 19:30:07 tlondon kernel: [  345.301272] Pid: 2348, comm: xsane
Not tainted 3.1.0-0.rc0.git17.1.fc17.x86_64 #1
Aug  4 19:30:07 tlondon kernel: [  345.301280] Call Trace:
Aug  4 19:30:07 tlondon kernel: [  345.301300]  [<ffffffff8105c470>]
warn_slowpath_common+0x83/0x9b
Aug  4 19:30:07 tlondon kernel: [  345.301315]  [<ffffffff8105c4a2>]
warn_slowpath_null+0x1a/0x1c
Aug  4 19:30:07 tlondon kernel: [  345.301329]  [<ffffffff8142f625>]
ip_rt_bug+0x5c/0x62
Aug  4 19:30:07 tlondon kernel: [  345.301342]  [<ffffffff81437231>]
dst_output+0x19/0x1d
Aug  4 19:30:07 tlondon kernel: [  345.301355]  [<ffffffff81438952>]
ip_local_out+0x20/0x25
Aug  4 19:30:07 tlondon kernel: [  345.301369]  [<ffffffff81439819>]
ip_send_skb+0x19/0x3e
Aug  4 19:30:07 tlondon kernel: [  345.301385]  [<ffffffff81456016>]
udp_send_skb+0x239/0x29b
Aug  4 19:30:07 tlondon kernel: [  345.301399]  [<ffffffff814577b3>]
udp_sendmsg+0x5a1/0x7d4
Aug  4 19:30:07 tlondon kernel: [  345.301415]  [<ffffffff813f69f7>] ?
release_sock+0x35/0x155
Aug  4 19:30:07 tlondon kernel: [  345.301428]  [<ffffffff8143732c>] ?
ip_select_ident+0x3d/0x3d
Aug  4 19:30:07 tlondon kernel: [  345.301443]  [<ffffffff81062587>] ?
local_bh_enable_ip+0xe/0x10
Aug  4 19:30:07 tlondon kernel: [  345.301457]  [<ffffffff814f1519>] ?
_raw_spin_unlock_bh+0x40/0x44
Aug  4 19:30:07 tlondon kernel: [  345.301470]  [<ffffffff813f6b0e>] ?
release_sock+0x14c/0x155
Aug  4 19:30:07 tlondon kernel: [  345.301485]  [<ffffffff8145eccc>]
inet_sendmsg+0x66/0x6f
Aug  4 19:30:07 tlondon kernel: [  345.301498]  [<ffffffff813f1fc2>]
sock_sendmsg+0xe6/0x109
Aug  4 19:30:07 tlondon kernel: [  345.301513]  [<ffffffff8108f078>] ?
lock_acquire+0x10f/0x13e
Aug  4 19:30:07 tlondon kernel: [  345.301528]  [<ffffffff8110d89e>] ?
might_fault+0x5c/0xac
Aug  4 19:30:07 tlondon kernel: [  345.301542]  [<ffffffff8108ef3c>] ?
lock_release+0x1a4/0x1d1
Aug  4 19:30:07 tlondon kernel: [  345.301556]  [<ffffffff8110d8e7>] ?
might_fault+0xa5/0xac
Aug  4 19:30:07 tlondon kernel: [  345.301569]  [<ffffffff813f2d07>] ?
copy_from_user+0x2f/0x31
Aug  4 19:30:07 tlondon kernel: [  345.301582]  [<ffffffff813f4b9d>]
sys_sendto+0x132/0x174
AugAug  4 19:30:08 tlondon kernel: [  346.314606] ------------[ cut
here ]------------
Aug  4 19:30:08 tlondon kernel: [  346.314612] WARNING: at
net/ipv4/route.c:1714 ip_rt_bug+0x5c/0x62()
Aug  4 19:30:08 tlondon kernel: [  346.314615] Hardware name: 74585FU
Aug  4 19:30:08 tlondon kernel: [  346.314616] Modules linked in: fuse

ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM ppdev iptable_mangle parport_pc lp parport tun bridge stp llc rfcomm bnep usblp arc4 snd_usb_audio snd_usbmidi_lib snd_hda_codec_conexant snd_rawmidi uvcvideo videodev snd_hda_intel snd_hda_codec media v4l2_compat_ioctl32 snd_hwdep snd_seq snd_seq_device iwlagn snd_pcm btusb microcode iTCO_wdt i2c_i801 iTCO_vendor_support thinkpad_acpi mac80211 snd_timer bluetooth cfg80211 snd_page_alloc rfkill snd soundcore e1000e virtio_net kvm_intel kvm uinput wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]

Aug  4 19:30:08 tlondon kernel: [  346.314693] Pid: 2348, comm: xsane
Tainted: G        W   3.1.0-0.rc0.git17.1.fc17.x86_64 #1
Aug  4 19:30:08 tlondon kernel: [  346.314695] Call Trace:
Aug  4 19:30:08 tlondon kernel: [  346.314701]  [<ffffffff8105c470>]
warn_slowpath_common+0x83/0x9b
Aug  4 19:30:08 tlondon kernel: [  346.314704]  [<ffffffff8105c4a2>]
warn_slowpath_null+0x1a/0x1c
Aug  4 19:30:08 tlondon kernel: [  346.314708]  [<ffffffff8142f625>]
ip_rt_bug+0x5c/0x62
Aug  4 19:30:08 tlondon kernel: [  346.314711]  [<ffffffff81437231>]
dst_output+0x19/0x1d
Aug  4 19:30:08 tlondon kernel: [  346.314714]  [<ffffffff81438952>]
ip_local_out+0x20/0x25
Aug  4 19:30:08 tlondon kernel: [  346.314717]  [<ffffffff81439819>]
ip_send_skb+0x19/0x3e
Aug  4 19:30:08 tlondon kernel: [  346.314721]  [<ffffffff81456016>]
udp_send_skb+0x239/0x29b
Aug  4 19:30:08 tlondon kernel: [  346.314725]  [<ffffffff814577b3>]
udp_sendmsg+0x5a1/0x7d4
Aug  4 19:30:08 tlondon kernel: [  346.314729]  [<ffffffff813f69f7>] ?
release_sock+0x35/0x155
Aug  4 19:30:08 tlondon kernel: [  346.314732]  [<ffffffff8143732c>] ?
ip_select_ident+0x3d/0x3d
Aug  4 19:30:08 tlondon kernel: [  346.314736]  [<ffffffff81062587>] ?
local_bh_enable_ip+0xe/0x10
Aug  4 19:30:08 tlondon kernel: [  346.314740]  [<ffffffff814f1519>] ?
_raw_spin_unlock_bh+0x40/0x44
Aug  4 19:30:08 tlondon kernel: [  346.314743]  [<ffffffff813f6b0e>] ?
release_sock+0x14c/0x155
Aug  4 19:30:08 tlondon kernel: [  346.314747]  [<ffffffff8145eccc>]
inet_sendmsg+0x66/0x6f
Aug  4 19:30:08 tlondon kernel: [  346.314750]  [<ffffffff813f1fc2>]
sock_sendmsg+0xe6/0x109
Aug  4 19:30:08 tlondon kernel: [  346.314754]  [<ffffffff8108f078>] ?
lock_acquire+0x10f/0x13e
Aug  4 19:30:08 tlondon kernel: [  346.314758]  [<ffffffff8110d89e>] ?
might_fault+0x5c/0xac
Aug  4 19:30:08 tlondon kernel: [  346.314761]  [<ffffffff8108ef3c>] ?
lock_release+0x1a4/0x1d1
Aug  4 19:30:08 tlondon kernel: [  346.314765]  [<ffffffff8110d8e7>] ?
might_fault+0xa5/0xac
Aug  4 19:30:08 tlondon kernel: [  346.314768]  [<ffffffff813f2d07>] ?
copy_from_user+0x2f/0x31
Aug  4 19:30:08 tlondon kernel: [  346.314771]  [<ffffffff813f4b9d>]
sys_sendto+0x132/0x174
Aug  4 19:30:08 tlondon kernel: [  346.314775]  [<ffffffff810b29eb>] ?
audit_syscall_entry+0x11c/0x148
Aug  4 19:30:08 tlondon kernel: [  346.314780]  [<ffffffff8124f03e>] ?
trace_hardirqs_on_thunk+0x3a/0x3f
Aug  4 19:30:08 tlondon kernel: [  346.314784]  [<ffffffff814f8382>]
system_call_fastpath+0x16/0x1b
Aug  4 19:30:08 tlondon kernel: [  346.314786] ---[ end trace

97e7c0a8de097c51 ]---

Regarding the 'movable IP Address' issue (.5 vs. .6), I found the following in /var/lib/dhclient/dhclient-5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03-eth0.lease

lease {
interface "eth0";
fixed-address 192.168.2.5;
option subnet-mask 255.255.255.0;
option dhcp-lease-time 4294967295;
option routers 192.168.2.1;
option dhcp-message-type 5;
option dhcp-server-identifier 192.168.2.1;
option domain-name-servers 192.168.2.1;
option domain-name "TintonFalls";
renew 4 2079/07/06 21:52:00;
rebind 1 2130/10/30 06:17:29;
expire 6 2147/11/04 01:06:07;
}
lease {
interface "eth0";
fixed-address 192.168.2.6;
option subnet-mask 255.255.255.0;
option dhcp-lease-time 4294967295;
option routers 192.168.2.1;
option dhcp-message-type 5;
option dhcp-server-identifier 192.168.2.1;
option domain-name-servers 192.168.2.1;
option domain-name "TintonFalls";
renew 2 2079/08/22 16:15:42;
rebind 4 2130/09/07 00:41:11;
expire 1 2147/09/11 19:29:49;
}

So, my router is just giving my wired NIC different addresses....

More I can provide?

tom

Tom London

Hello,

Thanks! Can you check in dmesg or in another log
about the first IP address in such line:

printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"

	Is it now 192.168.2.6 ?

Regards

--
Julian Anastasov <[email protected]>

Sorry, don't see those messages. I guess I'll have to reboot with 'debug' to see that.

Before I do that, I booted this time with the RFKILL switch set to kill the radio (both BT and WIFI), and reran the above tests.

Here is what 'ip monitor' said:

[root@tlondon ~]# ip monitor
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE ff02::fb via ff02::fb dev eth0 metric 0
cache
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE

Here is what 'inotail -f /var/log/messages' said:

Aug  5 06:12:21 tlondon kernel: [  536.727187] usb 3-1: new full speed
USB device number 2 using uhci_hcd
Aug  5 06:12:21 tlondon kernel: [  537.315296] usb 3-1: New USB device
found, idVendor=04b8, idProduct=010a
Aug  5 06:12:21 tlondon kernel: [  537.315308] usb 3-1: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Aug  5 06:12:21 tlondon kernel: [  537.315317] usb 3-1: Product: Perfection1640
Aug  5 06:12:21 tlondon kernel: [  537.315323] usb 3-1: Manufacturer: EPSON
Aug  5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
"/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
Aug  5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device

So, no WARN_ON messages.

I'd like to conclude that this is due to UDP casting on the wlan. I'll reboot with the radio on and in debug mode to see what happens.

tom

Tom London

Hmmm, first attempt at recreating in debug mode didn't actually produce any WARN_ON reports.

'ip monitor' did say:

[root@tlondon ~]# ip monitor
239.255.255.250 dev eth0 lladdr 01:00:5e:7f:ff:fa NOARP 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether

Will try one more time.

tom

Tom London

Can't seem to reproduce this when I boot with 'debug' on the boot line.

Here is what 'ip monitor' says:

[root@tlondon ~]# ip monitor
ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether

tom

Tom London

Hello,

Sending to 255.255.255.255 without binding to source address
or output device will succeed only if there is a route that matches the 255.255.255.255 address (default route as last option). If no route matches, the result is ENETUNREACH and packet should be dropped. But how input route is attached, I still don't know.

Your ip monitor does not show fatal event that can
invalidate the source address or the default route (that will match for 255.255.255.255) while sending packet.
It is almost impossible such problem to occur, i.e. between routing and following re-routing the address/route to disappear.

Such events:

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether

are may be for link, not sure. Events for addresses/routes
would show addresses and routes in a way similar to
ip addr and ip route list.

Not sure where your logs go, may be you can add
"kern.* /var/log/kernel.log" in your /etc/rsyslog.conf. But if you don't see the WARNING then the problem does not happen. You can also see the ip_rt_bug line with 'dmesg'. So, can you confirm the problem occurs only when default route points to wlan? Even if so, I still don't see good explanation for the error message.

Regards

--
Julian Anastasov <[email protected]>

Hello,

OK, after a bit of digging here is the problem.
It is evident that ip_rt_bug reports skb->dev = NULL which is impossible to pass ip_route_input. It means, we got this input route no matter our skb->dev = NULL. Here is how that happened.

For the routing cache compare_keys matches
rt_key_dst, rt_key_src, rt_mark, rt_key_tos, rt_oif, rt_iif

Consider the following two examples:

1. Received traffic from 0.0.0.0 to 255.255.255.255, one example is DHCP

ip_route_input_slow caches the things as follows:

rt_key_dst = 255.255.255.255 (iph->daddr) rt_key_src = 0.0.0.0 (iph->saddr)
rt_mark = 0
rt_key_tos = 0 (RT TOS from iph->tos) rt_oif = 0 (always for input route)
rt_iif = eth0 (input device)

not compared by compare_keys:
rt_route_iif = eth0 (input device)

use hash chain based on some keys and iif

2. Local traffic from ANY LOCAL IP to 255.255.255.255, our example is broadcast for EPSON printer where the socket is not bound to source address

__mkroute_output caches the things as follows:

rt_key_dst = 255.255.255.255 (orig_daddr)
rt_key_src = 0.0.0.0 (orig_saddr), because not bound rt_mark = 0
rt_key_tos = 0 (RT TOS from iph->tos)
rt_oif = 0 (orig_oif), because not bound to output device rt_iif = eth0 (orig_oif or dev_out->ifindex), dev_out in our case

not compared by compare_keys:
rt_route_iif = 0 (always for output route)

use hash chain based on some keys and orig_oif

Now when we put rt_intern_hash in the game, it tries to
reuse existing entries in the cache by using compare_keys. It is hard to hit the problem because input and output routes use different hashing based on iif/orig_oif.

The problem: if we have input route in the cache
it can be returned to callers that request output route. That is why dst_output points to ip_rt_bug.

As noted above, compare_keys must consider rt_route_iif.
It must be also considered by ip_route_input_common.

The appended patch fixes the problem for me. I was
able to reproduce ip_rt_bug by using rhash_entries=1 (resulting in rt_hash_mask=1) and increasing gc_thresh to 8, so that I can send these 2 packets with custom programs and the cache entries to live longer in cache.

===============================================================

[PATCH] ipv4: fix the reusing of routing cache entries

compare_keys and ip_route_input_common rely on
rt_oif for distinguishing of input and output routes with same keys values. But sometimes the input route has also same hash chain (keyed by iif != 0) with the output routes (keyed by orig_oif=0). Problem visible if running with small number of rhash_entries.

Fix them to use rt_route_iif instead. By this way
input route can not be returned to users that request output route.

The patch fixes the ip_rt_bug errors that were
reported in ip_local_out context, mostly for 255.255.255.255 destinations.

---

This is for 3.0, didn't checked net-next yet.

diff -urp v3.0/linux/net/ipv4/route.c linux/net/ipv4/route.c
@@ -725,6 +725,7 @@ static inline int compare_keys(struct rt
 		((__force u32)rt1->rt_key_src ^ (__force u32)rt2->rt_key_src) |
 		(rt1->rt_mark ^ rt2->rt_mark) |
 		(rt1->rt_key_tos ^ rt2->rt_key_tos) |
+		(rt1->rt_route_iif ^ rt2->rt_route_iif) |
 		(rt1->rt_oif ^ rt2->rt_oif) |
 		(rt1->rt_iif ^ rt2->rt_iif)) == 0;
 }

@@ -2281,8 +2282,8 @@ int ip_route_input_common(struct sk_buff
 		if ((((__force u32)rth->rt_key_dst ^ (__force u32)daddr) |
 		     ((__force u32)rth->rt_key_src ^ (__force u32)saddr) |
 		     (rth->rt_iif ^ iif) |
-		     rth->rt_oif |
 		     (rth->rt_key_tos ^ tos)) == 0 &&
+		    rt_is_input_route(rth) &&
 		    rth->rt_mark == skb->mark &&
 		    net_eq(dev_net(rth->dst.dev), net) &&
 		    !rt_is_expired(rth)) {

From: Julian Anastasov <[email protected]>
Date: Sun, 7 Aug 2011 01:14:22 +0300 (EEST)

Good spotting Julian.

This is my fault entirely. First I removed the thing we now call ->rt_route_iif which led to bug fix:

commit 1b86a58f9d7ce4fe2377687f378fbfb53bdc9b6c

Author: OGAWA Hirofumi <[email protected]>
Date:   Thu Apr 7 14:04:08 2011 -0700

    ipv4: Fix "Set rt->rt_iif more sanely on output routes."

but I forgot to make sure we also added back the key comparison on lookups as well :-/

Applied and queued up for -stable, thanks!

Hello,

I now checked these changes back to 2.6.38.
As rt_iif is used to provide input device even for loopback packets that come with output route, may be we can optimize further the code to save some CPU cycles. In fact, it restores some route.c functions to 2.6.38 semantics. The conversion was:

fl.iif -> rt_route_iif
rt_iif -> preserved

There are other places that used fl.iif (0 for output
routes) but are now using rt_iif instead of rt_route_iif, not sure if this change is fatal for them because:

- net/sched/cls_route.c, route4_classify() gets optional iif, so it can be 0, may be to match output route? And later route4_classify does exact match for rt_iif. Does it mean that now we can not match output packets without providing "fromif OUTDEV" ?

- net/sched/em_meta.c: now int_rtiif (being rt_iif) is always != 0, may be not good to match output routes?

	In short, the fl.iif -> rt_iif conversion is risky

at some places.

For now posting patch for route.c in another thread...

Regards

--
Julian Anastasov <[email protected]>

From: Julian Anastasov <[email protected]>
Date: Tue, 9 Aug 2011 16:51:26 +0300 (EEST)

If we convert em_meta.c and cls_route.c to use rt_route_iif we should be OK right? Please patches to do this if so.

Thanks.

Hello,

It seems the user space for route filter treats
0 as error, so "fromif if0" was never supported. So, using rt_iif is a better choice here.

May be using 'rt_iif eq 0' is silly for the meta match.
It is preferred to use rt_iif instead of rt_route_iif so that one can match even packets from loopback.

It seems no patches are needed. Sorry for the confusion.

Regards

--
Julian Anastasov <[email protected]>

From: Julian Anastasov <[email protected]>
Date: Thu, 11 Aug 2011 19:36:37 +0300 (EEST)

Ok, thanks for the clarification.