lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] [lwip] Question and thoughts..


From: David Ryan
Subject: [lwip-users] [lwip] Question and thoughts..
Date: Thu, 09 Jan 2003 01:42:25 -0000

Hi..

I've recently downloaded lwip060rc1 and been working with that.  I 
finally got lwip so that I can *nearly* ping it from my pc, however 
ethereal is showing up that the ping response ICMP checksum is inccorect 
set as 0x335c ( should be 0x6e98 ).  Windows is throwing the response 
away as a bad packet.  I haven't started looking closely at the icmp or 
ip files yet..  but thought that this sort of error would not show up 
just in implementation?  Anyone have similar problem, or suggest how the 
environment might effect the outcome of the checksum?  The IP checksum 
is coming out correctly.

Also..  I'm creating a multithreaded implementation and attempting to 
use the API.  From the list I notice that not too many people are 
working with this.  Anyway.. too my point.  I noticed (due to a bug in 
my sys_arch_sem_wait code)  that memp, mem, pbuf (ones I've found so 
far) are calling sys_sem_wait.  sys_sem_wait has the side effect of 
checking/running timer code.  I would have thought it would make more 
sense to use the sys_arch_sem_wait directly for these type of semaphore 
locks.  I suggest that sys_sem_wait only be called on non-lock type 
semaphores..  ie..  waiting to receive a message to an mbox, etc.

I'd suggest that the whole sys.c module should be cleaned up to allow a 
seperate thread to handle timer code in a multithreaded implementation 
while still allowing a single threaded implementation to check timers 
another way.  Having sys_sem_wait have the side effects it does is very 
confusing.  Maybe a name change to sys_sem_wait_chk_timers?

Once I've got my implementation more stable I'll see if I can do some of 
these things.  Do people agree with where I'm going on this?

Thanks..
David.




[This message was sent through the lwip discussion list.]




reply via email to

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