Re: [lwip-users] Performance drop due port numbers reused too fast

/ action required to send FIN,ACK? Regards, Jochen ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Performance drop due port numbers reused too fast

wIP version are you using and is the ACK problem gone with master? Still on 1.4.1 due newer lwip versions are incompatible to the E70 GMAC driver and there are no efforts from the manufacturer to update the driver. Thanks, Jochen ___ lwip-users mail

Re: [lwip-users] Performance drop due port numbers reused too fast

out implementing a custom ephemeral port number generator which avoids port number reuse before MSL time is reached? Best regards, Jochen > ___ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/l

[lwip-users] Performance drop due port numbers reused too fast

, Jochen ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] ACK missing after SYN, strange high Ack Num

l you get extra delay. The problem is that the client application gets an CONNECTION_TIMEOUT error if RST happens. How to distinguish the 'RST on pending connection' from a 'server unreachable' error? Thanks, Jochen ___ lwip-users mailing list lwip-u

Re: [lwip-users] ACK missing after SYN, strange high Ack Num

Hello Indan, > I think the key here is "TCP Port numbers reused". If you open and close > many TCP connections to the same host MS Windows will re-used a recently > used port which is still in the CLOSE WAIT state on lwIP's side. You're probably right. The faster requests are sent, the more

Re: [lwip-users] ACK missing after SYN, strange high Ack Num

: ACKing on SYN is the correct behavior for a device which is not able to process the connection request? I still wonder about the 'insane high' number 4286058530 in the '[ACK] Seq=1 Ack=4286058530' reply, so I'm not sure if the protocol handling is correct here. Regards, Jochen

Re: [lwip-users] ACK missing after SYN, strange high Ack Num

Looks to me this is a performance issue. I never noticed such a problem over the last years. The problem seem to arise since http requests are sent from a more powerful (Intel) CPU. According to wireshark my 3 years old (Windows) laptop sends out 500 http packets/s, a newer laptop (Linux) sends

Re: [lwip-users] ACK missing after SYN, strange high Ack Num

No ideas? I still wonder if ACK after SYN is a protocol error or not. If it is an error, could this be an (probably well known) LWIP problem? What also puzzles me: according to the info provided in the wireshark trace, the ACK numbers reported in case of trouble seems not to be pure random, if

[lwip-users] ACK missing after SYN, strange high Ack Num

Hello, I'm running a Python requests script which aborts after running ca. 30 minutes with timeout > 5s. Telling from Wireshark, usually SYN is followed by SYN,ACK: 192.168.0.7 192.168.0.100TCP66 [TCP Port numbers reused] 57847 → 80 [SYN] Seq=0 Win=64240 Len=0

Re: [lwip-users] lwip reply delayed after long communication idle time

Still guessing what leads to (some) delays in a (http) reply. In the screenshot, http com starts (time 0, frame 78162) with SYN. Then, I see a TCP Retransmission (time 3.0, frame 78164). Between SYN and TCP Retransmission is a UDP broadcast (frame 78163 in the screenshot, frame 1289 in the

Re: [lwip-users] lwip reply delayed after long communication idle time

Not giving up on this... Although pinging 10 lwip's in a loop seems to work, from time to time I see kind of these records in the Wireshark log: Internet Control Message Protocol Type: 3 (*Destination unreachable*) Code: 2 (*Protocol unreachable*) Checksum: 0xfcfd [correct]

Re: [lwip-users] lwip reply delayed after long communication idle time

Another observation/idea/question: At the time ping times out or is delayed, I noticed a bulk of dest:FF... (broadcast?) messages: Antwort von 192.168.0.100: Bytes=32 Zeit=1ms TTL=255 Antwort von 192.168.0.100: Bytes=32 Zeit=1ms TTL=255 Antwort von 192.168.0.100: Bytes=32 Zeit=*60ms* TTL=255

Re: [lwip-users] lwip reply delayed after long communication idle time

Looks to me that LWIP does not respond to some ARP protocol requests of the host. Can you give me a hint what happens if these debug messages appear? 2012-01-01 00:00:06 [W]gmac_low_level_input: DMA buffer 0x2045d878 received, size=64 [idx=1] 2012-01-01 00:00:06 [W]gmac_rx_populate_queue: new

Re: [lwip-users] lwip reply delayed after long communication idle time

osting part of the traces in the message body but I don't know how to explain my observations in a short and more readable way. Pls find attached the wiresharc trace and LWIP debug printfs. If I can provide you further information or testing pls let me know. Thanks, Jochen pingprobs.pcap <http:/

Re: [lwip-users] lwip reply delayed after long communication idle time

Trace is attached. Pls check message no 300 and 1882 ff. Thanks 4forum.pcapng -- Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html ___ lwip-users mailing list lwip-users@nongnu.org

Re: [lwip-users] lwip reply delayed after long communication idle time

Now, in 2.1.x, the first http request after host and controller power up is served but still delayed for ca. 5s and I don't know if this is a "feature" or bug of ARP. Please have a look at the commented 1st trace below. The second trace shows the normal behavior. The controller immediately sends

Re: [lwip-users] lwip reply delayed after long communication idle time

Thanks for your answer. It seems to me that this is a bug in den ARP protocol handling of 1.4.1 I did not notice for years. The only thing I can tell is that the first ping replies take several seconds. But after some pings everything is ok. But without the pings the first http communication

Re: [lwip-users] lwip reply delayed after long communication idle time

Guess that ARP_MAXAGE which is set to 20 minutes explains the first part of my question. And scrolling thru the code I guess that there is a way to configure lwip in such a way that the IPs are not removed from the cache? And, after removing the IP from the cache the update of the cache (and

[lwip-users] lwip reply delayed after long communication idle time

, I'm still using lwip 1.4 for now. Thanks, Jochen 415917434.296389192.168.0.9 192.168.0.100 ICMP74 Echo (ping) request id=0x0001, seq=4480/32785, ttl=128 (reply in 4160) 416017434.296667192.168.0.100 192.168.0.9 ICMP74 Echo (ping) reply id=0x0001

Re: [lwip-users] Slow HTTP put request

Speaking of that, why do you use PUT anyway? I would have used POST to implement what you seem to do. PUT seems rather "unusual" to me... I thought PUT - because of its history? - is the right thing to send binary data to a server e.g. for firmware update. And a PUT header seems to be easier

Re: [lwip-users] Slow HTTP put request

I see the following solution: - server sends reply to expect/continue and then... well, frankly don't know exactly what happens then and how much overhead this means [..] I see 2 solutions: implement a HTTP 1.1 server that keeps to the specification (I'll have to do that for the lwIP httpd,

Re: [lwip-users] Slow HTTP put request

You should capture the traffic on your customer premises to make sure this is what's happening. I'm curious to know. Below is the trace of our customer. I think if you look at packets around no 2552 for example it shows the same behavior as curl in my understanding. Labview is waiting with a

Re: [lwip-users] Slow HTTP put request

> Try `curl -H "Expect:"` to remove it, or even `curl -0` to fallback to > HTTP1.0; but it won't help in your real life scenario. We don't know if > that is what happens on your customer side. Works like a charm! > You should capture the traffic on your customer premises to make sure > this is

Re: [lwip-users] Slow HTTP put request

Am 23.03.2018 21:10, schrieb goldsi...@gmx.de: On 23.03.2018 20:50, Jochen Strohbeck wrote: [..] I am able to reproduce the same problem using curl on windows and found out that even a PUT request with only a single byte payload takes about a second! If I do the same request with python

[lwip-users] Slow HTTP put request

where the problem is located. I put the wireshark output below. First is the output of the curl request, second the same request using python. Any ideas ? Jochen 13 11.971296 192.168.0.200 192.168.0.100 TCP 66 24773 → 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=4 SACK_PERM=1 14 11.971481

Re: [lwip-users] Problem running lwip on cortex M7 with D cache enabled

Jan Menzel: > Did you check the performance for your system? I suppose with buffers in > non-cached memory you do not have any benefits of the d-cache. If you > can't get any of the options I suggested to run, you still might use > dedicated non-cached RX buffers in the driver and copy received

Re: [lwip-users] Problem running lwip on cortex M7 with D cache enabled

Jan Menzel: > On 30.11.2017 23:09, Jochen Strohbeck wrote: >> As already written in my previous posts I can place the buffer >> descriptors to non-cache memory. I checked the address in the debugger. >> But if I try to place 'memp_memory' (which seems to be the data buffer

Re: [lwip-users] Problem running lwip on cortex M7 with D cache enabled

that makes _really_ sense. The next step would be to upgrade to 2.0.3 I guess. Jochen ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Problem running lwip on cortex M7 with D cache enabled

uffer must be implemented for cache management This sounds complicated to me. Therefore my first and probably stupid idea was to use explicit RX buffers, place them in non-cacheable memory and use them for RX payload instead of an allocated buffer. Does this probably work ? Regards, Jochen goldsimon: &

Re: [lwip-users] Problem running lwip on cortex M7 with D cache enabled

or is this driver already available in the STM or lwip source code package ? Regards, Jochen Am 30.11.2017 12:37, schrieb Noam Weissman: Hi, I am working with STM32F7 with LwIP 2.02 + FreeRTOS 9 D and I cache are enabled. TX/RX descriptors are hard coded inside DTCM. We have no problems for now

[lwip-users] Problem running lwip on cortex M7 with D cache enabled

Hello, I'm using lwip 1.4.1 and FreeRTOS on a SAME70 custom board with success if D-cache is disabled. If I enable the D-cache no more packets are received. If I place the RX descriptor into a non-cacheable region I get packets again but the received data is corrupt. Here is the lwip output: