[ECOS] ecos + lwip
Thu Sep 3 07:45:00 GMT 2009
>>> cyg_lwip_thread_new( "My thread", m_main, (void *)"My thread",
>>> my_stack, 0x1000, 5 );
>>> I'll enable more debugs to see where it's getting stuck.
>> After changing it to 2, it's able to find the interface (et0) with all
>> the right settings.
> Well, that does not really make sense. cyg_lwip_sequential_init() will not
> return until the lwip stack is initialized, and initializing ethernet device
> drivers is part of that. This *must* work even when the TCPIP thread has
> lower priority, as long as you start your application thread *after* the
> execution of cyg_lwip_sequential_init(). By starting *after* I mean that you
> also have to make sure that cyg_lwip_sequential_init() and starting your
> applications thread is done in the same thread!
> I hope I didn't miss the obvious here, but that's how it should work.
Well, I checked the code again. The netif init is done as part of
This I see is being called in tcpip_thread(). This function is being
executed in the
tcpip thread's context.
I guess this is why the priority of the threads matters.
Would do you think?
>> Now another problem has cropped up! :) Sorry.
>> My app's actually a DHCP server. So it receives DHCP packets with 0.0.0.0
>> as the src IP. However, the stack is dropping them with the following
>> ip_input: iphdr->dest 0xffffffff netif->ip_addr 0x101010b (0xffffff,
>> 0x1010b, 0xff000000)
>> ip_input: packet accepted on interface et
>> ip_input: packet source is not valid.
>> I've enabled the following in my config:
>> * Support broadcast filter
>> * Receive support
>> Is anything else needed?
> May I ask you to forward this question to the lwip mailing list, I have no
> experience on that subject myself.
Ok. I'll do that.
>> Just one more thing:
>> While tracing the path from cyg_lwip_sequential_init() to see what
>> all happens, I saw that
>> we end up calling lwip_init() twice!
>> Once in cyg_lwip_sequential_init() and then again in tcpip_init().
>> Why do we do it twice? The only function called between these 2 calls is
>> I think we can remove one of these. Or am I missing something?
> Well, that's a bug. Thanks for spotting. I wrapped a new release you can
> download from:
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss