Re: [lwip-users] Broadcast packets breaking my network traffic

[Caglar Akyuz]

Frédéric BERNON wrote:
>> Yes in my port it's enabled. Should I disable it?
> 
> It can be useful. Simon just fix it in current CVS HEAD, but since you use 
> lwip 1.1.0, I think you could have the problem
> 
>> I'm thinking if I should remove this or not... 
> 
> That's what we do now (There is an option for that). But in fact, even ARP 
> packets can cause the problem. That's why, in current code, all packets are 
> process in a "core protection" context (when you use tcpip.c).
> 
> 
>> I've read one of your posts about this issue on the list. ( December 2006, I 
>> guess). When do you think this will cause problems to me? For example, if I 
>> disable etharp_ip_input before calling tcp_output and re-enable it after 
>> tcp_sent, is it an enough protection? I really don't care answering arp 
>> requests for a short period of time as long as it is not a very very wrong 
>> move.
> 
> I don't know how is your application design, but saying you have two 
> contexts: one for your RX (your driver), and one for your application which 
> send the data. If your application send data, and there is a switch context 
> (note that sys_arch_protect only protect small parts of the code, like 
> allocation, etc..), and you start to process any input packet, you can 
> corrupt the core. But how do the "right" protection is dependant of your 
> driver, your port, and your application.
> 

Yes, there are 2 threads as you noted, actually I'm lying here. RX task
which is ethernetif_input is synced to the mac interrupt with a
semaphore. It has higher priority than my TX task. For this reason I'm
disabling mac interrupts before I call any "send related" function
(tcp_write and/or tcp_output). I wonder if it would be better or not to
increase the priority of TX task as an alternate solution.

However I don't have any idea what are the timer tasks as Kieran warned
me to protect them also. There is another task which is "tcpip_thread"
in tcpip.c . I'm confused here a little bit. From looking at the code,
this thread is also synced to ethernetif_input. If packet is an ip
packet ethernetif_input calls xNetIf->input( p, xNetIf ) which sends a
message to tcpip_thread. So I assume it is enough if I protect
ethernetif_input, only.

Anyway, this is my port. In my TX task I use raw api for sending and
using callbacks to receive data. I'm attaching a small packet capture
illustrating the problem. To catch the problem when it happens, I'm
closing connection to devices If I don't receive anything for a period
of 500 milliseconds.(Every device should send data at every 16 msecs).
Here 192.168.100.8 is the PC(windows machine), others are the lwIPs.
Everything is ok up to frame 117, then arp requests start and we don't
receive anything approx. 1 sec. There were some other arp requests
before but they didn't cause any harm. But I can assure that every time
this kind of locking occurs there is a broadcast message right before,
that's for sure.

Best Regards,
Caglar AKYUZ

errs.zip
Description: Zip archive