lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-devel] Re: [lwip-users] filter broadcast packet


From: Jonathan Larmour
Subject: Re: [lwip-devel] Re: [lwip-users] filter broadcast packet
Date: Fri, 25 Jan 2008 16:39:02 +0000
User-agent: Thunderbird 1.5.0.12 (X11/20070530)

Piero 74 wrote:
> 
> 
> 2008/1/25, Jonathan Larmour <address@hidden
> <mailto:address@hidden>>:
> 
>     Piero 74 wrote:
>     >
>     > My  board will be a simple device  in a typical windows or unix
>     > network,  which  will accept tcp connection for  options programming
>     > and upgrade, and send/receive udp packets on event.
>     > For marketing reason it has to implement DHCP.
>     > So my idea:
>     > 1. on bootstrap, using dhcp session for get IP -----> driver will not
>     > block broadcast packet
>     > 2. when a new IP is available, enable broadcast packet filtering,
>     except ARP
>     >
>     > What do you think?
> 
>     You would have to make sure it worked for DHCP renewals as well.
> 
> 
> ... i understood... i thought using DHCP client only on boot, and after
> getting ip stop it... but it's NO correct... right?

Yes, that would not be correct. The DHCP client must stay running,
otherwise the DHCP server may reallocate your address after the lease expires.

>     This was a problem with code in 1.2.0 and earlier. The ARP code is
>     not safe
>     to call from any context other than the tcpip thread. For current
>     CVS (and
>     1.3.0) you need to be calling tcpip_input, which will automatically deal
>     with the ARP processing for you, but will do it all in the correct
>     context
>     of the tcpip thread.
> 
>     What I'm suggesting is calling tcpip_input from your irq, but only
>     if your
>     mboxes are irq-safe.
> 
> 
> ops... i'm working on lwip 120.... so, you suggest me to use lwip
> 130rc1.... which has different ethernetif_input (i'm seeing now...) and
> call tcpip_input from my irq...
> i'm thinking to se a flag when a emac irq occur, and reset it on exit,
> and check this flag on sy_mbox_post... in this way i can choose how rtos
> function call, normal or irq safe, depending on sys_mbox_post is called
> from irq or from stack. What do you think?

Sounds like it would work.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine




reply via email to

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