Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: iptables: Devel

Re: ipv4_get_l4proto: Frag of proto 17

 

 

iptables devel RSS feed   Index | Next | Previous | View Threaded


kaber at trash

Aug 30, 2007, 12:08 AM

Post #1 of 5 (1090 views)
Permalink
Re: ipv4_get_l4proto: Frag of proto 17

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?


mroos at linux

Aug 30, 2007, 6:04 AM

Post #2 of 5 (1033 views)
Permalink
Re: ipv4_get_l4proto: Frag of proto 17 [In reply to]

> > 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 [at] linux)


kaber at trash

Aug 31, 2007, 10:28 PM

Post #3 of 5 (1026 views)
Permalink
Re: ipv4_get_l4proto: Frag of proto 17 [In reply to]

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?


mroos at linux

Sep 1, 2007, 8:04 AM

Post #4 of 5 (1025 views)
Permalink
Re: ipv4_get_l4proto: Frag of proto 17 [In reply to]

> 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 [at] linux)


kaber at trash

Sep 1, 2007, 9:19 AM

Post #5 of 5 (1018 views)
Permalink
Re: ipv4_get_l4proto: Frag of proto 17 [In reply to]

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.
Attachments: x (1.52 KB)

iptables devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.