|Subject:||Re: [lwip-users] Transmission stall after ARP broadcast|
|Date:||Thu, 15 Feb 2018 17:21:45 +0000|
thank you for the fast response.
>> 1.4.1 is rather old. There have been numerous bugs fixed since then.
Yes I know. I would prefer to update, but I can't make this decision on my own.
>> A screenshot? WTF? If this is a screenshot of a wireshark log, please attach a pcap file instead.
Of course I have the log files. I was not sure if someone would look inside. In the Ti forum I get less attention. I attached 2 files. I cut about 100.000 frames to make them small.
The device with LwIP has the IP 192.168.211 and my connected notebook the IP 192.168.1.31.
>> No. In general, lwIP has *nothing* to do with your hardware. The netif driver is responsible for that.
I expected this answer, but was not sure about this. It was very curious that the port always stops with transmission of an ARP broadcast.
The device is configured as a switch with 2 ports. One port is connected, the other one is not. A task cyclically checks the second port for phy activity.
On 15.02.2018 16:05, Stephan Hilchenbach wrote:
The port stops transmitting after some minutes or hours. The DMA hardware register shows no errors but the transmission stalled. The DMA does not process further packets, but the content of the next packets looks OK.
When I run Wireshark I observe always the same sequence. Every time before the port stops transmission, the last packet sent was an ARP broadcast to the connected host "TexasIns_e4:2a:20 Broadcast ARP Who has 192.168.1.31? Tell 192.168.1.211". Curiously this is the only time the LwIP generates this request after connection was established. There are no other ARP broadcasts until the Tx stall. Attached is a screenshot.
I have two questions about this:
1. What is the reason for the LwIP to generate this ARP broadcast during transmission?
2. Can the LwIP cause a hardware Tx port to stall (because of the packet content)?
|[Prev in Thread]||Current Thread||[Next in Thread]|