Re: ipv4_get_l4proto: Frag of proto 17

Re: ipv4_get_l4proto: Frag of proto 17

[Patrick McHardy]

Meelis Roos wrote:
> Yesterdays git snapsot on a normal home PC spams dmesg with the 
> following line:
> ipv4_get_l4proto: Frag of proto 17


In what situation does this happen?

Re: ipv4_get_l4proto: Frag of proto 17

[Meelis Roos]

> > Yesterdays git snapsot on a normal home PC spams dmesg with the following
> > line:
> > ipv4_get_l4proto: Frag of proto 17
> 
> In what situation does this happen?

It happens some times every hour on the average. Seems to be some UDP 
traffic. Firewall allows in any UDP that is ESTABLISHEFD,RELATED, DHCP 
(some more UDP rules with counter 0 so not important). Additionally 
there is internal netowkr that sometimes has a laptop but usually not 
and the messages have appeared also when there is nothin in the internal 
network.

Locally mldonkey is probably using UDP, and lsof -i | grep UDP tells 
that named, avahi-daemon, dhcpd, chronyd, nmbd and cupsd are listening 
on UDP sockets (most of them on internal network).

But I have no idea what application is causing the messages.

-- 
Meelis Roos (mroos@linux.ee)

Re: ipv4_get_l4proto: Frag of proto 17

[Patrick McHardy]

Meelis Roos wrote:
>>> Yesterdays git snapsot on a normal home PC spams dmesg with the following
>>> line:
>>> ipv4_get_l4proto: Frag of proto 17
>> In what situation does this happen?
> 
> It happens some times every hour on the average. Seems to be some UDP 
> traffic. Firewall allows in any UDP that is ESTABLISHEFD,RELATED, DHCP 
> (some more UDP rules with counter 0 so not important). Additionally 
> there is internal netowkr that sometimes has a laptop but usually not 
> and the messages have appeared also when there is nothin in the internal 
> network.
> 
> Locally mldonkey is probably using UDP, and lsof -i | grep UDP tells 
> that named, avahi-daemon, dhcpd, chronyd, nmbd and cupsd are listening 
> on UDP sockets (most of them on internal network).
> 
> But I have no idea what application is causing the messages.


I'm guessing that its ICMP errors containing UDP fragments.

Could you add a WARN_ON(1) to ipv4_get_l4proto() in
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c to verify
this?

Re: ipv4_get_l4proto: Frag of proto 17

[Meelis Roos]

> I'm guessing that its ICMP errors containing UDP fragments.
> 
> Could you add a WARN_ON(1) to ipv4_get_l4proto() in
> net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c to verify
> this?

Yes, it seems to be an ICMP error:

WARNING: at net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:93 ipv4_get_l4proto()
 [<c0103447>] show_trace_log_lvl+0x1a/0x2f
 [<c0103f2e>] show_trace+0x12/0x14
 [<c0103f45>] dump_stack+0x15/0x17
 [<f8cc60fc>] ipv4_get_l4proto+0x78/0xc0 [nf_conntrack_ipv4]
 [<f8d14fc4>] nf_ct_get_tuplepr+0x45/0xae [nf_conntrack]
 [<f8cc6777>] icmp_error+0x185/0x1f6 [nf_conntrack_ipv4]
 [<f8d1548f>] nf_conntrack_in+0xc0/0x409 [nf_conntrack]
 [<f8cc6251>] ipv4_conntrack_in+0x11/0x13 [nf_conntrack_ipv4]
 [<c028f16e>] nf_iterate+0x36/0x67
 [<c028f519>] nf_hook_slow+0x57/0xd6
 [<c0294a97>] ip_rcv+0x1d9/0x489
 [<c027a38e>] netif_receive_skb+0x2c9/0x34a
 [<f88ca79d>] rtl8139_poll+0x2a5/0x410 [8139too]
 [<c027bfa4>] net_rx_action+0x56/0xd5
 [<c011af47>] __do_softirq+0x38/0x7a
 [<c01048e5>] do_softirq+0x41/0x91
 =======================
ipv4_get_l4proto: Frag of proto 17

-- 
Meelis Roos (mroos@linux.ee)

Re: ipv4_get_l4proto: Frag of proto 17

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

Meelis Roos wrote:
>>I'm guessing that its ICMP errors containing UDP fragments.
>>
>>Could you add a WARN_ON(1) to ipv4_get_l4proto() in
>>net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c to verify
>>this?
> 
> 
> Yes, it seems to be an ICMP error:
> 
> WARNING: at net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:93 ipv4_get_l4proto()
>  [<c0103447>] show_trace_log_lvl+0x1a/0x2f
>  [<c0103f2e>] show_trace+0x12/0x14
>  [<c0103f45>] dump_stack+0x15/0x17
>  [<f8cc60fc>] ipv4_get_l4proto+0x78/0xc0 [nf_conntrack_ipv4]
>  [<f8d14fc4>] nf_ct_get_tuplepr+0x45/0xae [nf_conntrack]
>  [<f8cc6777>] icmp_error+0x185/0x1f6 [nf_conntrack_ipv4]


Thanks for testing. This patch removes the error message since its
perfectly valid for ICMP tracking to hand in a fragmented packet.


[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1553 bytes --]

[NETFILTER]: nf_conntrack_ipv4: fix "Frag of proto ..." messages

Since we're now using a generic tuple decoding function in ICMP
connection tracking, ipv4_get_l4proto() might get called with a
fragmented packet from within an ICMP error. Remove the error
message we used to print when this happens.

Signed-off-by: Patrick McHardy <kaber@trash.net>

---
commit 4846f19dbc2c1aca93784b08b9e3884ab8c36426
tree 86312e905ea0126863ff701088c94c6641b5e53b
parent 91574ca32eb052b31c976581e9723735e9acb53f
author Patrick McHardy <kaber@trash.net> Sat, 01 Sep 2007 18:17:13 +0200
committer Patrick McHardy <kaber@trash.net> Sat, 01 Sep 2007 18:17:13 +0200

 net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c |   10 +++-------
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
index d9b5177..53cb177 100644
--- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
@@ -87,14 +87,10 @@ static int ipv4_get_l4proto(const struct sk_buff *skb, unsigned int nhoff,
 	if (iph == NULL)
 		return -NF_DROP;
 
-	/* Never happen */
-	if (iph->frag_off & htons(IP_OFFSET)) {
-		if (net_ratelimit()) {
-			printk(KERN_ERR "ipv4_get_l4proto: Frag of proto %u\n",
-			iph->protocol);
-		}
+	/* Conntrack defragments packets, we might still see fragments
+	 * inside ICMP packets though. */
+	if (iph->frag_off & htons(IP_OFFSET))
 		return -NF_DROP;
-	}
 
 	*dataoff = nhoff + (iph->ihl << 2);
 	*protonum = iph->protocol;