headers
Stefano OLIVERI | 1 Jun 2011 11:32

Re: Anybody interested in converting simulated FreeRTOS/uIP project to lwIP?

Hi Claudius,

First of all, let me say that the work exist thanks to the contribution of many people, starting from Paul
(the work made on STR9), Ben (to move from the closed IAR toolchain to Eclipse+GCC), Richard and so on.

Actually I started to working at Cortex_STM32F107 demo in order to update to lwIP version 1.4.0. The demo
build with success but it doesn't work. At the moment I'm busy with other activity (like a FatFS demo, etc.)
and I have to spend little effort for this update.

I can send you the development version. If you are interested we can try to cooperate to this activity. Let me
know by emailing me at "software[at]stf12.net".

Regards,
Stefano

-----Original Message-----
From: Claudius Zingerli [mailto:lwip-usersmail@...] 
Sent: Tuesday, May 31, 2011 10:49 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Anybody interested in converting simulated FreeRTOS/uIP project to lwIP?

Hi Richard,

On 2011/5/30 18:51 PM, FreeRTOS Info wrote:
> If somebody wanted to take this project, convert the uIP web server to
> an lwIP web server, and send it back to me, I could then host it along
> with FreeRTOS, hopefully maintain it, and document it, and hopefully add
> extra example functionality over time.  The result would then (hopefully
> again, am I saying that too often) be a good development and test bed,
> and an excellent example of how to use lwIP in a multitasking environment.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kieran Mansley | 2 Jun 2011 10:47

Re: netconn_new (NETCONN_TCP) returns NULL

On Tue, 2011-05-31 at 18:00 +0100, MaX wrote:
> thank you very much for the replay. The return value of
> TCPIP_APIMSG(&msg)
> is -6.

If you look in include/lwip/err.h you can see that -6 is ERR_VAL.  The
most likely reason I can see for the netconn_new() code path to return
ERR_VAL is if you've given a type that it doesn't recognise: see
pcb_new() 

It would be worth adding some more verbose checking in that function to
see if it is returning ERR_VAL, or something else is the problem.  

Kieran
Permalink | Reply | 0 comments |
headers
Couch, Kelly J | 3 Jun 2011 00:11
Picon
Favicon

How to detect FIN / remote closed connection with netconn API?

I am using lwip 1.4.0 and must utilize netconn_new_with_callback

 

My reader thread blocks on a queue that is written to by the netconn_callback.  I merely detect when NETCONN_EVT_RCVPLUS is the event and write to a queue, then the blocking thread wakes up and processes the incoming data.

 

I have implemented something very similar to what is suggested via this thread: http://lists.gnu.org/archive/html/lwip-users/2011-02/msg00026.html

 

I have observed that a NETCONN_EVT_RCVPLUS with a ‘len’ of 0 coincides with connection events (but am uncertain if this is the ONLY reason for a 0 length event), like a newly established connection or a disconnected connection, however I can find no flags or other mechanism to confirm that the connection is indeed closed?

 

As a debugging attempt, I have tried using “netconn_set_nonblocking(pxNewConnection, TRUE);“ on a newly established connection, but calls to netconn_recv still block!?

 

It appears I can set the recv_timeout, which does return, but is not really the desired mechanism.

 

Any help is greatly appreciated.

 

Thanks.

 

-Kelly

 

_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 1 comment |
headers
Kieran Mansley | 3 Jun 2011 09:57

Re: How to detect FIN / remote closed connection with netconn API?

On Thu, 2011-06-02 at 15:11 -0700, Couch, Kelly J wrote:
> I have observed that a NETCONN_EVT_RCVPLUS with a 'len' of 0 coincides
> with connection events (but am uncertain if this is the ONLY reason
> for a 0 length event)

You will get a zero length event when:
 - the connection is first established 
 - the connection is closed either due to FIN, RST, local close or error
 - you receive a zero length UDP datagram.  

This last one (the zero length datagram) is probably something we need
to look into to check that the higher layers give correct behaviour, but
if your application isn't doing zero length sends then you can probably
ignore that and assume that an event with len=0 means the connection is
just opened or just closed.

Kieran
Permalink | Reply | 0 comments |
headers
hajot | 7 Jun 2011 14:47
Picon

Regression test problems for old bug #24212

Hi

I am just curious, if we have regression test problems with bug #24212 (I already reported some years ago).

In my latest application release I had to reintroduce the workaround to reorder unacked tcp segments.

(I am still using lwip 1.3.2, but this shouldn't do matter for this problem).

Regards
Hans-Joerg
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 5 comments |
headers
Kieran Mansley | 7 Jun 2011 15:27

Re: Regression test problems for old bug #24212

On Tue, 2011-06-07 at 12:47 +0000, hajot@... wrote:
> Hi
> 
> I am just curious, if we have regression test problems with bug #24212
> (I already reported some years ago).
> 
> In my latest application release I had to reintroduce the workaround
> to reorder unacked tcp segments.

A change to your application shouldn't have introduced a regression in
lwIP.  Either we didn't (completely) fix the problem in the first place,
or you also upgraded lwIP when you made your application release, and in
the intervening period the problem was re-introduced.

Did the fix that was committed for bug 24212 solve the problem you were
seeing at the time?  What changed between then and when you've had to
re-introduce the workaround?

Thanks

Kieran
Permalink | Reply | 1 comment |
headers
goldsimon-Mmb7MZpHnFY@public.gmane.org | 7 Jun 2011 17:48
Picon
Picon

Re: Regression test problems for old bug #24212

Kieran Mansley wrote:
> On Tue, 2011-06-07 at 12:47 +0000, hajot@... wrote:
>> Hi
>>
>> I am just curious, if we have regression test problems with bug #24212
>> (I already reported some years ago).
>>
>> In my latest application release I had to reintroduce the workaround
>> to reorder unacked tcp segments.
> A change to your application shouldn't have introduced a regression in
> lwIP.  Either we didn't (completely) fix the problem in the first place,
That's what I guess, since the code of the commit that fixed the bug is 
still in there:

lwip-commit mail:
http://lists.nongnu.org/archive/html/lwip-commits/2009-04/msg00028.html
diff of the fix:
http://cvs.savannah.gnu.org/viewvc/lwip/src/core/tcp_out.c?root=lwip&r1=1.80&r2=1.81

Could you please tell us what your actual fix is that you now added to 
fix the problem you are seeing?

Thanks,
Simon
Permalink | Reply | 0 comments |
headers
hajot | 7 Jun 2011 21:59
Picon

Re: Regression test problems for old bug #24212

Hi Kieran, hi Simon

Thanks for your replies. I am still busy with acceptance test of my application using lwip.
I will keep an eye on this issue (possible regression of bug 24212) an let you know about
my thoughts.

I have to reproduce the issue, to exclude the possibility that my application is mixing up
something. I saw one deadlocked tcp traffic without my fix. After fixing, there was no
more problem with tcp traffic. But perhaps this was a just a hap.

As I said, I will let you know
Hans-Joerg
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 2 comments |
headers
Soma Sundari | 8 Jun 2011 05:38
Picon

Sub:Error in Large File Transfer to remote server using RAW LWIP 1.3.0 (stellaris LM3S6432)


Hi Friends,
 
 
We have done webcient program and  can transmit file upto the size 1MB to our local server which
 
is located in our place.But when try to tranfer same size of file to the remote server the program hung
 
when the file size will be more than 7 KB.I can't identify what mistake behind this problem.And i have
 
sent the lwipopts.h with our configuration settings.please verify that and if need any changes for memory
 
allocation , let me know.
 
I think some of you may have experience with this.
 
So please help me to solve the issue soon.
 
 
Regrads,
 
Sundari.S
Attachment (lwipopts.h): text/x-chdr, 19 KiB
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 2 comments |
headers
Mehmet Ali Ekici | 8 Jun 2011 11:40

contrib project documentation

Hello,

I had looked at a very simple introduction document describing “contrib” project but unfortunatly there isn’t any. Is there such a document ?

 

Regards,

Mehmet Ali Ekici

 

_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 0 comments |

Gmane