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

[Goldschmidt Simon]

> My bad, I think I phrased my situation with the wrong words. 
> I'm registering callbacks, I'm not calling them in my TX 
> thread. Here is my simple server:
> 
[..]
> 
> I guess this fits to the 3rd case. In my TX task I only use 
> tcp_write and tcp_ouput. Since my RX task and tcpip_thread 
> have higher priority than my TX task, I just disable task 
> switching(actually RX interrupt) prior to using tcp_write. Do 
> you think I'm missing something here?
> 

I don't think I have fully understood your setup...
So are you calling core functions directly from TX thread or not?
You *must not* call tcp_write() or tcp_output() from any other thread
than tcpip_thread! This means if you want to write something from the
TX thread, set up a callback like this:

void write_callback(void *arg)
{
  tcp_write(arg->pcb, arg->data, arg->len, copy);
}

And in the TX thread, let it be called in the thread-context of
tcpip_thread:

tcpip_callback(write_callback, arg)

Where arg can be a struct containing the information necessary to send
data.
That way, you make sure the core stack is protected since it only is
used
fom one thread.

Every other usage is currently _not supported_! This might change in
future releases, but right now, it's the way to do it.

> > 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?).
> > 
> 
> is this mean that I should increase my arp table 
> size(curently 10) if I'm going to connect 20 devices to a 
> hub? I always thought that since my devices are going to send 
> and receive packets only to/from PC, they won't add arp 
> entries for other devices on the same hub.
> 

Normally, this shouldn't be a problem, I think (I don't know really,
since
this is somewhat implementation dependent). But to be on the safe side,
I
would increase the ARP table size for testing. You can turn it down
later
once it works to see if it was the problem.


Simon