* return of ip_rt_bug()
@ 2011-08-02 17:09 Dave Jones
2011-08-04 7:23 ` David Miller
2011-08-04 12:20 ` Julian Anastasov
0 siblings, 2 replies; 18+ messages in thread
From: Dave Jones @ 2011-08-02 17:09 UTC (permalink / raw)
To: netdev; +Cc: Tom London
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-02 17:09 return of ip_rt_bug() Dave Jones
@ 2011-08-04 7:23 ` David Miller
2011-08-04 12:20 ` Julian Anastasov
1 sibling, 0 replies; 18+ messages in thread
From: David Miller @ 2011-08-04 7:23 UTC (permalink / raw)
To: davej; +Cc: netdev, selinux
From: Dave Jones <davej@redhat.com>
Date: Tue, 2 Aug 2011 13:09:42 -0400
> 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.
It should have been fixed by the patch below, but apparently not:
--------------------
>From ed6e4ef836d425bc35e33bf20fcec95e68203afa Mon Sep 17 00:00:00 2001
From: Julian Anastasov <ja@ssi.bg>
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
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/netfilter.c | 60 ++++++++++++++------------------------
net/ipv4/netfilter/ipt_REJECT.c | 14 ++------
2 files changed, 26 insertions(+), 48 deletions(-)
diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
index 4614bab..2e97e3e 100644
--- a/net/ipv4/netfilter.c
+++ b/net/ipv4/netfilter.c
@@ -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;
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index 1ff79e5..51f13f8 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -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
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-02 17:09 return of ip_rt_bug() Dave Jones
2011-08-04 7:23 ` David Miller
@ 2011-08-04 12:20 ` Julian Anastasov
2011-08-04 13:14 ` Tom London
1 sibling, 1 reply; 18+ messages in thread
From: Julian Anastasov @ 2011-08-04 12:20 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, Tom London
Hello,
On Tue, 2 Aug 2011, Dave Jones wrote:
> 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.
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 <ja@ssi.bg>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-04 12:20 ` Julian Anastasov
@ 2011-08-04 13:14 ` Tom London
2011-08-04 17:37 ` Julian Anastasov
0 siblings, 1 reply; 18+ messages in thread
From: Tom London @ 2011-08-04 13:14 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
On Thu, Aug 4, 2011 at 5:20 AM, Julian Anastasov <ja@ssi.bg> wrote:
>
> Hello,
>
> On Tue, 2 Aug 2011, Dave Jones wrote:
>
>> 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.
>
> 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 <ja@ssi.bg>
>
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-04 13:14 ` Tom London
@ 2011-08-04 17:37 ` Julian Anastasov
2011-08-04 17:48 ` Tom London
0 siblings, 1 reply; 18+ messages in thread
From: Julian Anastasov @ 2011-08-04 17:37 UTC (permalink / raw)
To: Tom London; +Cc: Dave Jones, netdev
Hello,
On Thu, 4 Aug 2011, Tom London wrote:
> How else can I help?
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 <ja@ssi.bg>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-04 17:37 ` Julian Anastasov
@ 2011-08-04 17:48 ` Tom London
2011-08-05 2:45 ` Tom London
0 siblings, 1 reply; 18+ messages in thread
From: Tom London @ 2011-08-04 17:48 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
On Thu, Aug 4, 2011 at 10:37 AM, Julian Anastasov <ja@ssi.bg> wrote:
>
> Hello,
>
> On Thu, 4 Aug 2011, Tom London wrote:
>
>> How else can I help?
>
> 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 <ja@ssi.bg>
>
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-04 17:48 ` Tom London
@ 2011-08-05 2:45 ` Tom London
2011-08-05 7:56 ` Julian Anastasov
0 siblings, 1 reply; 18+ messages in thread
From: Tom London @ 2011-08-05 2:45 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
On Thu, Aug 4, 2011 at 10:48 AM, Tom London <selinux@gmail.com> wrote:
> On Thu, Aug 4, 2011 at 10:37 AM, Julian Anastasov <ja@ssi.bg> wrote:
>>
>> Hello,
>>
>> On Thu, 4 Aug 2011, Tom London wrote:
>>
>>> How else can I help?
>>
>> 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 <ja@ssi.bg>
>>
>
> 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
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-05 2:45 ` Tom London
@ 2011-08-05 7:56 ` Julian Anastasov
2011-08-05 13:18 ` Tom London
0 siblings, 1 reply; 18+ messages in thread
From: Julian Anastasov @ 2011-08-05 7:56 UTC (permalink / raw)
To: Tom London; +Cc: Dave Jones, netdev
Hello,
On Thu, 4 Aug 2011, Tom London wrote:
> So, my router is just giving my wired NIC different addresses....
>
> More I can provide?
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 <ja@ssi.bg>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-05 7:56 ` Julian Anastasov
@ 2011-08-05 13:18 ` Tom London
2011-08-05 13:30 ` Tom London
2011-08-05 16:36 ` return of ip_rt_bug() Julian Anastasov
0 siblings, 2 replies; 18+ messages in thread
From: Tom London @ 2011-08-05 13:18 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>
> Hello,
>
> On Thu, 4 Aug 2011, Tom London wrote:
>
>> So, my router is just giving my wired NIC different addresses....
>>
>> More I can provide?
>
> 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 <ja@ssi.bg>
>
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-05 13:18 ` Tom London
@ 2011-08-05 13:30 ` Tom London
2011-08-05 13:37 ` Tom London
2011-08-05 16:36 ` return of ip_rt_bug() Julian Anastasov
1 sibling, 1 reply; 18+ messages in thread
From: Tom London @ 2011-08-05 13:30 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
On Fri, Aug 5, 2011 at 6:18 AM, Tom London <selinux@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>>
>> Hello,
>>
>> On Thu, 4 Aug 2011, Tom London wrote:
>>
>>> So, my router is just giving my wired NIC different addresses....
>>>
>>> More I can provide?
>>
>> 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 <ja@ssi.bg>
>>
>
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-05 13:30 ` Tom London
@ 2011-08-05 13:37 ` Tom London
2011-08-06 22:14 ` Julian Anastasov
0 siblings, 1 reply; 18+ messages in thread
From: Tom London @ 2011-08-05 13:37 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
On Fri, Aug 5, 2011 at 6:30 AM, Tom London <selinux@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 6:18 AM, Tom London <selinux@gmail.com> wrote:
>> On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>>>
>>> Hello,
>>>
>>> On Thu, 4 Aug 2011, Tom London wrote:
>>>
>>>> So, my router is just giving my wired NIC different addresses....
>>>>
>>>> More I can provide?
>>>
>>> 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 <ja@ssi.bg>
>>>
>>
>> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-05 13:18 ` Tom London
2011-08-05 13:30 ` Tom London
@ 2011-08-05 16:36 ` Julian Anastasov
1 sibling, 0 replies; 18+ messages in thread
From: Julian Anastasov @ 2011-08-05 16:36 UTC (permalink / raw)
To: Tom London; +Cc: Dave Jones, netdev
Hello,
On Fri, 5 Aug 2011, Tom London wrote:
> 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.
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 <ja@ssi.bg>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-05 13:37 ` Tom London
@ 2011-08-06 22:14 ` Julian Anastasov
2011-08-08 5:20 ` David Miller
0 siblings, 1 reply; 18+ messages in thread
From: Julian Anastasov @ 2011-08-06 22:14 UTC (permalink / raw)
To: Tom London; +Cc: Dave Jones, netdev
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.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
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
--- v3.0/linux/net/ipv4/route.c 2011-07-22 09:43:33.000000000 +0300
+++ linux/net/ipv4/route.c 2011-08-06 18:15:17.841066642 +0300
@@ -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)) {
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-06 22:14 ` Julian Anastasov
@ 2011-08-08 5:20 ` David Miller
2011-08-09 13:51 ` Julian Anastasov
0 siblings, 1 reply; 18+ messages in thread
From: David Miller @ 2011-08-08 5:20 UTC (permalink / raw)
To: ja; +Cc: selinux, davej, netdev
From: Julian Anastasov <ja@ssi.bg>
Date: Sun, 7 Aug 2011 01:14:22 +0300 (EEST)
> 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.
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 <hirofumi@mail.parknet.co.jp>
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!
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-08 5:20 ` David Miller
@ 2011-08-09 13:51 ` Julian Anastasov
2011-08-11 13:00 ` David Miller
0 siblings, 1 reply; 18+ messages in thread
From: Julian Anastasov @ 2011-08-09 13:51 UTC (permalink / raw)
To: David Miller; +Cc: selinux, davej, netdev
Hello,
On Sun, 7 Aug 2011, David Miller wrote:
> commit 1b86a58f9d7ce4fe2377687f378fbfb53bdc9b6c
> Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> Date: Thu Apr 7 14:04:08 2011 -0700
>
> ipv4: Fix "Set rt->rt_iif more sanely on output routes."
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 <ja@ssi.bg>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: return of ip_rt_bug()
2011-08-09 13:51 ` Julian Anastasov
@ 2011-08-11 13:00 ` David Miller
2011-08-11 16:36 ` rt_iif conversions (was Re: return of ip_rt_bug()) Julian Anastasov
0 siblings, 1 reply; 18+ messages in thread
From: David Miller @ 2011-08-11 13:00 UTC (permalink / raw)
To: ja; +Cc: selinux, davej, netdev
From: Julian Anastasov <ja@ssi.bg>
Date: Tue, 9 Aug 2011 16:51:26 +0300 (EEST)
> 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.
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* rt_iif conversions (was Re: return of ip_rt_bug())
2011-08-11 13:00 ` David Miller
@ 2011-08-11 16:36 ` Julian Anastasov
2011-08-12 1:01 ` rt_iif conversions David Miller
0 siblings, 1 reply; 18+ messages in thread
From: Julian Anastasov @ 2011-08-11 16:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Thomas Graf
Hello,
On Thu, 11 Aug 2011, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Tue, 9 Aug 2011 16:51:26 +0300 (EEST)
>
> > 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" ?
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.
> > - net/sched/em_meta.c: now int_rtiif (being rt_iif) is
> > always != 0, may be not good to match output routes?
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.
> > In short, the fl.iif -> rt_iif conversion is risky
> > at some places.
>
> 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.
It seems no patches are needed. Sorry for the confusion.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rt_iif conversions
2011-08-11 16:36 ` rt_iif conversions (was Re: return of ip_rt_bug()) Julian Anastasov
@ 2011-08-12 1:01 ` David Miller
0 siblings, 0 replies; 18+ messages in thread
From: David Miller @ 2011-08-12 1:01 UTC (permalink / raw)
To: ja; +Cc: netdev, tgraf
From: Julian Anastasov <ja@ssi.bg>
Date: Thu, 11 Aug 2011 19:36:37 +0300 (EEST)
> It seems no patches are needed. Sorry for the confusion.
Ok, thanks for the clarification.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-08-12 1:03 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-02 17:09 return of ip_rt_bug() Dave Jones
2011-08-04 7:23 ` David Miller
2011-08-04 12:20 ` Julian Anastasov
2011-08-04 13:14 ` Tom London
2011-08-04 17:37 ` Julian Anastasov
2011-08-04 17:48 ` Tom London
2011-08-05 2:45 ` Tom London
2011-08-05 7:56 ` Julian Anastasov
2011-08-05 13:18 ` Tom London
2011-08-05 13:30 ` Tom London
2011-08-05 13:37 ` Tom London
2011-08-06 22:14 ` Julian Anastasov
2011-08-08 5:20 ` David Miller
2011-08-09 13:51 ` Julian Anastasov
2011-08-11 13:00 ` David Miller
2011-08-11 16:36 ` rt_iif conversions (was Re: return of ip_rt_bug()) Julian Anastasov
2011-08-12 1:01 ` rt_iif conversions David Miller
2011-08-05 16:36 ` return of ip_rt_bug() Julian Anastasov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).