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

[Patrick McHardy <kaber@trash.net>]

Indan Zupancic wrote:
> On Wed, July 25, 2007 17:19, Patrick McHardy wrote:
> 
>>Indan Zupancic wrote:
>>
>>>Hello,
>>>
>>>After reading the "Never happen" comment in the code, I thought it
>>>wasn't too silly to mention that it apparently does happen. Never saw
>>>the message before, hence this mail. This happened on a machine
>>>doing SNAT for another pc, so conntrack may be involved.
>>>
>>>The three errors happen within 1.5 seconds of each other:
>>>
>>>[17834.377955] ipv4_get_l4proto: Frag of proto 17
>>>[17835.358985] ipv4_get_l4proto: Frag of proto 17
>>>[17835.872457] ipv4_get_l4proto: Frag of proto 17
>>>
>>>As this seems to be an incident, I've no idea how to debug it, nor
>>>whether it's worth debugging. If this can be caused by a peer
>>>sending a bad packet I'd ignore this report.
>>>
>>>If this is serious enough to be reported, perhaps it should be a BUG?
>>
>>It should not be serious, the packets are simply dropped.
> 
> 
> I meant serious in the sense of there being a bug in the code or not.
> If it indicates a bug then it might be better to make it a BUG or
> something else which gives more feedback to make it easier to track
> down. Right now it's not clear where the packet came from and goes to.


There is only one possible path, crashing peoples machines won't help :)
It does indicate a bug, but not a serious one.

>>Did it perhaps happen directly after nf_conntrack_ipv4 module load?
> 
> 
> No, it was loaded for at least a few hours.
> 
> 
>>Otherwise I think it might happen on loopback if you manually send
>>to large packets or possibly with NOTRACK. Any chance you're doing
>>anything of that?
> 
> 
> No idea what NOTRACK is, I've quite simple iptables rules and didn't do
> anything fancy at the time, so I don't think so.
> 
> As far as I can remember I was just browsing at the time, at least doing
> nothing that causes much UDP activity, DNS only. That said, I do run
> dnsmasq locally, so there is some loopback UDP activity, and it's also the
> DNS server for the SNATed host. Fair chance that there was more UDP
> activity from that host though (Quake3).
> 
> If it happens again I'll add extra debugging stuff and hope that it'll
> happen again. Currently it seems it's too vague to debug.


Thanks. One more question: are you running nfs?