Mailing List Archive

> > 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)

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?

> 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)

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.