[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] in-place overwriting of payload via static "tcphdr" poi

From: Bernhart Pelger
Subject: Re: [lwip-devel] in-place overwriting of payload via static "tcphdr" pointer.
Date: Wed, 10 Jan 2018 16:43:08 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

Am 10.01.2018 um 15:21 schrieb Simon Goldschmidt:
Bernhart Pelger wrote:
I know this sounds fundamentally broken, because other arriving packets
might be overwriting the free'd DMA buffers before LWIP or the
application had a chance to process it.
This does not *sound* fundamentally broken, it *is*!
But that's a different topic, not in the scope of this topic, or even
this mailing list.
And it doesn't affect me right now with my usage pattern.
It's a different topic, yes. I'm not 100% sure though that it doesn't
affect you. If you see cache issues now, how far away is an overwritten
Well I have no cache issues at all, when I flush the cache line containing the tcp header. This cache line contains the last few bytes from the IP header, the full TCP header, and a few (4?) bytes of payload data.

When I don't flush that cache line, under heavy rx traffic, once every 10 minutes or so I do get corrupted packets. When I inspect them in the debugger I see byte-flipped port numbers in the tcp header and the first few bytes corrupted in the payload (probably leftover data from the last processed packet).

It looks like this: (Y marks the cache line, X marks corruption, view with fixed-width-font)

It can't get any clearer than that: it's the write access to the tcp header (the IP header would also be corrupted, but you can't see that because the destination IP is the same for previous and current packet)

As for the other bug in the Xilinx driver (freeing the DMA buffers too early): With my current network configuration I should run into overwrite-problems after about 6ms to 10ms (at max rate RX traffic). However since I'm not using an operating system, it *is* possible to guarantee that the netif-function is called frequently enough.

Also the test environment for that bug would be a bit harder, because when polling too slow we always lose packets. So we have to destinguish between normal packet loss and actually overwritten packets.

Regards, Bernhart.


lwip-devel mailing list

Bernhart Pelger-Alzner
Entwicklungsingenieur Software
Tel:    +49 89 201804-261
Fax:    +49 89 201804-100
E-Mail: address@hidden

Lise-Meitner-Str. 2a, 85521 Ottobrunn, Germany
Postfach 1248, 85504 Ottobrunn, www.astyx.de
Reg.Nr.: M√ľnchen HRB 116 461, VAT: DE 186 893 572
CEO: Dipl.-Ing. G. Trummer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]