lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Caglar Akyuz
Subject: Re: [lwip-users] Broadcast packets breaking my network traffic
Date: Fri, 20 Jul 2007 10:09:24 +0300
User-agent: Thunderbird 1.5.0.8 (X11/20060911)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]