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

[Frédéric BERNON]

>I guess this fits to the 3rd case. 

"tcpip_callback" is not the same thing that "raw api callbacks": the first one 
if a "message" send to the tcpip_thread (from tcpip.c), with a function pointer 
and an argument, to tell "hey, tcpip_thread, when you got this message, can you 
call - in your context - this function with this arg?". Note that 
tcpip_callback is asynchrone, and if you want to wait the end of the call of 
the function, you have to use a semaphore to synchronize all that.

I think you can call raw api without really using sequential api 
(netconn/socket), BUT, you should protect the core: you could call your 
netio_init using the tcpip_callback, or you can use the tcpip_init_done that 
you could provide in parameter of tcpip_init (you will be in tcpip_thread 
context). After that, the "raw api callbacks" will be called from tcpip_thread 
context: when a packet if receive by example, for during of the internal lwip 
timers (they are initialized and handle inside tcpip.c, and their executions 
can cause a callback to be invoked). 

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

It can be the problem (but perhaps I'm wrong): if tcpip_thread execute a timer, 
like tcp_tmr, and your TX want to write, you will stop the current timers 
processing in an "undefined" state, and call the "core" in this state, what is 
wrong!!! But, except if the core cause a priority inversion, I don't and if you 
disable task switching, I don't know why you could have this case.

So, for this part of the problem, you could :

- use tcpip_callback like Simon propose
- use one of the sequential/api

For ARP, you should :

- set ARP_QUEUEING=0
- increase your ARP table, since, each input packet (ARP or IP) update the 
table, so with a hub, any devices see all others devices.
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Caglar Akyuz
Envoyé : vendredi 20 juillet 2007 09:09
À : Mailing list for lwIP users
Objet : Re: [lwip-users] Broadcast packets breaking my network traffic


Goldschmidt Simon wrote:
>> 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.
> 

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:

struct tcp_pcb* netio_init(void)
{
        struct tcp_pcb *pcb;
        
        pcb = tcp_new();
        tcp_bind(pcb, IP_ADDR_ANY, PORT);
        pcb = tcp_listen(pcb);  
        tcp_accept(pcb, netio_accept);
        
        return pcb;
}

err_t netio_accept(void *arg, struct tcp_pcb *pcb, err_t err)
{
        tcp_arg(pcb, NULL);
        tcp_sent(pcb, netio_sent);
        
        tcp_recv(pcb, netio_recv);
        
        netio_pcb = pcb;        
        return ERR_OK;
}

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?

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

Caglar


_______________________________________________
lwip-users mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf