* 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: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
* 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
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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.