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

[Goldschmidt Simon]

> 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.

That seems OK (with the downside of up to lwIP 1.2.0, ARP is not
really protected.

> 
> 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 

THIS is wrong! You mustn't call raw functions from another thread
since tcpip_thread also uses them and this isn't protected (there
are some global variables that tcp uses which can be corrupted if
used from more than 1 thread).

-> Use core functions only from tcpip_thread
-> Use the sequential APIs (netconn/socket) if you want to transfer
from other threads
-> Or use tcpip_callback to run one of your functions in the thread-
context of tcpip_thread, that way you achieve protection of the core
stack.

ARP packets then still might corrupt something, but this is rather
seldom as long as you make sure your ARP table can simultaneously
hold all the addresses your device sees (may be big if used on a hub?).


Hope that helps.

Simon