Re: 2.6.23-rc1: ipv4_get_l4proto: Frag of proto 17

On Thu, July 26, 2007 12:22, Patrick McHardy wrote:
> Indan Zupancic wrote:
>> On Thu, July 26, 2007 11:50, Patrick McHardy
wrote:
>>
>>>iptables -t raw -I PREROUTING 
>>>	-m icmp --icmp-type destination-unreachable -j
LOG
>>>
>>>should log the packets.
>>
>>
>> So with this when I get a Frag of proto it should
also log an ICMP error?
>
>
> Exactly.
>
>> Considering that the errors happened with a near
exact 1 second interval
>> and a 0.5s interval I think it's highly likely that
it were retry packets to
>> an unreachable host. But why is the proto UDP and
not ICMP?
>
>
> Its the inner packet that is parsed by
nf_ct_get_tuplepr.
>

Reading the comment in icmp.c iph->frag_off &
htons(IP_OFFSET)
being true means that it's a fragment, but not the first
one.

So what's happening is that the host sends a big UDP packet,
it gets
fragmentated, but never reaches its destination. ICMP error
packets
are generated. Conntrack drops the latter ones thanks to the
check in
ipv4_get_l4proto.

So the question is whether those latter ICMP packets should
be forwarded
or not. If not, the code is fine and the warning message
could be removed.
If they should, then it might be hard for the current
conntrack code know
where to send the packet, as the UDP header is missing.

Greetings,

Indan

Indan Zupancic wrote:
>
> Reading the comment in icmp.c iph->frag_off &
htons(IP_OFFSET)
> being true means that it's a fragment, but not the
first one.
>
> So what's happening is that the host sends a big UDP
packet, it gets
> fragmentated, but never reaches its destination. ICMP
error packets
> are generated. Conntrack drops the latter ones thanks
to the check in
> ipv4_get_l4proto.
>
> So the question is whether those latter ICMP packets
should be forwarded
> or not. If not, the code is fine and the warning
message could be removed.
> If they should, then it might be hard for the current
conntrack code know
> where to send the packet, as the UDP header is
missing.

Yes, we can't associate them with the original connection.
We should catch this case in ICMP tracking though I think
instead of removing the message.