lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] Problem on Lwip on WIN2000


From: wilson gomes
Subject: [lwip-users] Problem on Lwip on WIN2000
Date: 20 May 2004 05:05:39 -0000

Dear All,

I am  a newbie to lwIP.I am  compiling Florian Schulze lwIP(light weight 
Internet Protocol) stack on MS Visual C++  for a RealTek RTL8139(A)-based PCI 
Fast Ethernet Adapter.When I Execute a test application built over the lwIP 
stack , the output which I get says "UlbytesReceived =0".Hence the application 
does not proceed from there.I am using WinPcap 2.2.Could any user who has 
executed lwIP on Windows 2000 help me out on this?I would appreciate a "Readme 
" on how to execute lwIP on Windows 2000.

Thanks and Best Regards,
Wilson Gomes
  


On Thu, 20 May 2004 address@hidden wrote :
>Send lwip-users mailing list submissions to
>       address@hidden
>
>To subscribe or unsubscribe via the World Wide Web, visit
>       http://mail.gnu.org/mailman/listinfo/lwip-users
>or, via email, send a message with subject or body 'help' to
>       address@hidden
>
>You can reach the person managing the list at
>       address@hidden
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of lwip-users digest..."
>
>
>Today's Topics:
>
>    1. Re: Bug in api_lib.c (Timmy Brolin)
>    2. RE: Accepting multicast UDP packets (Robert Brown)
>    3. lwIP on Redhat linux 7.1 (Bhattiprolu, Ravikumar (Ravikumar))
>    4. Dont fragment (DF) bit in IP Header (Martin Glunz)
>    5. Dont fragment (DF) bit in IP Header (Martin Glunz)
>    6. a question of tcp_ack (=?gb2312?B?wfXBvA==?=)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Sat, 15 May 2004 13:16:10 +0200
> From: Timmy Brolin <address@hidden>
>Subject: Re: [lwip-users] Bug in api_lib.c
>To: Mailing list for lwIP users <address@hidden>
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>
>Last I checked, lwip was not task safe. You are not supposed to run lwip
>as several tasks.
>But of course, I can be mistaken.
>
>Timmy
>
>address@hidden wrote:
>
> >Hello all,
> >
> >We have found a bug in the file api_lib.c. This bug affects the socket 
> >function lwip_send() that sometimes result in sending too much data over the 
> >TCP/IP connection under heavy loads.
> >
> >Details:
> >
> >Have a look into the function netconn_write() in file api_lib.c:
> >
> >659: if (size > tcp_sndbuf(conn->pcb.tcp)) {
> >660:   /* We cannot send more than one send buffer's worth of data at a
> >661:      time. */
> >662:   len = tcp_sndbuf(conn->pcb.tcp);
> >663: } else {
> >664:   len = size;
> >665: }
> >
> >This lines determine the currently available space in the TCP send buffer. 
> >The problem is the variable snd_buf that is targeted by the macro 
> >tcp_sndbuf():
> >
> >#define  tcp_sndbuf(pcb)  ((pcb)->snd_buf)
> >
> >The first problem is that this variable is changed (read-modify-write) by 
> >the TCP/IP-task and is read asynchronously by any other task working with 
> >the socket API. On machines that could store the variable in one single 
> >cycle back to memory this is not a real problem. But imagine lwip ran on a 
> >machine that needs two discrete stores to save the variable - a 
> >asynchronously running task could fetch an invalid value if the TCP/IP-task 
> >is interrupted while it stores the both half-words (in this case: two bytes) 
> >to memory.
> >
> >The second and more important problem is that the variable snd_buf is 
> >referenced twice in the above code fragment. In our tests, we got a 
> >condition where the task that currently executes the function 
> >netconn_write() was interrupted just between the lines 659 and 662 by the 
> >TCP/IP task that changed the variable snd_buf. This is an unwanted 
> >race-condition that normally really seldom happens, but in our tests it was 
> >over one time every 2 minutes at a data rate of around 35 mbit/s (running 
> >uCOS/II on a PowerPC440 @400MHz).
> >
> >The result is that the length 'len' gets a wrong value, leading to an 
> >underflow of the variable 'size' later in the code. We observed that in this 
> >cases 64kb or 128kb garbage data was transmitted (note that the variables 
> >'len' and 'size' have a width of 16bit).
> >
> >Solution of the problem: Before line 659, save snd_buf to a temporary 
> >variable and work then with this.
> >
> >Also, someone must find a better way to handle the snd_buf variable over 
> >task-borders, maybe by protecting it with an additional semaphore.
> >
> >Best Regards,
> >Dennis
> >
> >
> >
> >_______________________________________________
> >lwip-users mailing list
> >address@hidden
> >http://mail.gnu.org/mailman/listinfo/lwip-users
> >
> >
> >
> >
> >
>
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Sat, 15 May 2004 10:54:47 -0400
> From: "Robert Brown" <address@hidden>
>Subject: RE: [lwip-users] Accepting multicast UDP packets
>To: "Mailing list for lwIP users" <address@hidden>
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset="us-ascii"
>
>You are on the right track.  I implemented support for multicast IP in lwIP
>0.6.4 in the manner you have suggested.  My application is a Universal Plug
>and Play control point.  As such it is necessary to send and receive
>multicast IP packets.  The attached file contains some code snippets to
>indicate what I did to get this to work.
>
>I assume you are using an ethernet interface. Depending upon the nature of
>your application you may need to enable Rx for ethernet multicast addresses
>in your ethernet chip.
>
>Rob
>
>
>
>-----Original Message-----
> From: address@hidden
>[mailto:address@hidden Behalf
>Of Bilow Rodriguez
>Sent: Monday, May 03, 2004 5:59 PM
>To: address@hidden
>Subject: [lwip-users] Accepting multicast UDP packets
>
>
>Greetings lwip users!
>
>I am a newbie to lwip, but like it very much so far.
>We are using the socket level interface for an
>application using TCP and UDP networking.  So far,
>verything is great.
>
>The problem we have run in to now, though, is
>regarding how to make the application accept UDP
>multicast packets.
>
>Does one need to call netif_add() for the additional
>ip addresses corresponding to the multicast packets?
>Or is there a better way?
>
>Guidance and suggestions would be greatly appreciated.
>
>-Bilowfan
>
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Win a $20,000 Career Makeover at Yahoo! HotJobs
>http://hotjobs.sweepstakes.yahoo.com/careermakeover
>
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/lwip-users
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: sample_mcast.c
>Type: application/octet-stream
>Size: 5067 bytes
>Desc: not available
>Url : 
>http://mail.gnu.org/pipermail/lwip-users/attachments/20040515/4f275a4d/sample_mcast.obj
>
>------------------------------
>
>Message: 3
>Date: Mon, 17 May 2004 15:18:53 +0530
> From: "Bhattiprolu, Ravikumar \(Ravikumar\)" <address@hidden>
>Subject: [lwip-users] lwIP on Redhat linux 7.1
>To: <address@hidden>
>Message-ID:
>       <address@hidden>
>Content-Type: text/plain;      charset="us-ascii"
>
>Hi All,
>
>   I have downloaded and built the lwip on RH7.3 on a X86 machine. I am
>trying to get a simple socket example running on this machine and
>getting a lot of problems.
>
>   The server starts OK and the client gets killed on an assert statement
>in pbuf.c (in DDD it looks like it is having problems in ARP).
>
>Can any one please help me with:
>
>1. Simple socket example using lwip socket APIs
>2. A README sort of stuff to get this tap0 port working in our subnet.
>3. Example for developing simple application. The examples in lwip
>contrib area are little confusing since the files they use to build lwip
>library differ from each example.
>
>thanks in advance,
>with best regards,
>Ravi
>
>
>
>
>
>
>------------------------------
>
>Message: 4
>Date: Mon, 17 May 2004 07:19:23 +0200
> From: Martin Glunz <address@hidden>
>Subject: [lwip-users] Dont fragment (DF) bit in IP Header
>To: address@hidden
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset=iso-8859-1
>
>In src/core/ipv4/ip.c ip_output_if() sets the
>Don't fragment Flag (DF) in every IP Header:
>   IPH_OFFSET_SET(iphdr, htons(IP_DF));
>
>This caused problems when I tried to access an
>embedded device via the internet (ADSL Router at
>home and at work, port forwarding and dyndns.org service).
>Packets reached the device through the routers, then
>the device replied with a maximum length packet and
>the DF flag set. The router rejected this packet
>because the ADSL mtu is smaller than the regular
>ethernet mtu and the packet could not be fragmented.
>
>So I just reset the DF flag in lwip and everthing worked fine.
>Is there any reason why the DF flag is always set in lwip?
>
>
>--
>MfG
>Martin Glunz
>
>WANTED: Schrödinger's Cat. Dead or Alive.
>
>Isn't vi that text editor with two modes... one that beeps and one that
>corrupts your file?
>
>
>
>
>------------------------------
>
>Message: 5
>Date: Mon, 17 May 2004 13:52:29 +0200
> From: Martin Glunz <address@hidden>
>Subject: [lwip-users] Dont fragment (DF) bit in IP Header
>To: address@hidden
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset=iso-8859-1
>
>In src/core/ipv4/ip.c ip_output_if() sets the
>Don't fragment Flag (DF) in every IP Header:
>   IPH_OFFSET_SET(iphdr, htons(IP_DF));
>
>This caused problems when I tried to access an
>embedded device via the internet (ADSL Router at
>home and at work, port forwarding and dyndns.org service).
>Packets reached the device through the routers, then
>the device replied with a maximum length packet and
>the DF flag set. The router rejected this packet
>because the ADSL mtu is smaller than the regular
>ethernet mtu and the packet could not be fragmented.
>
>So I just reset the DF flag in lwip and everthing worked fine.
>Is there any reason why the DF flag is always set in lwip?
>
>
>--
>MfG
>Martin Glunz
>
>WANTED: Schrödinger's Cat. Dead or Alive.
>
>Isn't vi that text editor with two modes... one that beeps and one that
>corrupts your file?
>
>
>
>
>------------------------------
>
>Message: 6
>Date: Tue, 18 May 2004 16:44:42 +0800
> From: "=?gb2312?B?wfXBvA==?=" <address@hidden>
>Subject: [lwip-users] a question of tcp_ack
>To: "lwip-users" <address@hidden>
>Message-ID: <address@hidden>
>Content-Type: text/plain;      charset="gb2312"
>
>
>      On the project of simhost under Unix, when i set lwipopts.h TCP_WND = 
> 4096 ,
>use ->tcpdump -i tap0 ,
>(server(unix):192.168.1.162:4000, client(simhost):192.168.0.2 )capture some 
>data:
>
>16:12:34.374198 192.168.1.162.4000 > 192.168.0.2.4097: . 5455872:5456896(1024) 
>ack 1 win 5840 (DF)
>16:12:34.374206 192.168.1.162.4000 > 192.168.0.2.4097: . 5456896:5457920(1024) 
>ack 1 win 5840 (DF)
>16:12:34.374210 192.168.1.162.4000 > 192.168.0.2.4097: P 5457920:5458944(1024) 
>ack 1 win 5840 (DF)
>16:12:34.374214 192.168.1.162.4000 > 192.168.0.2.4097: . 5458944:5459968(1024) 
>ack 1 win 5840 (DF)
>16:12:34.374968 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5457920 win 2048 
>(DF)
>16:12:34.375182 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5459968 win 0 (DF)
>16:12:34.614123 192.168.1.162.4000 > 192.168.0.2.4097: . ack 1 win 5840 (DF)
>16:12:34.614391 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5459968 win 4096 
>(DF)
>16:12:34.614434 192.168.1.162.4000 > 192.168.0.2.4097: P 5459968:5460992(1024) 
>ack 1 win 5840 (DF)
>16:12:34.614442 192.168.1.162.4000 > 192.168.0.2.4097: . 5460992:5462016(1024) 
>ack 1 win 5840 (DF)
>16:12:34.614446 192.168.1.162.4000 > 192.168.0.2.4097: . 5462016:5463040(1024) 
>ack 1 win 5840 (DF)
>16:12:34.614450 192.168.1.162.4000 > 192.168.0.2.4097: P 5463040:5464064(1024) 
>ack 1 win 5840 (DF)
>16:12:34.615222 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5462016 win 2048 
>(DF)
>16:12:34.615437 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5464064 win 0 (DF)
>16:12:34.854113 192.168.1.162.4000 > 192.168.0.2.4097: . ack 1 win 5840 (DF)
>16:12:34.854370 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5464064 win 4096 
>(DF)
>16:12:34.854407 192.168.1.162.4000 > 192.168.0.2.4097: . 5464064:5465088(1024) 
>ack 1 win 5840 (DF)
>16:12:34.854414 192.168.1.162.4000 > 192.168.0.2.4097: P 5465088:5466112(1024) 
>ack 1 win 5840 (DF)
>16:12:34.854418 192.168.1.162.4000 > 192.168.0.2.4097: . 5466112:5467136(1024) 
>ack 1 win 5840 (DF)
>16:12:34.854422 192.168.1.162.4000 > 192.168.0.2.4097: . 5467136:5468160(1024) 
>ack 1 win 5840 (DF)
>16:12:34.855192 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5466112 win 2048 
>(DF)
>16:12:34.855408 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5468160 win 0 (DF)
>16:12:35.084111 192.168.1.162.4000 > 192.168.0.2.4097: . ack 1 win 5840 (DF)
>16:12:35.084363 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5468160 win 4096 
>(DF)
>16:12:35.084401 192.168.1.162.4000 > 192.168.0.2.4097: P 5468160:5469184(1024) 
>ack 1 win 5840 (DF)
>16:12:35.084408 192.168.1.162.4000 > 192.168.0.2.4097: . 5469184:5470208(1024) 
>ack 1 win 5840 (DF)
>16:12:35.084412 192.168.1.162.4000 > 192.168.0.2.4097: P 5470208:5471232(1024) 
>ack 1 win 5840 (DF)
>16:12:35.084416 192.168.1.162.4000 > 192.168.0.2.4097: . 5471232:5472256(1024) 
>ack 1 win 5840 (DF)
>16:12:35.085168 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5470208 win 2048 
>(DF)
>16:12:35.085381 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5472256 win 0 (DF)
>16:12:35.314111 192.168.1.162.4000 > 192.168.0.2.4097: . ack 1 win 5840 (DF)
>16:12:35.314354 192.168.0.2.4097 > 192.168.1.162.4000: . ack 5472256 win 4096 
>(DF)
>16:12:35.314391 192.168.1.162.4000 > 192.168.0.2.4097: . 5472256:5473280(1024) 
>ack 1 win 5840 (DF)
>
>    Server send the packet: ack 1 win 5840 (DF)  costs the time too long. Can 
> anyone help
>me? thanks!!
>
>
>address@hidden
>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2004-05-18
>
>------------------------------
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/lwip-users
>
>End of lwip-users Digest, Vol 9, Issue 12
>*****************************************



reply via email to

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