strange ip_reass issue on powerpc board, need help

[Rui Zhengxin]

On Friday, November 01, 2013 6:47 AM Nick Withers wrote:

Thanks Nick,

> On Thu, 2013-10-31 at 17:16 +0800, Rui Zhengxin wrote:
>> Hi all,
> 
> Hey Rui,
> 
>> My board is MPC8309SOM, the uec network adapter driver is port from 8313 tsec, it works well.
> 
> MVME3100 here, with the MPC8540 and a tsec.
> 
>> Now I meet a strange ip_reass issue, it cause a crash.
>> The condition is send a fragment packet with a non-zero ip_offset value but not set IP_MF flag.
> 
> Is that legal in the first place? You're talking about the "More
> Fragments" flag, yeah? Shouldn't that *always* be set for packets in a
> fragmented datagram?
> 
> 'Course if it ain't legal one still doesn't want to target to crash :-P
> 
>> It's very easy to make the fragment packet by ping the target board 65000 bytes after clearing PC's ARP table first.
> 
> What does clearing the ARP table here accomplish?

Sorry, I forgot to tell you, my PC is Windows XP,
I find that in Windows XP, if clear ARP table first, then send a big ip packet, the first  fragment of is abnormal.
It's just the last fragment, as I said "a non-zero ip_offset value but not set IP_MF flag".
The attached is the capture result of wireshark, the third packet is the abnormal fragment.

> In any event, I haven't been able to crash mine, running RTEMS 4.11 from
> the start of October.
> 
>> I trace the code, after call ip_reass, the mbuf chain may become not correct(ps: not everytime), the last mbuf's m_next pointer
>> not set to NULL. When the upper layer discard the fragment by calling m_freem, the invalid ext_free function pointer cause crash.
>> I don't know the reason why the mbuf chain is changed.
>> 
>> If you have MPC8313 or other powerpc board, can you help me verify the issue? Very tks for you help.
> 
> Any other thoughts? My pings're of the form "sudo ping -s 65000 -i 0.25"
> from a FreeBSD 9.2-STABLE host and aren't actually being responded to
> above 25152 B of data.

I  test on QEMU run i386 image, the issue not appear.
If send such an abnormal fragment, the "netstats -mp" command shows the MBUF ftable counter increased,
then after some time(ttl timeout), the IP Statistics of fragments timed out counter increased.

> I've also got pretty big mbuf (2 MiB) / mbuf cluster (4 MiB) buffers
> configured, perhaps that's something to do with it?
> 
>> Thanks & Best regards,
>> Rui Zhengxin
> 
> Hope that helps... It probably doesn't! :-(



Thanks & Best regards,
Rui Zhengxin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ping.pcap
Type: application/octet-stream
Size: 1576 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20131101/ec78314f/attachment.obj>