Re: RE : [lwip-users] (no subject)

There is a limitation in the current lwIP sys-arch layer: sys_mbox_post must never fail! The result when not posting a message to the mbox is unpredictable (although most of the time, the stack will lock up, just like you see it). So while returning void is of course correct, you must ASSER

Re:RE : [lwip-users] (no subject)

I set the maximal number of the message for a mbox to 2, so that it can be full easy.In the funtion sys_mbox_post, I set a counter, when it bigger than a maximal number(such as 10), the funtion return viod. I'm test the system, and look into from the debug information. I find my board died some

Re: [lwip-users] help

Your question is too broad. Can you try formulating it more precisely? What *exactly* do you need to do? On Dec 3, 2007 12:14 AM, lekhanh <[EMAIL PROTECTED]> wrote: > > > Dear all, > I have a project which uses lwIP but I don't know how to write my > programm, > How to use lwIP and how to run m

SV: SV: [lwip-users] Re: TCP_SEG Leak ...

Ok I try to fix the closing first. Take a look on it tomorrow Med vänlig hälsning/Best Regards Jan Wester _ WHI Konsult AB Scheelegatan 11, 112 28 Stockholm, Sweden www.whi.se [EMAIL PROTECTED] +46 8 449 05 30 _ Från: [EMAIL

AW: [lwip-users] Re: TCP_SEG Leak ...

Could you post a Wireshark trace plus debug output from your target? Without that it's pretty hard to tell where the error comes from. Simon Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jan Wester Gesendet: Mittwoch, 5. Dezember 2007 17:07

Re: SV: [lwip-users] Re: TCP_SEG Leak ...

Could you add a routine that checks for "all PCB is in CLOSING state" and issue a reset to the micro? Not a good solution for the long term (obviously lwip needs fix), but it would at least keep the system available for the short term. Andy "Jan Wester" <[EMAIL PROTECTED]> Sent by: [EMAI

SV: [lwip-users] Re: TCP_SEG Leak ...

Ok, I found it in my changelog Still not working, sometimes the last ack disappears and on close the pcb state is changed to CLOSING, forever After a while all pcb is in CLOSING state and I have to reset the system Med vänlig hälsning/Best Regards Jan Wester _

AW: [lwip-users] Re: TCP_SEG Leak ...

http://cvs.savannah.nongnu.org/viewvc/lwip/CHANGELOG?root=lwip&r1=1.267&r2=1.268 Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jan Wester Gesendet: Mittwoch, 5. Dezember 2007 16:26 An: 'Mailing list for lwIP users' Betreff: SV: [lwip-users] Re: T

SV: [lwip-users] Re: TCP_SEG Leak ...

Sorry about the version, I use 1.3.0, Ok, I have downloaded the latest cvs head, but nothing was mentioned in the changelog I shall start to test to see if it works Med vänlig hälsning/Best Regards Jan Wester _ WHI Konsult AB Scheelegatan 11, 112 28 Stockholm,

RE: [lwip-users] Re: TCP_SEG Leak ...

Hi, the fix for this bug is included in CVS head. I can't send you 'a fix' since I would have to create one for your lwIP version (by backporting it to the version of lwIP you use). You can either download a CVS version of lwIP ('pretty stable' at the moment... - no guarantee for that, though!

SV: [lwip-users] Re: TCP_SEG Leak ...

Hi Can you send me the fix for ooseq, I belive I have the same problem with my webserver with more simultane connections Med vänlig hälsning/Best Regards Jan Wester _ WHI Konsult AB Scheelegatan 11, 112 28 Stockholm, Sweden www.whi.se [EM

[lwip-users] losing ack

Hi version lwip 1.1.3 I using raw api with simultane pcb and callback for acked frames, and sometimes the callback is not generated for the last frame and on a timeout I close. In the active pcb I can see the pcb in closing state and it will never end up. After a while all pcb is in the closing st

RE : [lwip-users] (no subject)

Last, if this is your problem, take a look to https://savannah.nongnu.org/task/?7490 (task #7490 : Add return value to sys_mbox_post). Frédéric BERNON HYMATOM SA Chef de projet informatique Microsoft Certified Professional Tél. : +33 (0)4-67-87-61-10

RE : [lwip-users] (no subject)

Your problem is perhaps that tcpip_thread is blocked somewhere, which explains that your driver can post new input packets, because tcpip_thread doesn't fetch them (or too slowly). That's why you got "memp_malloc: out of memory in pool TCPIP_MSG_INPKT". One of the main cause of tcpip_thread bloc

SV: [lwip-users] (no subject)

Maybe I have the same problem, but I using raw api with simultane pcb and callback for acked frames, and sometimes the callback is not generated for the last frame and on a timeout I close. In the active pcb I can see the pcb in closing state and it will never end up. After a while all pcb is in t