Re: [lwip-users] Improving UDP responses.

[Bill Auerbach]

Hi,

I know I'm late to the party but UDP throughput problems have to be at the 
driver level.  We produce an lwIP-based camera (752x480) on a slow 100Mhz CPLD 
softcore and with UDP for image transfers to the PC it can send over 60 images 
a second continuously.  This includes our own method for reliable transfers for 
dropped packets (which never happen on a private subnet unless 2 or more 
cameras are sending images at the same time). We don't need this speed 5 - 10 
per second is all we need, but it was a good test to run as fast as it will go 
and this is what we can achieve.  To be fair, this includes the image packet 
checksums being done in hardware, but that wasn't a big bottleneck before we 
did that.

Bill

-Original Message-
From: lwip-users  On 
Behalf Of goldsi...@gmx.de
Sent: Tuesday, September 21, 2021 1:50 PM
To: Mailing list for lwIP users 
Subject: Re: [lwip-users] Improving UDP responses.

Am 21.09.2021 um 14:59 schrieb Luciano Moretti:
> I've got an STM32F7 (SPL, not HAL) based project using LwIP RAW. We've 
> got it working fairly well, but it seems to handle 6 UDP packets very 
> quickly and then start dropping packets. I thought it was because of 
> the MEMP_NUM_UDP_PCB which was defined as 6, but increasing it to 12 
> has had no effect.
>
> Can you make any other recommendations as to how to increase our throughput?

I'm not aware of anything in lwIP limiting you here. It could be any memory 
shortage (debug this using lwip_stats) or it could be a driver issue somehow 
limiting the number of frames you can pull off your netif.

The STM drivers were somewhat buggy when I worked with them. Now some years 
have passed since then, but I don't know if they have been fixed by now.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Throughput is low in lwIP socket app.

[Bill Auerbach]

Hi,

Try TCP_MSS 1460 and try TCP_SND_BUF much larger and TCP_WND larger.

I run these with TCP_SND_BUF 32768 and TCP_WND 65534.

You didn’t say if the performance is poor sending, receiving or both.  Or the 
performance of the processor.  On our platforms we have no issue with 
throughput, but we use RAW_API (NO_SYS=1) and use a custom OS so it’s hard to 
compare.

Bill

From: lwip-users  On 
Behalf Of Ibtisam Tariq
Sent: Wednesday, May 26, 2021 4:34 AM
To: lwip-users@nongnu.org
Subject: [lwip-users] Throughput is low in lwIP socket app.

Hi.

My application is running fine but I am facing an issue in throughput while 
using the lwIP socket app.
I have integrated the lwIP stack over DPDK and the application is written by 
using the lwIP sockets API. Hence the whole module contains three threads.
- One thread takes packets continuously from the DPDK recv 
function(rte_eth_rx_burst) in a forever while loop, then takes a packet convert 
the mbuf to pbuf and pass it to the lwIP stack by calling netif->input function 
(tcpip_input).
- Second thread is the lwIP core thread which processes the packet in the stack.
- The third thread is the application thread which is created by using lwIP 
socket APIs.
and in the sending side, when the user calls the sendto function from the 
application in the 3rd thread, this invokes the 2nd thread which at the end 
calls netif->linkoutput function. This function converts pbuf to mbuf and sends 
pkt through the DPDK tx function(rte_eth_tx_burst). In this system, all threads 
are running on different cores.

With the help of this structure, I have created a simple UDP send application. 
The code is:
...
char FixMsg[267]="" //sample msg
while (1)
   {
int bytesSent=sendto(UDPSocket, FixMsg, 267, 0, (const struct sockaddr 
*)&serv_addr, sizeof(serv_addr));
   }
...
My application is capable of sending 500-600 pkts/sec. This throughput capacity 
is poor. I need to enhance it.
I have adjusted all buffer sizes according to my structure of application. I 
have seen no errors of buffer overflow in lwIP statistics, displaying them 
using stats_display() function.
The lwipopts.h is:

/**
 * @file
 *
 * lwIP Options Configuration
 */

/*
 * Copyright (c) 2001-2004 Swedish Institute of Computer Science.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without 
modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice,
 *this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright notice,
 *this list of conditions and the following disclaimer in the documentation
 *and/or other materials provided with the distribution.
 * 3. The name of the author may not be used to endorse or promote products
 *derived from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
EVENT
 * SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
PROCUREMENT
 * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
ARISING
 * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
POSSIBILITY
 * OF SUCH DAMAGE.
 *
 * This file is part of the lwIP TCP/IP stack.
 *
 * Author: Adam Dunkels mailto:a...@sics.se>>
 *
 */
#ifndef LWIP_LWIPOPTS_H
#define LWIP_LWIPOPTS_H

/*
 * Include user defined options first. Anything not defined in these files
 * will be set to standard values. Override anything you don't like!
 */
#include "lwipopts.h"
#include "lwip/debug.h"

/*
   ---
   -- Platform specific locking --
   ---
*/

/**
 * SYS_LIGHTWEIGHT_PROT==1: if you want inter-task protection for certain
 * critical regions during buffer allocation, deallocation and memory
 * allocation and deallocation.
 */
#define SYS_LIGHTWEIGHT_PROT0

/**
 * NO_SYS==1: Provides VERY minimal functionality. Otherwise,
 * use lwIP facilities.
 */
#define NO_SYS  0

/*
   
   -- Memory options --
   
*/

/**
 * MEM_ALIGNMENT: should be set to the alignment of the CPU
 *4 byte alignment -> #define MEM_ALIGNMENT 4
 *2 byte alignment -> #define MEM_ALIGNMENT 2
 */
#define MEM_ALIGNMENT   1U

/**
 * MEM_SIZE: the size of the heap memory. If the application will send
 * a

Re: [lwip-users] lwIP 1.4.1 stable tcp connection stall

[Bill Auerbach]

goldsi...@gmx.de writes:

Maybe. As a starter, you should disable everything you can in tcp_output 
(TCP_OUTPUT_DEBUG, TCP_CWND_DEBUG). Then once the error happens, try dumping 
the lwip_stats plus the whole tcp_pcb that doesn't send any more. There's no 
function to do that, so you'll have to write that on your own. I mean every 
member of the tcp_pcb plus all "interesting" members of lists like unsent, 
unacked etc.

Below is debug output for TCP up until it fails (minus a lot more ahead of that 
that was OK).  The last 4 lines repeat forever. Our application disconnects and 
reconnects after 5 seconds of no response which unfortunately has kept 
customers at bay because the system does recover on its own.  We make 
commercial ink jet printers so if the customer is printing it's bad - even 
worse with a 500 lb paper roll.  The only good thing is only one customer is 
seeing disconnects hourly or more.  I get them in less than 5 minutes which is 
great for testing.

tcp_receive: pcb->rttest 467 rtseq 44078 ackno 44410
tcp_receive: experienced rtt 1 ticks (500 msec).
tcp_receive: RTO 4 (2000 milliseconds)
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 63244, cwnd 23364, wnd 23364, seg == NULL, ack 44410
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 63244, cwnd 23364, wnd 23364, seg == NULL, ack 44410
tcp_write(pcb=0x008449f8, data=0x0083ae20, len=332, apiflags=0)
tcp_write: queuelen: 0
tcp_write: queueing 44410:44742
tcp_write: 2 (after enqueued)
tcp_output: snd_wnd 63244, cwnd 23364, wnd 23364, effwnd 332, seq 44410, ack 
44410
tcp_output: snd_wnd 63244, cwnd 23364, wnd 23364, effwnd 332, seq 44410, ack 
44410, i 0
tcp_output_segment: rtseq 44410
tcp_output_segment: 44410:44742
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 63244, cwnd 23364, wnd 23364, seg == NULL, ack 44410
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 63244, cwnd 23364, wnd 23364, seg == NULL, ack 44410
tcp_receive: window update 62912
tcp_receive: congestion avoidance cwnd 23455
tcp_receive: queuelen 2 ... 0 (after freeing unacked)
tcp_receive: pcb->rttest 469 rtseq 44410 ackno 44742
tcp_receive: experienced rtt 1 ticks (500 msec).
tcp_receive: RTO 4 (2000 milliseconds)
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 62912, cwnd 23455, wnd 23455, seg == NULL, ack 44742
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 62912, cwnd 23455, wnd 23455, seg == NULL, ack 44742
tcp_write(pcb=0x008449f8, data=0x0083af6c, len=332, apiflags=0)
tcp_write: queuelen: 0
tcp_write: queueing 44742:45074
tcp_write: 2 (after enqueued)
tcp_output: snd_wnd 62912, cwnd 23455, wnd 23455, effwnd 332, seq 44742, ack 
44742
tcp_output: snd_wnd 62912, cwnd 23455, wnd 23455, effwnd 332, seq 44742, ack 
44742, i 0
tcp_output_segment: rtseq 44742
tcp_output_segment: 44742:45074
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 62912, cwnd 23455, wnd 23455, seg == NULL, ack 44742
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 62912, cwnd 23455, wnd 23455, seg == NULL, ack 44742
tcp_receive: window update 64240
tcp_receive: congestion avoidance cwnd 23545
tcp_receive: queuelen 2 ... 0 (after freeing unacked)
tcp_receive: pcb->rttest 471 rtseq 44742 ackno 45074
tcp_receive: experienced rtt 1 ticks (500 msec).
tcp_receive: RTO 4 (2000 milliseconds)
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 64240, cwnd 23545, wnd 23545, seg == NULL, ack 45074
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 64240, cwnd 23545, wnd 23545, seg == NULL, ack 45074
tcp_write(pcb=0x008449f8, data=0x0083b0b8, len=332, apiflags=0)
tcp_write: queuelen: 0
tcp_write: queueing 45074:45406
tcp_write: 2 (after enqueued)
tcp_output: snd_wnd 64240, cwnd 23545, wnd 23545, effwnd 332, seq 45074, ack 
45074
tcp_output: snd_wnd 64240, cwnd 23545, wnd 23545, effwnd 332, seq 45074, ack 
45074, i 0
tcp_output_segment: rtseq 45074
tcp_output_segment: 45074:45406
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 64240, cwnd 23545, wnd 23545, seg == NULL, ack 45074
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 64240, cwnd 23545, wnd 23545, seg == NULL, ack 45074
tcp_receive: window update 63908
tcp_receive: congestion avoidance cwnd 23635
tcp_receive: queuelen 2 ... 0 (after freeing unacked)
tcp_receive: pcb->rttest 473 rtseq 45074 ackno 45406
tcp_receive: experienced rtt 1 ticks (500 msec).
tcp_receive: RTO 4 (2000 milliseconds)
tcp_output: nothing to send (0x)
tcp_output: snd_wnd 63908, cwnd 23635, wnd 23635, seg == 

Re: [lwip-users] lwIP 1.4.1 stable tcp connection stall

[Bill Auerbach]

Hi Simon,

I see a zero window persist timer bugfix entry in 1.4.1.

I can ping-pong 2.0.2 and 1.4.1 and make the error come and go. At first on the 
NIOS II but being slower and harder to debug I just got the PowerPC converted 
to 2.0.2 and it’s working there too (as expected).  The PowerPC allows me 
faster debugging and much more horsepower to output debug information.  And I 
can get the debug output in Telnet.  I can debug some, yes, but I’m no expert 
on this part of lwIP or TCP.  So I need help in what information is best to 
gather. I can pause when the sending stops and get to these variables.  Would 
output from LWIP_DEBUG_ONs (whichever ones are pertinent) show you anything 
about what’s happening?

Thank you for replying. Your dedication to this product is evident by your 
interest in knowing what fixed something in an older version. Due to time I may 
have to push a 2.0.2-based release out.  Do to the seriousness I could see you 
pushing a DIY code change for users to update 1.4.1 code to reduce the concern 
of a major update.  It got some nervous here when I said there were probably a 
hundred changes in 2.x. But I’ve already run a test with 3 devices using 30M 
packets and I see no differences from 1.4.1. I will run overnight as well.

Bill

From: lwip-users 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
goldsimon
Sent: Wednesday, August 09, 2017 10:45 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] lwIP 1.4.1 stable tcp connection stall

Hey Bill,

Great to hear 2.0.2 fixes this. I'm a bit lost thinking about a bug fix. We had 
some since then I guess, and I would have to dig through the log myself.
However, the most obvious would be a zero window where the persist timer 
doesn't start or somehow doesn't work correctly.

Are you able to reproduce this now? Can you debug it? Would you need help in 
debugging?

I'm not at my PC very often right now, but I'll see if I find something. Maybe 
you can dump the PCB in question once it stops plus lwip_stats, that could help 
finding the issue.

Simon
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] lwIP 1.4.1 stable tcp connection stall

[Bill Auerbach]

Hello group,

First, thanks to everyone for the continued development and support of lwIP - 
it been great to see it so active the past few years.  This purpose of this 
message is to notify lwIP 1.4.1 stable users of a problem, and to see if anyone 
(i.e. developers) knows the bug report that would have resolved this.  The 
problem is, based on network traffic that I have been unable to pinpoint, the 
TCP outbound communication stalls.  I am unsure in the debug logs what lwIP is 
trying to do with each tcp_output, but nothing goes out the wire.  Packets come 
and go from the device as I can still open telnet, ping, and use a UDP protocol 
on the device.  We use NO_SYS=1, a cooperative multi-tasking system, UDP and a 
single TCP connection.  1.4.1 was great for over 5 years.

We install systems on a local subnet (only a PC NIC and lwIP/Lantronix devices 
- anywhere from 2 to 10).  A critical customer has been complaining for months 
about our devices disconnecting.  We report a disconnect error when we stop 
getting repeating status messages back from all devices.  I'd heard of this 
occurring intermittently over the years and we always wrote it off as 
electrical problems since we're usually in a noisy environment.  Until by 
chance, I connected my local subnet switch to our corporate network and I was 
seeing disconnects on all lwIP devices I have connected. I don't know why.  
This customer must have the same traffic on the subnet that I see on the 
corporate network.

The first thing I did was upgrade to 2.0.2.  Other than very few minor changes, 
everything builds and runs.  The TCP send stalls are gone.  I went back to lwIP 
1.4.1 and they came back.  Good, I had a test and a solution.  We decided here 
the best approach is to try to patch 1.4.1 with the fix for this for the 
critical customer and then use a controlled rollout and test plan for lwIP 
2.0.2 which means updating 9 of our lwIP devices.  I spent about half a day 
checking the CHANGELOG and trying a few patches in the bug reports mentioning 
TCP and no change I made resolved the problem.  The one mention for TCP 
stalling was with a new scaling window feature in lwIP 2.x.  I would have 
thought a bug-fix regarding stalled TCP sends would be easy to find in the list 
- this is a big deal in a TCP/IP stack.

My question to developers is, does anyone recall a change that resolved TCP 
send stalling?  And a note to lwIP 1.4.1 stable users - you should update to 
2.x.

Thank you - best regards,
Bill Auerbach
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP raw TCP socket disconnection

[Bill Auerbach]

>It is not common to have the cable unplugged, but if you must detect that, you 
>need an
>ethernet driver (and chip/controller) with link status indication.

Be aware that checking the link status still isn't always enough.  If you're 
connected to a switch and your connection into the switch is disconnected, you 
still see a link but the connection is broken.

Bill

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Patch to update from 1.4.0 to 1.4.x?

[Bill Auerbach]

>On 20/03/2015 17:56, Sylvain Rochet wrote:



>They even do perfect documentation (perfect documentation is almost

>always the case with Atmel) about lwIP[1], way better than our own lwIP

>documentation, and which really prove they have a deep understanding of

>lwIP internals.



>We really should ask Atmel if we can re-use their documentation in order

>to improve by several order of magnitude the quality of lwIP embedded

>documentation.



They already have given this permission.



Bill


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Best set of configuration options

[Bill Auerbach]

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
goldsi...@gmx.de
Sent: Monday, October 05, 2015 2:48 PM
To: andy.p...@sdcsystems.com; Mailing list for lwIP users
Subject: Re: [lwip-users] Best set of configuration options

Andy Pont wrote:
>> [..]ROM space is therefore limited (64K max for everything) as are the 
>> services that are available.
>>

>I would disable these, unless you need them of course: IP_REASSEMBLY, IP_FRAG, 
>LWIP_ICMP, LWIP_RAW, LWIP_UDP, TCP_QUEUE_OOSEQ, TCP_OVERSIZE, 
>LWIP_HAVE_LOOPIF, 
>LWIP_STATS.
>
>Also, make sure LWIP_DEBUG is not defined and make sure LWIP_NOASSERT is 
>defined.
>
>If your hardware supports checksum generation/check in hardware, set all
>CHECKSUM_GEN_*/CHECKSUM_CHECK_* defines to 0.

This is very good!  Wiki-worthy IMO.

Bill


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Handling in case of disabled Nagle

[Bill Auerbach]

Or it’s simply a problem with your (OP’s) PC. I’ve used wireshark since it was 
Ethereal and never had a crash.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Radouch, Zdenek
Sent: Tuesday, December 09, 2014 8:43 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Handling in case of disabled Nagle

 

Ø  Wireshark does not work - it crashes on capturing. This is for sure a 
Windows-problem…

 

I seriously doubt it. I don’t use Windows, but I use Wireshark all the time and 
the versions that came

with the last couple Ubuntu Linux releases crash all the time, in quite random 
ways.

I have been able to avoid the crashes by building Wireshark myself, from the 
latest sources.

I don’t know if you can build open source tools like Wireshark yourself (since 
WIndows don’t come

with compilers), but I would definitely recommend trying the latest possible 
version of Wireshark

since some of the [older] versions can be quite unstable. 

 

Cheers,

-Z

 

From: lwip-users-bounces+zradouch=irobot@nongnu.org 
[mailto:lwip-users-bounces+zradouch=irobot@nongnu.org] On Behalf Of Karl 
Karpfen
Sent: Tuesday, December 09, 2014 3:25 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Handling in case of disabled Nagle

 

2014-12-08 19:47 GMT+01:00 goldsi...@gmx.de :

As it's always better to know than to guess, why don't you check wih wireshark?

 

Simply because Wireshark does not work - it crashes on capturing. This is for 
sure a Windows-problem but it keeps me away from analysing this. 

 

But connection problems I described does not seem to have the same reason like 
this crash, I could do a (very quick) test on a different Windows PC, there I 
could observe the same.

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Get IP address of client in RAW API

[Bill Auerbach]

Hello,

The PCB pointer in the accept callback has it.

If it's named tcb_pcb *pcb then pcb->remote_ip.addr is it.

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of mobin.seven
Sent: Tuesday, October 21, 2014 8:46 AM
To: lwip-users@nongnu.org
Subject: [lwip-users] Get IP address of client in RAW API

Hi

my question is the title!
How to get IP address of client in RAW API in server side?

thanks



--
View this message in context:
http://lwip.100.n7.nabble.com/Get-IP-address-of-client-in-RAW-API-tp23416.ht
ml
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] How to check send state?

[Bill Auerbach]

Yeah, I should have kept reading.  Sorry

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Simon Goldschmidt
Sent: Tuesday, September 16, 2014 9:51 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] How to check send state?

 

Bill, I appreciate you trying to teach programming basics, but I think this 
won't get Karl Karpfen further: sending from main-loop and receiving in 
interrupt just won't work with lwIP.

 

Simon

  

Gesendet: Dienstag, 16. September 2014 um 15:43 Uhr
Von: "Bill Auerbach" 
An: "'Mailing list for lwIP users'" 
Betreff: Re: [lwip-users] How to check send state?

Hi,

 

Did you declare sentLength as volatile?  You might also need to protect it if 
it’s not loaded/stored in a single processor instruction (not likely to be the 
case with a 32-bit architecture).

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Karl Karpfen
Sent: Monday, September 15, 2014 3:00 PM
To: lwip-users@nongnu.org
Subject: [lwip-users] How to check send state?

 

Hi,

within my lwIP application (TCP with permanent connection) I'm sending some 
data out of main-loop (no interrupt context) and start submission by calling

tcp_output(currentPcb);

Sending of data is done via tcp_write(). Within the send function itself amount 
of data already sent is stored in a variable sentLength. Now to find out if it 
is possible to send next bunch of data I check this variable. When its size is 
equal to the length of the previous data buffer, sending was completed and I 
start submission of next buffer.

 

My problem here: sentLength is manipulated out of interrupt context while 
checking it for completion is done out of main loop. It seems this sometimes 
causes troubles, at receiver side I can see incomplete frames.

So my question: what is the correct way to find out if currentPcb has finished 
sending (or better has pushed all data to tcp_write()) and is ready to accept 
next bunch of data?

Thanks!

___ lwip-users mailing list 
lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] How to check send state?

[Bill Auerbach]

Hi,

 

Did you declare sentLength as volatile?  You might also need to protect it if 
it’s not loaded/stored in a single processor instruction (not likely to be the 
case with a 32-bit architecture).

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Karl Karpfen
Sent: Monday, September 15, 2014 3:00 PM
To: lwip-users@nongnu.org
Subject: [lwip-users] How to check send state?

 

Hi,

within my lwIP application (TCP with permanent connection) I'm sending some 
data out of main-loop (no interrupt context) and start submission by calling

tcp_output(currentPcb);

Sending of data is done via tcp_write(). Within the send function itself amount 
of data already sent is stored in a variable sentLength. Now to find out if it 
is possible to send next bunch of data I check this variable. When its size is 
equal to the length of the previous data buffer, sending was completed and I 
start submission of next buffer.

 

My problem here: sentLength is manipulated out of interrupt context while 
checking it for completion is done out of main loop. It seems this sometimes 
causes troubles, at receiver side I can see incomplete frames.

So my question: what is the correct way to find out if currentPcb has finished 
sending (or better has pushed all data to tcp_write()) and is ready to accept 
next bunch of data?

Thanks!

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Ethernet link state: needed ?

[Bill Auerbach]

> My question to the lwIP users: does anyone have the need to know the link
state ? Can you share why ?

I do, for 2 reasons.  

One: We have a panel LED for link/no link/connected to PC state.  Often the
user can't see the jack or switch.  Gets the 2 basic connectivity questions
answered quickly.

Two: On loss of link we reset/abort the connection and delay to force the PC
to see no activity.  Our system is real time and we don't want link glitches
to cause pauses that don't close the connection but effect the program's
operation causing "bug reports".  We'd rather have a fatal disconnect error.

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Sergio R. Caprile
Sent: Thursday, June 12, 2014 11:51 AM
To: lwip-users@nongnu.org
Subject: [lwip-users] Ethernet link state: needed ?

Hi folks,
I wrote a driver for the DM9000 Ethernet chip, and nowadays it is missing
the link state part. I feel reluctant to add it because I don't really see a
need for the stack/application to know the link state, since all the devices
I can imagine I'll be developing will be permanently attached to the
network, and not mobile devices like a laptop.

My question to the lwIP users: does anyone have the need to know the link
state ? Can you share why ?

Thank you, regards


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] TCP Checksum = 0xFFFF

[Bill Auerbach]

Niall,

 

This final line in tcp_out sets the check sum and includes the ~ in the call.

 

  seg->tcphdr->chksum = inet_chksum_pseudo(seg->p, &(pcb->local_ip),

 &(pcb->remote_ip),

 IP_PROTO_TCP, seg->p->tot_len);

 

>From an empirical standpoint, lwIP is used in far too many places for there to 
>be this significant of a bug.  I’d look for a compiler bug or some other 
>issue.  I seriously doubt it’s a bug in lwIP.  Some of my company’s users run 
>our systems 24/7 sending lots of data through lwIP and I’d hear about it 
>really fast if there was this kind of a TCP lockup.

 

Regards,

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Niall Donovan
Sent: Tuesday, May 13, 2014 11:09 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] TCP Checksum = 0x

 

To follow up on this issue. The offending piece of code that is generating the 
0x as the TCP checksum is this (lines 1137-1147 in tcp_out.c):

 

/* rebuild TCP header checksum (TCP header changes for retransmissions!) */

acc = inet_chksum_pseudo_partial(seg->p, &(pcb->local_ip),

 &(pcb->remote_ip),

 IP_PROTO_TCP, seg->p->tot_len, TCPH_HDRLEN(seg->tcphdr) * 4);

/* add payload checksum */

if (seg->chksum_swapped) {

  seg->chksum = SWAP_BYTES_IN_WORD(seg->chksum);

  seg->chksum_swapped = 0;

}

acc += (u16_t)~(seg->chksum);

seg->tcphdr->chksum = FOLD_U32T(acc);

 

If acc happens to have a value equal to seg->checksum, for example acc=0x8E93 & 
seg->checksum=0x8E93, (which can happen given the right set of values) one gets 
 acc += ~acc, which always results in 0x. The FOLD_U32T has nothing to do 
and the 0x is set as the seg->tcphdr->chksum. Which is wrong? Am in missing 
something?

 

Anyone able to enlighten me as why this isn't a coding error?

 

Shouldn't there be something to ensure 0x is converted to 0x?!

 

Thanks.

Niall.

 

On 13 May 2014 13:17, Niall Donovan  wrote:

Hi All,

   I'd appreciate some help on my problem. I occasionally have seen my TCP 
socket connection hang and when I captured the fault on Wireshark I could see, 
on the packet causing the hang, that the calculated TCP Checksum value was 
0x, which Wireshark indicated was incorrect. Wireshark says it should be 
0x. It also helpfully pointed to RFC1624 for further information. 

 

The socket hangs because the recipient of the packet (Win 7 PC) sees a checksum 
error and discards the packet and resends its previous packet. LwIP sends a 
duplicate Ack then resends (and keeps sending) the offending packet, with the 
same erroneous checksum. Hence my ping-pong type link gets stuck.

 

I don't modify the packet content after handing it to lwIP and my MAC device 
driver simply copies the packet from pbuf(s) to a tx buffer verbatim. I depend 
on lwIP to calculate the Checksum and CRC.

 

I've attached the offending packet in a pcap file. I hand calculated the 
checksum and the one's compliment sum is 0x hence the one's compliment of 
that is 0x. 

 

Why is lwIP inserting a checksum of 0x? It should have inserted 0x 
right? Is this a known issue, I didn't see any mention of it in the mail 
archives. If this is a known issue hopefully someone can point me in the right 
direction for a fix/workaround so I don't have to debug and/or re-code the 
checksum code of lwIP!! While I'm awaiting a reply I'll start that process...

 

FYI:

I am using lwIP 1.4.1 and have LWIP_CHKSUM_ALGORITHM = 3 in lwipopts.h

 

Thanks for your time

Regards

Niall.

 

 

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Strange packet sizes in receive-callback

[Bill Auerbach]

Hi,

Could be a packet chain (pbuf chain) of 8 packets.  The "some crap" part is
not good and probably means the driver needs some scrutiny for times when
it's being pushed.

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Satz Klauer
Sent: Friday, January 03, 2014 3:44 PM
To: Mailing list for lwIP users
Subject: [lwip-users] Strange packet sizes in receive-callback

Hi,

I'm new to lwIP, so hopefully my question is not too stupid.

I'm sending huge amounts of data to my BeagleBone Black where a lwIP
implementation is running. Due to that within my receive callback I get
repeatedly packets with a size of 1460 bytes (which should be some TCP
segment/framesize?).

This works mainly well...but sometimes a packet with a bigger size is
received (e.g. 11680 bytes). This is bigger than the maximum possible size
and the memory contains some crap.

Any idea what the reason could be for this behaviour?

Thanks!

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] How to properly send packets of size greater than snd_buf?

[Bill Auerbach]

Search for: httpserver_raw

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of bradleytse
Sent: Wednesday, December 18, 2013 5:22 PM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] How to properly send packets of size greater than
snd_buf?

I've searched around on Google but could not find this example that you
refer to. Do you mind pointing me in the right direction? Thanks!



--
View this message in context:
http://lwip.100.n7.nabble.com/How-to-properly-send-packets-of-size-greater-t
han-snd-buf-tp22109p22111.html
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] How to properly send packets of size greater than snd_buf?

[Bill Auerbach]

The tcp_sent callback should be used to continue to send data until all data
has been sent - for Raw API mode anyway.  See the http_raw example for a
typical approach to this.

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of bradleytse
Sent: Wednesday, December 18, 2013 2:07 PM
To: lwip-users@nongnu.org
Subject: [lwip-users] How to properly send packets of size greater than
snd_buf?

How am I supposed to send packets of size greater than the pcb's snd_buf?
Right now my snd_buf is 8192 bytes, but the packets I am sending can be
~150kb. I know that one of the suggested methods is to return control to
main, and then use the tcp_poll callback function to finish sending the data
once the snd_buf has cleared, but this method is way too slow and I cannot
afford to wait like this. I need to force the whole packet to send right
away (or at least as fast as the receive can receive). 

I have tried using tcp_nagle_disable() and then tcp_output() but this does
not work. The snd_buf still does not clear out.

Any suggestions? I'm stumped at the moment.



--
View this message in context:
http://lwip.100.n7.nabble.com/How-to-properly-send-packets-of-size-greater-t
han-snd-buf-tp22109.html
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Advanced lwip raw API questions

[Bill Auerbach]

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of ella
Sent: Monday, November 18, 2013 2:14 PM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] Advanced lwip raw API questions

Hi,
Thanks for your reply.

The most disturbing thing for me is your NO to my question about tcp_*
thread safe. In other words it means that all processing should be done in
tcp callback ONLY as this is the only code running in tcp thread context !?

Right now I did something like this:

/* Receive Callback (tcp thread)*/
...
xQueueSend( queue_srv, &my_data, 0 );

/* Server Thread (My server thread) */
xQueueReceive( queue_srv, &my_data ... );
/* Processing */
...
tcp_write( ... );
tcp_output(  );

If tcp_write and tcp_output are not thread safe I do not know how to
implement server that requires long processing.



Hi,

You're welcome. 

There's a good bit documented about lwIP and threading (or not using
multiple threads).

This is a good start:
http://lwip.wikia.com/wiki/LwIP_with_or_without_an_operating_system

I use a cooperative multi-tasking kernel so don't worry about the threading
issue because I can't interrupt the TCP/IP thread, but I am able to send TCP
messages from all running threads.  In fact, one thread is a telnet thread
and when telnet is connected, all program debug printfs send to the telnet
connection (or are ignored otherwise).  I was not up for making things
thread safe or worrying about internal TCP thread messaging issues.  My
systems are realtime and I don't have the overhead or preemption issues to
worry about.

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Advanced lwip raw API questions

[Bill Auerbach]

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of ella
Sent: Friday, November 15, 2013 12:25 AM
To: lwip-users@nongnu.org
Subject: [lwip-users] Advanced lwip raw API questions

Hi,
Before I dive in to source code and spend hours I decided to ask people here
a few questions:

1. After issuing tcp_output and getting ERR_OK in return am I guaranteed to
get ANY tcp_sent callback?
In what cases there will be no callback? What if disconnect happened or
there is no ACK from remote peer?
In my server implementation it's thread blocks waiting for sent callback and
I'm not sure if I'm not risking to get stuck where forever.

2. API says that after tcp_close I still can receive data on the
disconnected pcb. What does it mean? Should I expect to get tcp_recv
callback even after tcp_close? When can I free resources allocated for such
closed connection and be sure nothing will happen anymore with it?

3. tcp_recv callback gets err argument. What kind of error should I expect
where and how to deal with it?

4. Are tcp_* functions thread safe? I mean can I have server running in
separate thread and make calls to tcp_* functions from that thread and not
from callback running in native tcp thread?

Thanks.

Just a few fillings. I tried to implement own TCP server based on raw API
and actually got it working but it looks pretty complex as I'm trying to
take care of all possible cases. I found out that it is not trivial to sync
between callback and server thread. So I've started to look at netconn API
assuming that same job was done and was TESTED already. Especially
considering the fact that I will need a number of different servers in my
application to implement external interfaces. 

-

Hi,

I will answer what I can based mostly on experience using lwIP, which goes
back now almost 10 years - all RAW API.

1.  tcp sent is called when there is buffer space, meaning when sent data
has been acked.  Unacked packets  and other issues (disconnects) would cause
tcp_sent to not be called.  I've never worried about it.  If tcp sent is
called, I check to see if I have more data to send.  If so, I do.  If not, I
set tcp_sent to NULL.  I reset it on the next send.  Pretty much just like
the raw http server demo.

2. Not totally sure except that I think you'll get more tcp received
callbacks if there is incoming data.  You know you won't receive more if tcp
received is called with a NULL pbuf or by a tcp error callback.

3.  I only use it if p is NULL and err is ERR_OK to indicate a closed
socket.  Again deriving this from an lwIP example.

4.  No.

One thing I've learned the hard way is that the tcp receive callback cannot
spend a lot of time or it disrupts tcp timing.  It will correct itself, but
when I saw errors in wireshark (e.g. retransmits) it pointed to something in
my system that was slower than normal that I did in the callback.

In order to not have nasty state-checking for all the possible callback
things I'd have to handle, I used tcp receive to create a pbuf chain which
would hold all of the incoming data.  When tcp received was called I called
back my application handler with how much data was in the chain.  If there
was enough to process the callback, I'd pull data off the of head to
process. Too often it happened that one callback would have my message
header and a second had the payload and it was hard to process that in 2
callbacks.

Bill


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] maximum lwip sockets limitation

[Bill Auerbach]

I don't use sockets, but I suspect that increasing MEMP_NUM_UD_PCB isn't
needed in which case you'll save some memory.  Feel free to yell at me if
I'm wrong. J

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Enrique Wellborn
Sent: Wednesday, October 30, 2013 12:34 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] maximum lwip sockets limitation

 

OK, changing this macro alone didn't do it, but changing the
MEMP_NUM_TCP_PCB and MEMP_NUM_UDP_PCB macros along solved it.

Is there any other macro that needs to be changed along with the above for
lwip to function properly and stably?

Thank you very much!

 

On Wed, Oct 30, 2013 at 5:25 PM, Yafei Yan  wrote:

You can modify the marco as follow:

/* MEMP_NUM_NETCONN: the number of struct netconns. */

#define MEMP_NUM_NETCONN8

It indicates that the number of sockets.

 

 

2013/10/30 Enrique Wellborn 

Hi,

I'm using the lwip_socket() api to create lwip sockets on linux and it works
well, but only for 4 sockets.

When I try to create a fifth socket, the functions fails (returns -1).

When I call lwip_close() on one of the 4 existing sockets, it works, and
then i can recreate the same socket (I get the same socket id) using
lwip_socket().

Is there a way to remove this limitation?

Thank you very much!

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

 


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Tcp server close stuck at TIME_WAIT, cannot open server on the same port again

[Bill Auerbach]

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Ishmeet Singh
Sent: Thursday, October 17, 2013 7:05 AM
To: lwip-users@nongnu.org
Subject: [lwip-users] Tcp server close stuck at TIME_WAIT, cannot open
server on the same port again

 

>Hi,

> 

>I am using LwIP 1.4.1, my tcp server close is stuck at TIME_WAIT condition,
hence I am unable to open server on the same port again. I have tried
SO_REUSE (#define SO_REUSEADDR 1), 

>but this also doesn't work, any ideas?

>In time wait I have check that after around 30 secs, it goes out of timeout
to CLOSED state, I don't want to wait that long.

 

This has come up a lot - you can search the archives.  The following
probably helps a lot:

http://lists.nongnu.org/archive/html/lwip-users/2008-02/msg00071.html

Bill

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] No delay between DHCP discoveries

[Bill Auerbach]

I would update to the latest (1.4.1).  Your version is 6 or 7 years out of
date.  It shouldn't make a difference, but if it does, why debug something
that may already be debugged?  Besides, there are *many* bug fixes and
features added over those years.

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of HA
Sent: Monday, October 07, 2013 4:35 AM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] No delay between DHCP discoveries

I have to connect some level converters to the Uart to print out debug
messages. I did a grep of dhcp_discovery and it was only used inside dhcp.c.
This file I have compared with the original and no difference.

My thre timers run correctly, I can see it on the scope. Have no idea how
the webserver could trigger dhcp_discovery. Will go through the code. Any
other ideas?



--
View this message in context:
http://lwip.100.n7.nabble.com/No-delay-between-DHCP-discoveries-tp21927p2193
8.html
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] No delay between DHCP discoveries

[Bill Auerbach]

What is the application doing while it's waiting for the IP address to be
set by the DHCP server?

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of HA
Sent: Friday, October 04, 2013 6:01 AM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] No delay between DHCP discoveries

I have the same values. Probably default.

Any other ideas?



--
View this message in context:
http://lwip.100.n7.nabble.com/No-delay-between-DHCP-discoveries-tp21927p2192
9.html
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] TCP ACK Problem?

[Bill Auerbach]

Doesn’t it make sense to update to 1.4.1 before asking about a bug or
problem?

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Rodrigo Garbi
Sent: Tuesday, August 27, 2013 9:29 AM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] TCP ACK Problem?

 

Anyone?

 

 

2013/8/23 Rodrigo Garbi 

Hi!

I'm working with FreeRTOS v7.0.1 and LwIP 1.4.0 and I'm facing the following
problem:

 

Device A and B transmit data every 40 ms to my board (where I'm running
LwIP) and once in a while I can notice some data from device A is being
missed.

 

So I did some research with CommView and found that:

 

1) Device A sends data (9 bytes length) to my board and get correct ACK from
it:


Sequence: 0x13D5388C (332740748)

 


Acknowledgement: 0x1A57 (6743)

 

Response from my board:


Sequence: 0x1A57 (6743)



Acknowledgement: 0x13D53895 (332740757)

 

2) Device A send 9-bytes data to my board, but this won´t ACK:


Sequence: 0x13D5389E (332740766)


Acknowledgement: 0x1A57 (6743)

 


Sequence: 0x1A57 (6743)



Acknowledgement: 0x13D5389E (332740766)

 

3)Device A does not care about it (maybe because data is already in ethernet
transceiver buffer) and sends a new data (9-bytes); my board will not ACK
it:


Sequence: 0x13D538A7 (332740775)


Acknowledgement: 0x1A57 (6743)

 


Sequence: 0x1A57 (6743)



Acknowledgement: 0x13D5389E (332740766)

4)Same as 3


Sequence: 0x13D538B0 (332740784)


Acknowledgement: 0x1A57 (6743)

 


Sequence: 0x1A57 (6743)



Acknowledgement: 0x13D5389E (332740766)

 

5) Same as 3

 


Sequence: 0x13D538B9 (332740793)


Acknowledgement: 0x1A57 (6743)

 


Sequence: 0x1A57 (6743)



Acknowledgement: 0x13D5389E (332740766)

 

6) Finally, device A is aware of the problem and retransmits data, but
instead of transmitting 36 bytes (9 x 4), only transmits 18 bytes


Sequence: 0x13D5389E (332740766)


Acknowledgement: 0x1A57 (6743)

 


Data length: 0x12 (18)



And my board running Lwip 1.4.0 will acknowledge 36 bytes instead of 18:


Sequence: 0x1A57 (6743)



Acknowledgement: 0x13D538C2 (332740802)



So device A won´t transmit last two 9-bytes packets, and they will be lost!

 

Anyone can help me with this? Is it a bug in LwIP or what is happening?

Thank you!

 

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Implementation of TCP_NODELAY

[Bill Auerbach]

Hi,

 

Because lwip_getsockopt_internal takes care of this.  lwip_getsockopt is
simply an error checker before doing the real work in
lwip_getsockopt_internal.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Ilya Lesokhin
Sent: Wednesday, August 14, 2013 9:53 AM
To: lwip-users@nongnu.org
Subject: [lwip-users] Implementation of TCP_NODELAY

 

Hi,

 

Looking at the code of lwip_getsockopt(...)

 

...

switch (optname) {

case TCP_NODELAY:

case TCP_KEEPALIVE:

#if LWIP_TCP_KEEPALIVE

case TCP_KEEPIDLE:

case TCP_KEEPINTVL:

case TCP_KEEPCNT:

#endif /* LWIP_TCP_KEEPALIVE */

  break;

...

 

I case see that the option TCP_NODELAY does nothing.

If I understand correctly this functionality is implemented and controlled
by the flag- TF_NODELAY.

So I was wondering, is there a reason the code int there isn't:

 

...

 case TCP_NODELAY:

 if ((*(int*)optval))

sock->conn->pcb.tcp-> flags |= TF_NODELAY;

 else

sock->conn->pcb.tcp-> flags &= ~TF_NODELAY;

 break;

...

 

or something along those lines?

 

Thanks,

ilya

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp_output() when processing "tcp_input_pcb"

[Bill Auerbach]

Hi,

I agree with you.  We are running real-time with RAW API and NO OS and see
very good TCP response - but we are on a fast system.  On our lower
performing systems we get "exceptional throughput" only by using UDP.

Also, the real-time part of lwIP is maximized by minimizing what you do in
the receive callback.  If you do too much in the receive callback, you throw
off TCP timing which slows the connection even to the point of causing
errors.  If I need more than a few milliseconds, I kick off a second thread
so I can return to lwIP as fast as possible.  We run a cooperative OS which
eliminates all of the threading problems of lwIP.

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Noam weissman
Sent: Tuesday, August 13, 2013 5:51 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] tcp_output() when processing "tcp_input_pcb"

Hi,

It depends on what you do and what are the available resources (RAM/ROM).

LwIP is small but it has its limitations.

I am working with a system that has a WEB server, UDP and TCP connections
and bridging to UART all is running at real time. 

If you do not need exceptional throughput its OK.

BR,
Noam.

-Original Message-
From: lwip-users-bounces+noam=silrd@nongnu.org
[mailto:lwip-users-bounces+noam=silrd@nongnu.org] On Behalf Of
Numb_Faith
Sent: ג 13 אוגוסט 2013 12:38
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] tcp_output() when processing "tcp_input_pcb"

Dear Noam,

Thanks, I'm clear about it.
So if I want to do some application which need real time, I still need the
RTOS. Though TCP/IP is not a stack which has good performance in the real
time case.

Best Regards,
Ray Li



--
View this message in context:
http://lwip.100.n7.nabble.com/tcp-output-when-processing-tcp-input-pcb-tp217
83p21793.html
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

 
 


This footnote confirms that this email message has been scanned by PineApp
Mail-SeCure for the presence of malicious code, vandals & computer viruses.






 
 


This footnote confirms that this email message has been scanned by PineApp
Mail-SeCure for the presence of malicious code, vandals & computer viruses.






___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp_output() when processing "tcp_input_pcb"

[Bill Auerbach]

Ray,

Perhaps you can show us your connection setup code (i.e. the tcp alloc,
listen, bind, etc.).

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Numb_Faith
Sent: Friday, August 09, 2013 3:46 AM
To: lwip-users@nongnu.org
Subject: [lwip-users] tcp_output() when processing "tcp_input_pcb"

When I use lwip1.4.1 and RAW API, I meet a problem. I use my borad(STM32) as
a server. When server receive a packet from client, I hope it can send a
packet immediately. So I call the function below:

/tcp_write(tpcb, DataTest, sizeof(DataTest), 0x01); tcp_output(tpcb);/

But when server receive a packet, the stack will call tcp_input(), and
tcp_input_pcb = pcb (the connection), so tcp_output(tpcb) would return.

When I comment the code below(in function tcp_output), it can got what I
want. But I'm still confused about why "If we are invoked by the TCP input
processing code, we do not output anything".

/* First, check if we are invoked by the TCP input processing code. If so,
we do not output anything. 
Instead, we rely on the input processing code to call us when input
processing is done with. */ //  if (tcp_input_pcb == pcb) { //  return
ERR_OK; //  } 

Best Regards,
Ray Li



--
View this message in context:
http://lwip.100.n7.nabble.com/tcp-output-when-processing-tcp-input-pcb-tp217
83.html
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] ETHARP_TRUST_IP_MAC

[Bill Auerbach]

Vincent,

 

My experience is better than yours. I’ve used ETHARP_TRUST_IP_MAC in every 
lwIP-based product I’ve done (9 so far) and never have had a problem with it.  
We have users unplug and replug cables and turn off and on power “hot” all the 
time and the PC apps always reconnect normally.  Our devices are often power 
24/7 as well (not that they should  be – some users are lazy).

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Vincent Cui
Sent: Thursday, August 08, 2013 8:00 PM
To: Mailing list for lwIP users
Subject: [lwip-users] ETHARP_TRUST_IP_MAC

 

Hi :

 

Is there anyone use ETHARP_TRUST_IP_MAC ?

One interesting happen about it is from my customer. He use the A version with 
ETHARP_TRUST_IP_MAC enable in LWIP, it works well after power on. 

But PING request always time out after running some days, I also find the PING 
other device in the network is good. so, I hot reset the Device, the PING issue 
still exist.

Then, I upgrade the A version to B version with ETHARP_TRUST_IP_MAC disable in 
LWIP and hot reset, PING issue goes out. Everything goes well now . 

Next, I upgrade B version to A version again and hot reset, the PING issue 
happen again .  but if cold reset the device with A version, PING issue goes 
out. But It will come back

After running many days.

 

Anyone has known this ?

 

 

Vincent 

 

Vincent Cui

Firmware Engineer Leader



Room1106, Building A, New Caohejing Business Centre, No.391, Guiping Road, 
Xuhui District, Shanghai, P.R.China

T: +86 21 34612525, M: +86 13482482211

www.enlogic.com

  _  

P please consider the environment before printing this email 

  _  

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to which they are addressed.  If 
you have received this e-mail in error, please notify the sender immediately 
and then delete it.  If you are not the intended recipient, you must not use, 
disclose or distribute this e-mail without the author's prior permission. We 
have taken precautions to minimize the risk of transmitting software viruses, 
but we advise you to carry out your own virus checks on any attachment to this 
message.  We cannot accept liability for any loss or damage caused by software 
viruses.  Any views and/or opinions expressed in this e-mail are of the author 
only and do not necessarily represent the views of Enlogic.

  _  

<>___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP

[Bill Auerbach]

Pavel,

Regarding licensing, it's best to read the actual license and have you or
your company decide if it fits your intended usage.  This is the link on the
lwIP Savannah site:

http://www.xfree86.org/3.3.6/COPYRIGHT2.html#4

Bill

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of M65FireFox
Sent: Wednesday, July 17, 2013 3:18 PM
To: lwip-users@nongnu.org
Subject: [lwip-users] lwIP

 

Hello,
I have a question for you. I take your library lwIP in future products. It
is possible your library to add these devices and sell without publishing
the code? That includes your library is written in the literature about in
the program.

Thank you in advance for your reply
Pavel H. 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] webserver problem

[Bill Auerbach]

Pierre,

No, it's not normal.  In lwIP normal behavior isn't tested with ASSERTs.  The 
ASSERT means pbuf_free is not expecting a NULL.  Typically this is a port/Enet 
driver error.  Or the pbuf was passed through the stack and still deleted by 
your code.

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
pcu
Sent: Thursday, July 11, 2013 6:16 AM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] webserver problem

I put lwip in debug, level at Warning.
 
In the event that it works or it does not work, I print a lot of messages 
"pbuf_free (p == NULL) was called."

Is this normal?

Pierre



--
View this message in context: 
http://lwip.100.n7.nabble.com/webserver-problem-tp21697p21731.html
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] a question!?

[Bill Auerbach]

Maybe because the protocol and type checks are 2 byte checks while the ip
address and hwaddr checks total 10 bytes to check?

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of hunybal
Sent: Monday, June 24, 2013 8:54 AM
To: lwip-users@nongnu.org
Subject: [lwip-users] a question!?

hello evry one i cant understand why in lwip first check the type ,protocol
and  and after check the ipaddr and hwaddr .why at the beginning dont
check this parameter to Prevention useless Process? 



--
View this message in context:
http://lwip.100.n7.nabble.com/a-question-tp21588.html
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] ARP Request breaking Telnet traffic

[Bill Auerbach]

Daniel,

It looks like the MAC address of your lwIP device changed - from
02:81:00:01:D4:C1 to 02:81:00:01:D5:00 from packet 13 to 14.

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Daniel
Sent: Monday, June 24, 2013 7:42 AM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] ARP Request breaking Telnet traffic

Hi Ueli

Thank you for you reply. I actually forgot the attachment! 

Here it comes.
wireshark_ARP_breakdown_excerpt2.pcapng
  

Regards,
Daniel



--
View this message in context:
http://lwip.100.n7.nabble.com/ARP-Request-breaking-Telnet-traffic-tp21584p21
586.html
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] NETCONN_NOCOPY not sending

[Bill Auerbach]

Nick,

What was the problem exactly.  It very well could help others who run into
the same issue.

Thanks,
Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Nikolas Karakotas
Sent: Thursday, May 16, 2013 11:34 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] NETCONN_NOCOPY not sending

Hi,

I finally found the problem. It was a bug in the ethernet driver as you
mentioned. I fixed it up and in now works.
Thank you for pointing it out.

Regards,
Nick

-Original Message-
From: Bill Auerbach
Sent: Thursday, May 16, 2013 10:42 PM
To: 'Mailing list for lwIP users'
Subject: Re: [lwip-users] NETCONN_NOCOPY not sending

Hi,

It could also be that the memory is getting reused (overwritten) in the time
from the tcp_write to the time it's actually sent by the Ethernet driver.

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Martin Velek
Sent: Thursday, May 16, 2013 5:08 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] NETCONN_NOCOPY not sending

Hi,

my crystal ball is telling me that you are using NOCOPY to pass data e.g.
from ROM, STACK, SRAM but the EMAC driver does not provide send buffer (zero
copy) and thus cannot access the ROM, STACK, SRAM area.
This is e.g. case of LPC1788. With NETCONN_COPY, the lwip creates buffers in
the right memory regions.

Could you provide a detailed description of your configuration, like lwip
version, type of  drivers, system, etc?

Best
Martin

On Sun, May 5, 2013 at 10:41 AM, Nikolas Karakotas 
wrote:
> Hi,
>
> Im trying to send data with NETCONN_NOCOPY but I cant get it to work 
> only with NETCONN_COPY.
> What could be causing this problem?
>
> Regards,
> Nick
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users 


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] NETCONN_NOCOPY not sending

[Bill Auerbach]

Hi,

It could also be that the memory is getting reused (overwritten) in the time
from the tcp_write to the time it's actually sent by the Ethernet driver.

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Martin Velek
Sent: Thursday, May 16, 2013 5:08 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] NETCONN_NOCOPY not sending

Hi,

my crystal ball is telling me that you are using NOCOPY to pass data e.g.
from ROM, STACK, SRAM but the EMAC driver does not provide send buffer (zero
copy) and thus cannot access the ROM, STACK, SRAM area.
This is e.g. case of LPC1788. With NETCONN_COPY, the lwip creates buffers in
the right memory regions.

Could you provide a detailed description of your configuration, like lwip
version, type of  drivers, system, etc?

Best
Martin

On Sun, May 5, 2013 at 10:41 AM, Nikolas Karakotas 
wrote:
> Hi,
>
> Im trying to send data with NETCONN_NOCOPY but I cant get it to work 
> only with NETCONN_COPY.
> What could be causing this problem?
>
> Regards,
> Nick
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] NETCONN_NOCOPY not sending

[Bill Auerbach]

Hello,

 

So, NETCONN_COPY works but NETCONN_NOCOPY doesn’t?  Is it trying to send data - 
is your netif->linkoutput function being called?  Did you check return codes 
from lwIP functions? I suggest turning on LWIP_DEBUGs and see if any errors are 
reported.  Also, print the lwip stats after an attempt to send.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Nikolas Karakotas
Sent: Sunday, May 12, 2013 1:45 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] NETCONN_NOCOPY not sending

 

Hello,

 

I would like some help with this issue I'm facing. I want to use static pages 
to serve over the httpd server but when I use NETCONN_NOCPY it doesn’t seem to 
work.

Nothing is sent. I cant seem to track this issue Can someone direct me where to 
look?

 

Nick

 

From: Nikolas Karakotas   

Sent: Sunday, May 05, 2013 6:41 PM

To: Mailing list for lwIP users   

Subject: [lwip-users] NETCONN_NOCOPY not sending

 

Hi,

 

Im trying to send data with NETCONN_NOCOPY but I cant get it to work only with 
NETCONN_COPY.

What could be causing this problem?

 

Regards,

Nick

  _  

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] STR912 lwIP + Freertos demo

[Bill Auerbach]

Noam,

Didn’t you mean to say "... there should NOT be a timeout as ..."?

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Noam weissman
Sent: Monday, April 22, 2013 9:05 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] STR912 lwIP + Freertos demo

Hi,

Under UDP there should be a time out as there is no connection.

When you work with TCP it is normal to have some kind of timeout and that is
to avoid unused connections.

Noam.

-Original Message-
From: lwip-users-bounces+noam=silrd@nongnu.org
[mailto:lwip-users-bounces+noam=silrd@nongnu.org] On Behalf Of ajinkya
Sent: ב 22 אפריל 2013 15:26
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] STR912 lwIP + Freertos demo

Hi Noam,
I just rectified the problem, :-)
Actually I wrote the IR generation first, got it working.
Then I started with LWIP, also got it working, with your help of course.

But while integrating both the codes, I did not comment 

>> VIC_DeInit();  //(actually did that purposefully while
writing IR generation)

function call, which was a part of IR generation code, and was getting
called after UDP server comes online.

So everything related to interrupts was deinitialized (as ethernet requires
them, it was not working)

Finally it is working.
I am able to control AC over Ethernet now...

Still I have some reliability issues, as it goes offline after certain time/
packets of transmission and reception.
Is there something/some function to keep it refreshing/resetting?


---
Thanks a lot,
Ajinkya


(Will be available on this mailing list if somebody finds some problem,
and I am able to solve it :-) )



--
View this message in context:
http://lwip.100.n7.nabble.com/STR912-lwIP-Freertos-demo-tp21277p21332.html
Sent from the lwip-users mailing list archive at Nabble.com.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

 
 


This footnote confirms that this email message has been scanned by PineApp
Mail-SeCure for the presence of malicious code, vandals & computer viruses.






 
 


This footnote confirms that this email message has been scanned by PineApp
Mail-SeCure for the presence of malicious code, vandals & computer viruses.






___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LwIP stops sending data (but keeps retrying forever) - caused by buffer chaining

[Bill Auerbach]

Jeremy,

 

There are so many changes, bug fixes and enhancements in 1.4.1 that I strongly 
recommend updating.  And if this is a bug and it’s been fixed, that means 
updating to 1.4.1 to get it anyway.  Or diffing the changes and back-porting it.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Jeremy Spiller
Sent: Wednesday, March 27, 2013 5:29 PM
To: lwip-users@nongnu.org
Subject: [lwip-users] LwIP stops sending data (but keeps retrying forever) - 
caused by buffer chaining

 

I’m using version 1.3.2.  In the case where I do this:

 

tcp_write(pcb, (void*)"\r\n", 2, TCP_WRITE_FLAG_COPY);
tcp_write(pcb, (void*)">", 1, TCP_WRITE_FLAG_COPY);

Communications stop, but LwIP keeps retrying forever.  I can fix the problem by 
making the following modification in tcp_enqueue:

 

  /* If there is room in the last pbuf on the unsent queue,
  chain the first pbuf on the queue together with that. */
  if (TCP_ALLOW_BUFFER_CHAINING_JMS &&

...

 

With TCP_ALLOW_BUFFER_CHAINING_JMS set to false, the problem goes way.  I 
suspect the packets are going out, but have an incorrect checksum or are 
permanently corrupted somewhere along the way.  BTW, I’m using LwIP functions 
in only one thread (the main loop) and only outside of interrupts, so I don’t 
think it’s a threading issue.

 

Is this a bug, or is something else going on?

 

-Jeremy

 

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP instead of BSD stack regarding IPv6

[Bill Auerbach]

Interesting...  But for those wanting BSD licensing and as the subject says
"instead of BSD":

>From http://www.oryx-embedded.com/cyclone_tcp.html#sourceCode

"The open source GPLv2 version CycloneTCP Open is available for free.
However the GPL license requires that developers publish the complete source
of their applications and make it available to anyone who wants to use it
for free.

Bill

-Original Message-
From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Guillaume Fortaine
Sent: Wednesday, March 27, 2013 10:23 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] lwIP instead of BSD stack regarding IPv6

Hello,

There is also the newly released CycloneTCP as lightweight Open Source
TCP/IP Stack :

http://www.oryx-embedded.com/cyclone_tcp.html#sourceCode

Best Regards,

Guillaume FORTAINE

On Wed, Mar 27, 2013 at 1:00 PM,   wrote:
> Hello,
>
>
> i have a project where IPv6 is required. I have to examine the lwIP’s 
> TCP/IP stack regarding its IPv6 capability and if it is an alternative 
> to the BSD stack. Because of having limited memory space on the 
> embedded target controller, lwIP with the lower footprint is 
> preferred. Since I am just a rookie I considered to join the mailing 
> list. I have some questions especially using the IPv6 stack. Are there 
> any experiences? Or restrictions for using it?  The operating system 
> in my project is eCos. The current version of the lwIP stack is not
implemented, but v1.3.2.
>
> One concrete question is concerning the address eCosCentric in the
> limitations: “The DNS client support only returns IPv4 addresses”. 
> What does this mean?
>
> I hope anybody can help me and has already some experiences about IPv6.
> Thank you very much!
>
>
> Best regards, Christian
>
>
>
> ---
> Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen!
> Rundum glücklich mit freenetMail
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Interface with PPPoE and DHCP?

[Bill Auerbach]

All,

 

We as many do have the same problem and requirement.  My first pass at this
was to auto-assign an AutoIP address derived from the MAC address of the
product.  On power up every device had an IP address, and better, a known
one because the device has a MAC address label. If DHCP picked up an
address, it would change over.  We have a ‘Discovery’ program and protocol
and can  list devices connected to the PC.  I looked at mDNS / AutoConf but
it’s a lot of development.  Our protocol was expanded to get and set the IP
address and MAC address so that factory boards all have the same MAC for
initial testing and bring-up.

 

Ultimately we abandoned DHCP and ship products with a known and static IP
address.  We don’t want to discover on-the-fly and have access problems from
the PC program and worse, we don’t want to use a device attached somewhere
else in the customer’s building.  This approach also forces our users to use
a sub-net and get off their network.  Our utility has the option to move all
devices from one subnet to another in case we collide with their internal
network.

 

In any case, starting up with a static AutoIP address worked while we used
it.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Richner Simon
Sent: Wednesday, March 20, 2013 7:16 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Interface with PPPoE and DHCP?

 

Dear Ruben,

 

I have thought about using broadcasts as well. The problem is, that when I
connect my laptop directly to the device, neighter one has a valid IP
(0.0.0.0). I'm not sure this would bother UDP broadcasts, but for TCP this
isn't possible for sure. So the only way I see is to use UDP broadcasts to
make sure it's a point to point connection and then set static IPs for both
sides

Of course the question is, if you really need TCP on a point to point
connection at all.

 

Kind Regards

Simon

 

 

  _  

Von: lwip-users-bounces+simon.richner=psi...@nongnu.org
[mailto:lwip-users-bounces+simon.richner=psi...@nongnu.org] Im Auftrag von
Ruben van der Kraan
Gesendet: Mittwoch, 20. März 2013 10:56
An: Mailing list for lwIP users
Betreff: Re: [lwip-users] Interface with PPPoE and DHCP?

Hi Simon,

I have a similar problem but at the moment i am not working on this issue. 

The idea I have is to send a UDP broadcast message to all the users on the
local network. 
The devices that recognize the UDP frame answer tot it and now the IP
address is know to the application. 

An other way is to let the device send a udp broadcast message to every one
on the network.
the C# application receives this message and then knows the IP of all the
compatible devices in the network. 
You can send the broadcast every minute or so. 

If you or anyone else have i better option I am interested. 

Kind Regards 

Ruben


On 20-3-2013 9:07, Richner Simon wrote:

Hi 

I'm looking for some advice. I have a series of custom devices using LwIP,
talking to a custom C# application. 
Some devices are connected to a network, using DHCP to get an IP address.
Other devices are setup for standalone use and are directly connected to a
local laptop for maintenence. In both cases I want to use the same ethernet
connetion with the same software.

I've been looking at AUTOIP, but this takes almost a full minute to setup IP
adresses, which is unacceptable. Another idea was to use one common static
IP if no DHCP server was found. The problem with this is, that in case it's
just a temporary DHCP server absence, I end up with dozens of devices having
the same IP. My last idea was to use DHCP and PPPoE in parallel. So if there
was no DHCP server, the laptop would use PPPoE. I haven't tested this, but
if my thought is correct, this would solve both problems mentioned (to the
cost of having to implement two protocols).

 

If anybody has similar requirements, please let me know how you solved this.


Am I on the right track, or is there a much simpler solution to my problem? 

 

Best Regards 
Simon 






___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] lwIP 1.4.1 - Detecting a closed TCP connection

[Bill Auerbach]

Hello,

Background: My embedded device can only handle one connection from a PC and
refuses a connection when one is open.  To date, I have done this by setting
a bool true it the accept callback and setting it to false when the tcp_recv
callback indicates the connection is closed.  If the accept callback sees
the true bool, I send a message back to the PC that the device is already
connected and use tcp_close to close the second connection.

Problem: Every once in a very long while, I'm out of sync and the PC
connection is refused even though the previous connection has closed.  I
doubt it's an Ethernet error, and I don't want to assume that there could be
an intermittent missed callback to tcp_recv telling me that the connection
has closed.  So I don't know how this state is entered.  In any case, it's a
really bad state to wind up in! I have to cycle power to the device to
reconnect to it.

Question: I'm sure there is a better way to go about doing this. Instead of
querying a bool variable that I have to maintain is there an lwIP function
that will always work to determine if there is an open connection to a port?
I don't mind getting the second connection (briefly) and it has been nice to
warn the PC user that someone else is connected to the device.  But I need
to stay in perfect sync.

Thank you,
Bill Auerbach


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Correctly manage cable disconnection and reconnection

[Bill Auerbach]

>Whether you poll the phy registers from a slow thread or use the phy
>interrupt (if there is one) doesnt matter to lwIP. What's important is
>that you call lwip_set_link_up() or lwip_set_link_down() after detecting
>link changes. Note that it's very important to call these functions in
>the lwIP thread, not from your low prio thread or from an ISR!

Correction: It's netif_set_link_up and netif_set_link_down

Bill


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Sending out TCP-Data as integer type

[Bill Auerbach]

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Mark Lakata
Sent: Wednesday, December 05, 2012 5:16 PM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] Sending out TCP-Data as integer type

 

Oops, *I* need to read up on paying attention... sorry, I retract my
comment. There are 2 bugs in the original posting, first the data buffer
size (should be sizeof(int) and not 1) and second (which I missed) that he
is not passing a pointer.  It has nothing to do with Endianness . 



 

Maybe not a typo - depends what the OP wants to do.  If he wants to send a 0
to 255 as a byte (which is implied with a length of 1) then sizeof(int)
isn't right - that sends (probably 4) bytes.  You do need the address of
data and being a pointer to an int which is sent as bytes it might be
affected by endianess if the other end differs in endianess.

 

Bill

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Sending out TCP-Data as integer type

[Bill Auerbach]

 

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Firedog I.
Sent: Wednesday, December 05, 2012 9:38 AM
To: lwip-users@nongnu.org
Subject: [lwip-users] Sending out TCP-Data as integer type

 

Hi everyone,

 

I got a little problem over here. I can send simple TCP-Data like string and
char, but I can't send data as integer type. I'm using lwIP v1.36 with RAW
API.

 

Example:

 

/*Connection to Client established.*/

int data = 0xFF; //or int data = 255;

tcp_write(pcb, data, 1, 1);

 

tcp_write 2nd param is a void * arg - a pointer.  So you want:

 

tcp_write(pcb,&data,1,1);

 

but then using an int could be a problem depending on the platform.  Always
best to use bytes (chars).

 

char data = 0xFF;

tcp_write(pcb,&data,1,1);

 

should do it.  If you were to change data to an array of chars, then:

 

char data[] = { 0xFF };

tcp_write(pcb,&data,sizeof data,1);

 

is better still. And you can add bytes to the initializer for data[] without
changing any other code.

 

Bill

 

 

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] network configuration change

[Bill Auerbach]

>How to reinitialize lwIP core when network configuration from DHCP to
STATIC without cold reset ?
>Do I need delete TCPIP and ETHERNET task first, then call lwIP init
functions ?
>
>Vincent  

Use dhcp_stop and netif_set_addr (or other netif_ setting functions).

Bill


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] how to detect cable down in this case

[Bill Auerbach]

I think he means if you are connected to a switch and the connection to
another device on the switch is removed.  In this case there is no loss of
link since the switch maintains that but there is a loss of connection.

>-Original Message-
>From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
>[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On
>Behalf Of Krzysztof Wesolowski
>Sent: Tuesday, August 21, 2012 3:59 PM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] how to detect cable down in this case
>
>Lwip is "just" network a stack, it does not interact with physical
>medium directly.
>
>In ethernet application usually (always?)  PHY i responsible for link
>up/down,
>negotiation, mode configuration etc.
>
>So your driver must detectrelated events and/or check state, and
>report it to LwIP.
>
>Regards,
>Krzysztof Wesołowski,
>
>
>On Tue, Aug 21, 2012 at 9:42 PM, vincent cui 
>wrote:
>> Hi:
>>
>> When internet cable is plugged into board, but another side is plugged
>out
>> Slotn how lwip know that the cable is down?
>>
>> Vincent
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip raw TCP client.

[Bill Auerbach]

>I am using the sockets interface, not the raw interface.  I prefer to
>open a listener socket on my server, and let the systems handle the Port
>number details.  Perhaps someone with a bit more experience in the raw
>interface may be able to reply.

I don't have a problem with this (RAW API) but I have MEMP_NUM_TCP_PCB set
to 6.  When you get notified the client has closed the PCB (tcp_recved with
p==NULL) do you call tcp_close?  I do this and I can open and close
"forever".

But I wonder, if both ends do close the socket normally, would the PCB end
up in a TIME_WAIT?

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP API mysql or stack

[Bill Auerbach]

> Attached you will find the MySQL client modified from mbed to lwip with a
few fixes and also in C.

 

Sha1 is specified as GPL2.  Is that OK to mix with lwIP?  Does it change
lwIP's license or effect the application that includes lwIP?

 

I read the Wiki on all of the GPL permutations and which category this falls
into isn't crystal clear.

 

Thanks,

Bill

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] pbuf_free

[Bill Auerbach]

Rene Hensel writes:

> 

>i got an error using Nios2 and lwip.

> 

>i try to get data via tcp and this works but after getting the data i get
the error

> 

>
>Assertion "pbuf_free: p->ref > 0" failed at line 563 in src/core/pbuf.c
from pbuf_free(p)

> 

> 

>I dont find any solutions in the internet how to fix it except there are
multithread accesses to the pbuf but i dont know how to prevent this.

 

To follow up since the solution to this was posted on Altera Forums:

 

tcp_recved returned -1 instead of ERR_OK.

 

Bill

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] pbuf multiple assertions

[Bill Auerbach]

>On Behalf Of Víctor Mateo
>We have an annoying error using lwIP. Our software is a NIOSII C/C++ 
>application, without Operating System and Superloop.

>We are experiencing intermittent errors while trying to receive an UDP 
>message, proccess data and send this proccesed data back.

>Two common errors that we get on NIOS console are:

>-Assertion "bad pbuf type" failed at line 548 in ../lwIP/src/core/pbuf.c

>-Assertion "p->ref == 1" failed at line 599 in ../lwIP/src/core/ipv4/ip.c

Can we see the UDP packet handling code?  It sounds like memory overwriting or 
using a NULL pbuf.

 

Bill

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Being notified of an address conflict when setting address manually

[Bill Auerbach]

>Maybe we could detect the problem there, and set the interface down?
>Then the netif_status callback would be called, and the user could
>decide to use a different address?
>
>What is the best strategy here to be notified of a "wrong" choice
>for a static address (address already in use).
>
>In the general case, does lwip try to detect when other systems
>are using the same IP address?

You could enable AutoIp which does resolve conflicts.

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp_abandon

[Bill Auerbach]

>> Ok then, why isn't it public?  How do I abandon a tcp_pcb without any
>> further activity on it and releasing it ASAP.  This is a real-time
>> embedded system - loss of link is fatal.
>
>I guess because it hasn't been needed, yet. Why do your need to abandon
>a pcb ASAP if you lost the link? I would have thought you had plenty of
>time to do that until the link returns...
>
>Simon

If data gets slowed enough for whatever reason and it's not at the device
when it needs to be, the system has to be stopped.  Usually this happens
when the user tries to run too fast even without system bottlenecks (like
from his system setup, the PC or the network).  In this case we stop because
he's run out of data (Underflow).  We are in very noisy places with multiple
large motors, heaters, UV lights and we do get flaky behavior at times.  But
we don't want flakiness where a short loss of link recovers and sometimes it
doesn't underflow and sometimes it does underflow.  We have to debug
completely remotely and the errors we can catch and control we have to.
With loss of link being fatal, we stop but we want the PC to reconnect as
quickly as possible and not leave anything taking up resources from the
previous connection. On the next connect I pass back that the previous
connection lost link so at least I can report why the system was stopped.
If we have flaky wiring or a flaky switch causing loss of link we want to
know about it. Once we had to replace a switch that was causing problems.

Thanks,
Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp_abandon

[Bill Auerbach]

>> Why is tcp_abandon in tcp_impl.h and not tcp.h?
>
>Because it is not part of the documented public API that we try to keep
>stable.

Ok then, why isn't it public?  How do I abandon a tcp_pcb without any
further activity on it and releasing it ASAP.  This is a real-time embedded
system - loss of link is fatal.

Thanks,
Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] tcp_abandon

[Bill Auerbach]

Hello,

 

Why is tcp_abandon in tcp_impl.h and not tcp.h?  I need to abort without
sending an RST .  This is for the case of loss of link - there's no point in
trying to send anything when aborting.

 

Thanks,

Bill

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip whole performance down

[Bill Auerbach]

Vincent,



In my experience, most performance issues have been in my driver or hardware
platform, not in lwIP.  I don’t use a real OS so I can’t speak to its
added overhead.



I do note you changed PBUF_POOL_BUFSIZE.  I believe if smaller than the
default you get chained pbufs which is a little less efficient than one
packet per pbuf.



Bill



From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of vincent cui
Sent: Wednesday, May 16, 2012 1:49 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] lwip whole performance down



Hi :



I enable LWIP_STAT to get LWIP status when performance goes down. but it
seems no error detected …

Anyone help to have a look  ?



ETHARP

 xmit: 2

 recv: 761

 fw: 0

 drop: 0

 chkerr: 0

 lenerr: 0

 memerr: 0

 rterr: 0

 proterr: 0

 opterr: 0

 err: 0

 cachehit: 1750



IP

 xmit: 1753

 recv: 1971

 fw: 0

 drop: 0

 chkerr: 0

 lenerr: 0

 memerr: 0

 rterr: 0

 proterr: 0

 opterr: 0

 err: 0

 cachehit: 0



TCP

 xmit: 1

 recv: 1757

 fw: 0

 drop: 0

 chkerr: 0

 lenerr: 0

 memerr: 0

 rterr: 0

 proterr: 0

 opterr: 0

 err: 0

 cachehit: 0



MEM HEAP

 avail: 12288

 used: 1676

 max: 1760

 err: 0



MEM RAW_PCB

 avail: 4

 used: 0

 max: 0

 err: 0



MEM UDP_PCB

 avail: 6

 used: 1

 max: 2

 err: 0



MEM TCP_PCB

 avail: 16

 used: 1

 max: 2

 err: 0



MEM TCP_PCB_LISTEN

 avail: 6

 used: 4

 max: 4

 err: 0



MEM TCP_SEG

 avail: 32

 used: 0

 max: 1

 err: 0



MEM NETBUF

 avail: 2

 used: 0

 max: 0

 err: 0



MEM NETCONN

 avail: 8

 used: 2

 max: 2

 err: 0



MEM TCPIP_MSG_API

 avail: 8

 used: 0

 max: 0

 err: 0



MEM TCPIP_MSG_INPKT

 avail: 8

 used: 1

 max: 1

 err: 0



MEM SYS_TIMEOUT

 avail: 10

 used: 6

 max: 6

 err: 0



MEM SNMP_ROOTNODE

 avail: 30

 used: 0

 max: 0

 err: 0



MEM SNMP_NODE

 avail: 50

 used: 0

 max: 0

 err: 0



MEM SNMP_VARBIND

 avail: 2

 used: 0

 max: 0

 err: 0



MEM SNMP_VALUE

 avail: 3

 used: 0

 max: 0

 err: 0



MEM PBUF_REF/ROM

 avail: 16

 used: 0

 max: 0

 err: 0



MEM PBUF_POOL

 avail: 10

 used: 2

 max: 2

 err: 0





From: lwip-users-bounces+vincent.cui=enlogic@nongnu.org
[mailto:lwip-users-bounces+vincent.cui=enlogic@nongnu.org] On Behalf Of
vincent cui
Sent: 2012年5月15日 21:31
To: Mailing list for lwIP users
Subject: [lwip-users] lwip whole performance down



Hi:



I am working on LWIP1.4.0 and FreeRTOSv7.1.1 to setup web server with SOCKET
API..and found that sending speed becomes lower.

In order to know the actual sending speed, I write a simple application to
test it. And found that the sending speed is up to 8Mb/s. it is high enough
for me.

I notice that the application only setup connection one times. In web
server, it closed connection after sending all data out. I do n’t know if
it may cause system

Performance down. I extend the sending buffer as I can. They are following:



#define TCP_MSS (1500 - 40)   /* TCP_MSS = (Ethernet MTU -
IP header size - TCP header size) */



/* TCP sender buffer space (bytes). */

#define TCP_SND_BUF (8*TCP_MSS)



/*  TCP_SND_QUEUELEN: TCP sender buffer space (pbufs). This must be at least

  as much as (2 * TCP_SND_BUF/TCP_MSS) for things to work. */



#define TCP_SND_QUEUELEN(4* TCP_SND_BUF/TCP_MSS)



/* TCP receive window. */

#define TCP_WND (4*TCP_MSS)



/* -- Pbuf options -- */

/* PBUF_POOL_SIZE: the number of buffers in the pbuf pool. */

#define PBUF_POOL_SIZE  10



/* PBUF_POOL_BUFSIZE: the size of each pbuf in the pbuf pool. */

#define PBUF_POOL_BUFSIZE   1024



/* MEMP_NUM_TCP_SEG: the number of simultaneously queued TCP

   segments. */

#define MEMP_NUM_TCP_SEG64



/* MEMP_NUM_TCP_PCB: the number of simulatenously active TCP

   connections. */

#define MEMP_NUM_TCP_PCB32



/* MEM_SIZE: the size of the heap memory. If the application will send

a lot of data that needs to be copied, this should be set high. */

#define MEM_SIZE(12*1024)



/* MEMP_NUM_PBUF: the number of memp

Re: [lwip-users] raw lwIP on uC, timer or Ethernet Interrupt?

[Bill Auerbach]

>BTW - it sounds like you are polling the ethernet input.  I personally
>dislike polling when an interrupt is available.  But you cannot rely on
>the timing of packets arriving.

However, depending on the processor, at GBpbs speeds the packet interrupt
overhead becomes significant over polling.  This might be why some
processors (e.g. the PowerPC PowerQUICC) have the option to interrupt after
N number of packets or M microseconds since last packet.  

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp_recved

[Bill Auerbach]

>As a general advisory, I'm with on that, Kieran.
>
>However, I think Bill's way might be correct in his very special case
>here: calling tcp_recved from the receive callback without freeing the
>received pbuf does not hurt the stack. The only problem might be running
>out of pbufs (so newly arriving packets are dropped, like Kieran wrote).
>But as long as you impose an outer limit on the number of pbufs being
>buffered like that (on all connections, globally!), this should not have
>a negative impact on performance or what soever.

Would this limit me to TCP_WND of received data?  My thinking is if I don't
run out of pbufs and call tcp_reced on every receive callback, I would be
buffering using pbufs instead of copying into a memory buffer (using less
pbufs).  I plan on using something like pbuf_cat to build this list keeping
p->tot_len (the top) valid.  When p->tot_len is the size that's sent, I can
process the data.  pbuf_cat is inefficient for large chains, but since I own
the chain, I can link these more efficiently.  Yes, I know pbufs were not
designed for packet chains which is what I am building.  Maybe pbuf_cat_pkt
would be nice - just add to the end keeping the front tot_len correct, and
pbuf_top_pkt to remove the first updating p->next->tot_len.  Neither of
these would entail traversing the list.

To really support zero-copy large (MB) receives, I can't think of anything
more efficient to do, can you?

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] How to send a large dynamic generated http page?

[Bill Auerbach]

>I've the same problem to solve. In my case they are log files with up to
>64KB. With the standard LwIP http server example it's not possible to
>send files with a size above the allowed buffer size. In most cases
>hs->left points just to the address in this buffer. So I think the best
>way is to create a other function which allows the "streaming" of the
>data (filling the buffer and sending and not to close the connection,
>even complete data was send).

It can be done because I've sent up to 800k files using the original
(non-SSI) httpd and note that I was basing this on the httpd_raw (sp?) demo.
Regardless of the file size the tcp_sent callback is used to continue to
send until the file end is reached.  I would expect 10k, 100k or 1MB to be
identical in the handling.

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] tcp_recved

[Bill Auerbach]

Hello,
Is it acceptable or incorrect to call tcp_recved from the receive callback
even if the pbuf isn't freed? I am buffering pbufs in the callback until I
have enough to process what has come in.  This buffering could be in the
hundreds.  There's no memory limit - I have 6000 pbufs preallocated.
Thanks,
Bill
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Understanding pbuf's

[Bill Auerbach]

Martin,

 

>Thanks for your reply. I am currently also using a generic queue to store
pointers to pbufs.

>But I still don't understand how this correlates to "pre-allocation".

 

>Maybe, I misunderstand the meaning but I do not allocate any pbufs. All I
have is a queue

>of pbuf pointers. In the ISR, all I can do is then update the reference to
the newly 

>received frame's payload. 

 

If you do not allocate pbufs, what do the pbuf pointers point to that are in
your queue?

 

I do the same - in the DMA RX (which interrupts when the packet data is
ready to be DMAd) I DMA into the pbuf payload - but that pbuf was
preallocated and in the array of pbuf pointers. That payload pointer is set
by pbuf_alloc.  I don't have to allocate in the RX ISR - I only need to kick
off the DMA and update to the next index in the array.

 

Bill

 

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Martin Osterloh
Sent: Tuesday, April 17, 2012 12:41 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Understanding pbuf's

 

Bill,

 

Thanks for your reply. I am currently also using a generic queue to store
pointers to pbufs.

But I still don't understand how this correlates to "pre-allocation".

 

Maybe, I misunderstand the meaning but I do not allocate any pbufs. All I
have is a queue of pbuf pointers. In the ISR, all I can do is then update
the reference to the newly received frame's payload. 

 

What am I missing something?

 

Thanks again,

-Martin

On Tue, Apr 17, 2012 at 10:46 AM, Bill Auerbach 
wrote:

>I was also wondering: To pre-allocate pbufs, do I have to that in
pbuf_init() (which is currently empty) or does LwiP take care of that
internally? 

 

I create an array of pbuf pointers in ethernetif_init.  The ISR adds a RX
packet to a pbuf next  in line in the array using a circular queue using the
array index in and out slot.  Then my low_level_input (which is polled in my
case) removes the new RX pbuf(s) and uses pbuf_alloc to replace it/them.  I
then return the new RX pbuf.  lwIP will free this packet when it's done.
The size of the array depends on how much memory you want to tie up in pbufs
as they will always be allocated for keeping the array full.

 

 


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Understanding pbuf's

[Bill Auerbach]

>I was also wondering: To pre-allocate pbufs, do I have to that in
pbuf_init() (which is currently empty) or does LwiP take care of that
internally? 

 

I create an array of pbuf pointers in ethernetif_init.  The ISR adds a RX
packet to a pbuf next  in line in the array using a circular queue using the
array index in and out slot.  Then my low_level_input (which is polled in my
case) removes the new RX pbuf(s) and uses pbuf_alloc to replace it/them.  I
then return the new RX pbuf.  lwIP will free this packet when it's done.
The size of the array depends on how much memory you want to tie up in pbufs
as they will always be allocated for keeping the array full.

 

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp_sndbuf return 0 when sending file

[Bill Auerbach]

>I use LWIP 1.3.2, after server receive a lot of data packet from client for
a while .

>The system performance is lower, anyone know how to perfact it ?

 

I would use lwIP 1.4.1.  Why spend all this time developing and testing on
something already out of date with known problems fixed in later versions?

 

Bill

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] flow of lwip as a stream client

[Bill Auerbach]

>-Original Message-
>So, why don't you just use your received pbuf(s) directly in your audio
>function ?
>This way:
>- the size of your "buffer" (made of pbufs) is the size of your TCP
>window
>- the server cannot send more
>- no copy, less memory used (only the TCP window vs buffer + TCP window)

Great idea.  You can keep a queue of pbufs of incoming data.  Which leads to
a question - what if you do this until lwIP runs out of pbufs?  Does it
throttle back automatically when it's out of pbufs?

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] flow of lwip as a stream client

[Bill Auerbach]

It seems from reading this discussion that perhaps tcp_recved is badly
named.  It's not that it's been received but that it's been processed.  I
would think tcp_processed (or similar) would convey a better meaning as to
what this function is accomplishing.

>-Original Message-
>Calling tcp_recved() gives the server permission to send more data, so
>you can use this to throttle the server. The server will never send more
>data than fits into the TCP window, so if you implement this correctly,
>you will *never* get more data than you can buffer. The only requirement
>here is that sizeof(your_buffer) >= TCP_WND.



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip 1.4.1 bug-fix release

[Bill Auerbach]

>That maximum size of a UDP datagram should only be limited by the
>protocol and your resources, so 64K should work, yes.

With UDP being unreliable, that implies that one or more fragments could be
dropped in a large UDP send, right?

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP/WIN32 UDP performance (throughtput)

[Bill Auerbach]

>Ok, maybe we need 2 settings:
>1. alignement of pbuf struct
>2. alignement of pbuf payload (may lead to wasted memory)

I did this like you did Stephane (modified the #defines) and I also agree
that both of these would be useful if built-in.

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP/WIN32 UDP performance (throughtput)

[Bill Auerbach]

>I've been meaning to talk to you about this issue.
>Since I use DMA, there are hard constraints on the location of the
>buffer.
>It must start at an address multiple of 32 (cache line aligned) and the
>length must be a multiple of 32, and we must purge the appropriate lines
>from cache before the DMA operation.
>
>I suppose I could allocate 32 more bytes to hold the pbuf struct and
>fudge the pointers to make the payload start on the right boundary,
>but you've said that pbuf_header could move the start of payload,
>or something like that... More voodoo stuff.

This is what I've done on 2 platforms - both use DMA and zero-copy (one uses
chained DMA and needs cache maintenance). I've done this "fudging". I
aligned the payload and padded it out to the required size.

>Like someone said on the list, I think lwip wants control over
>the packet buffers, which is a problem when a driver also needs
>control over the buffers.

It's not a problem that can't be overcome with lwIP as is.  If this pbuf
driver management was done from the onset, all the better.  But it wasn't
and they would risk breaking compatibility with a lot of lwIP programs if
pbuf use and the API for it is changed.

Bill


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP/WIN32 UDP performance (throughtput)

[Bill Auerbach]

Stas,

 

Res, RAW API and NO_SYS=1.  You don't need threads with RAW API if you have
a "big loop" type of program that spins processing lwIP timers and other
system events.

 

Single threaded?  Yes and no I guess.  We use a cooperative RTOS so there
are many tasks, but one task handles Ethernet, lwIP and its callbacks.  The
other threads (tasks) do send TCP data but being cooperative in nature there
is never a worry as to when they do need to send something.  Being mostly
event driven, lwIP's task gets 99%-interrupt processing time of CPU time so
there is always all the bandwidth we need.  This is a real-time system and
can push 50-60MB/S (TCP) and at this speed 30% of the processor is then
processing interrupts (not Ethernet interrupts - they are polled).

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Zayaz Volk
Sent: Tuesday, February 07, 2012 11:32 AM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] LWIP/WIN32 UDP performance (throughtput)

 


Bill,
Do you use the RAW API with NO_SYS=1, i.e. singe threaded ?
Don't you need another threads to be able to send a data over ethernet ?
Is your application single threaded ?

I guess i would need an ability to send a data over ethernet from other
threads as well, so NETCONN might be my "lowest" possible API, or did i miss
something ?
If NETCONN API is the "lowest" way to run a lwip in multi threaded
environment, did somebody tried to profile this API on PC or its own
Hardware (i.e. did somebody use an lwip in multi threaded environment) ?
What was the outcome ?

Thanks,
Stas

  _  

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP/WIN32 UDP performance (throughtput)

[Bill Auerbach]

I totally agree with Simon, at least with RAW API - I can't speak for
NETCONN performance.  My "embedded" system is like yours (667Mhz CPU and
256MB  667Mhz DDR2) and is zero-copy with optimized checksum (aligned
accesses and in assembly).  I can reach 500-600+MbS with TCP.  In my testing
of UDP the PC in some instances was not able to keep pace receiving.  I do
not run lwIP on the PC - we use Win32 sockets so far without issues.

 

It would be nice to see a standard Win32/Linux program to communicate with a
simple lwIP test program (RAW, NETCONN, sockets) to create a list of lwIP
platforms and the results of the tests.

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Simon Goldschmidt
Sent: Tuesday, February 07, 2012 12:57 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] LWIP/WIN32 UDP performance (throughtput)

 

Zayaz Volk  wrote:

Obviously, it raise the questions

1. Did anyone try to work with lwip on linux/Win32 and what throughput
you've been able to achieve ?

 

In my opinion, the win32 port is mainly limited by the netif driver: winpcap
doesn't seem to give the best performance, since we have to copy packets
twice on RX (and I don't remember if it's once or twice on TX). Also, lwIP
doesn't really benefit from multiple CPU cores. Instead, you're right that
it is targeted on low resources rather that throughput. 

 

Still, i think lwIP should be able to achieve the performance you want if:

A) your netif driver correctly supports zero copy and

B) you handle the stack "correctly" so that zero copy is possible (I.e. data
passed to a TX function must be left unchanged in memory until the netif
driver has actually sent it out).

 

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE

[Bill Auerbach]

A pbuf of PBUF_POOL_BUFSIZE is alloctated for every pbuf_alloc of PBUF_POOL. So 
PBUF_POOL_BUFSIZE must be the same or larger than any incoming our outgoing 
packet that’s going to use a pbuf_alloc to obtain a packet buffer.  I had a 
similar problem to yours in not adding ETH_PAD_SIZE (2) to PBUF_POOL_BUFSIZE 
and every pbuf_alloc for a packet had a chained pbuf with the second pbuf 
containing the 2 bytes. 

 

PBUF_POOL_BUFSIZE doesn’t constrain the incoming our outgoing packet size – 
it’s the maximum size that’s going to be used for all PBUF_POOL pbuf_allocs.

 

Bill

 

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Gary Spivey
Sent: Wednesday, December 07, 2011 5:47 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Incoming packet bigger than PBUF_POOL_BUFSIZE

 

Thanks, this doesn’t yet work for me … but it does change the problem and leads 
me to another question that might help.

 

It appears that the buffer allocate does not give me a buffer of the size 
requested, but constructs a chain of buffers whose total size is what has been 
requested. 

What I have been doing is getting the buffer address and copying the entire 
received Ethernet buffer into that address. With this change, it seems clear 
that I cannot do this, but that I have to manage the copy into this chain of 
buffers. Is there an lwip-provided method to do this, or do I just need to 
follow the chain myself? I am looking through the documentation, but I haven’t 
found anything yet.

 

-Gary

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] help request; need to get a grip of lwIP

[Bill Auerbach]

Mauro,

If you're using a static IP address, you need to call netif_set_up yourself
once you've set the static IP in the netif.  If you're using DHCP or AutoIP
these both call netif_set_up and so it will happen automatically once an IP
address is established by these methods.

Bill

>-Original Message-
>From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
>[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On
>Behalf Of mcondare...@soft-in.com
>Sent: Wednesday, November 16, 2011 4:35 PM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] help request; need to get a grip of lwIP
>
>Real sorry.
>I sent the message before it was finished.
>Continuation follows below.
>
>Regards
>Mauro
>
>- Messaggio originale -
>> Hi,
>> I'm struggling with my first lwIP port.
>> I need to implement a few services, mostly based on TCP.
>>
>> One of the first things I need to do is to create a socket to allow
>> remote to connect, when this happens I should start sending some
>> logging messages over the socket.
>> If none is connected messages are silently discarded.
>>
>> My real problem is to get to the first stage of the connection.
>>
>> For some tests I used apps/tcpecho_raw as template.
>>
>> My main program calls (no prior lwIP code) the function IP_start(0).
>>
>> ---
>> struct netif netif;
>>
>> /* static port number; workaround for lwIP slipif deficencies */
>> int slipif_port = -1;
>>
>> static void ip_init(void *param)
>> {
>> IP4_ADDR(&gw, 192, 168, 0, 1);
>> IP4_ADDR(&ipaddr, 192, 168, 0, 2);
>> IP4_ADDR(&netmask, 255, 255, 255, 0);
>>
>> netif_add(&netif, &ipaddr, &netmask, &gw, NULL, slipif_init,
>> tcpip_input);
>> nmea_init();
>> }
>>
>> error_t IP_start(u8_t port)
>> {
>> if (slipif_port != -1)
>> {
>> main_debug_printf("IP_start: already initialized!\r\n");
>> return FAILURE;
>> }
>> slipif_port = port;
>>
>> tcpip_init(ip_init, NULL);
>> return SUCCESS;
>> }
>> ---
>> nmea_init() is the function that initializes my application
>> ---
>---
>void nmea_init(void)
>{
>   LWIP_DEBUGF(N_DEBUG, ("nmea_init: start\r\n"));
>   nmea_pcb = tcp_new();
>   if (nmea_pcb != NULL)
>   {
>  err_t err;
>
>  err = tcp_bind(nmea_pcb, IP_ADDR_ANY, 1000);
>  if (err == ERR_OK)
>  {
> LWIP_DEBUGF(N_DEBUG, ("nmea_init: bound\r\n"));
>
> nmea_pcb = tcp_listen(nmea_pcb);
> tcp_accept(nmea_pcb, nmea_accept);
> LWIP_DEBUGF(N_DEBUG, ("nmea_init: waiting for
>connection\r\n"));
>  }
>  else
>  {
> LWIP_DEBUGF(N_DEBUG, ("nmea_init: unable to bind\r\n"));
>  }
>   }
>   else
>   {
>  LWIP_DEBUGF(N_DEBUG, ("nmea_init: unable to allocate pcb\r\n"));
>   }
>}
>---
>The function nmea_accept() is never called.
>I traced the error down to lwip/core/ipv4/ip.c where the test:
>---
>  /* interface is up and configured? */
>  if ((netif_is_up(netif)) && (!ip_addr_isany(&(netif->ip_addr {
>/* unicast to this interface address? */
>if (ip_addr_cmp(¤t_iphdr_dest, &(netif->ip_addr)) ||
>/* or broadcast on this interface network address? */
>ip_addr_isbroadcast(¤t_iphdr_dest, netif)) {
>  LWIP_DEBUGF(IP_DEBUG, ("ip_input: packet accepted on interface
>%c%c\n",
>  netif->name[0], netif->name[1]));
>  /* break out of for loop */
>  break;
>}
>---
>fails because netif_is_up(netif) returns FALSE.
>
>Struct netif appears to contain the right values, but I'm obviously
>missing some needed initialization.
>
>Can someone point me to some complete initialization fitting my cases?
>I will try debugging through the code and I believe I can find out which
>function does the required initialization, but it's far from being an
>efficient process.
>
>I really need to get a grip on the various programming interfaces lwIP
>has, possibly mixing them in a sensible way.
>
>I will need to implement several semi-unrelated services all insisting
>on the same SLIP connection; some of them are best suited for the RAW
>interface while some other would prefer a connection; is it possible to
>mix (on different applications, of course)?
>
>TiA
>Mauro
>
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Automatic Rx DMA ring replenish

[Bill Auerbach]

Simon,

 

I commented based on the “This should improve performance” statement in Timmy’s 
message.  The intent was not to invalidate the change or deem it unnecessary, 
only to not have performance be a reason one heads off in the direction of 
adding this feature to their port.  I well could be wrong about performance too 
– this is merely an opinion based on code review.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Simon Goldschmidt
Sent: Thursday, November 03, 2011 9:47 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Automatic Rx DMA ring replenish

 

"Bill Auerbach" :

I haven’t benchmarked to be able to provide factual data, but I’ve done a lot 
of optimization and tweaking of lwIP to improve bandwidth and my study of pbufs 
and memory pools did not show the need for improvement considering all of the 
other things required to handle a TCP connection.

 

I saw the patch not as speed optimization but as a way to simplify the netif 
driver: to provide a robust implementation, a netif driver would have to ensure 
it retries if pbuf_alloc fails because the pool is empty (to prevent a 
deadlock). This patch prevents a netif driver having to implement some sort of 
timer because it just gets notified when pbufs are available again.

 

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Automatic Rx DMA ring replenish

[Bill Auerbach]

Timmy,

 

I haven't benchmarked to be able to provide factual data, but I've done a
lot of optimization and tweaking of lwIP to improve bandwidth and my study
of pbufs and memory pools did not show the need for improvement considering
all of the other things required to handle a TCP connection.  Pbuf_alloc of
PBUF_POOLS doesn't use a lot of runtime when the alloc fits in one pbuf, and
memp_malloc and memp_free run only a few lines of simple C code to complete.
Pbuf_free also does very little on a single (unchained) pbuf.  You are in a
position to test for the actual improvement.  I would be curious (and
surprised) if the overall performance increases significantly, or even
noticeably.  From my experience, there are several other areas to improve
that significantly increase performance.  One of them I submitted a patch
for and is already included in lwIP and others are optimizing your Ethernet
port, improving inet_chksum and using zero-copy TX and RX.  For me
optimizing memcpy (using assembly code and unrolled loops and indexed
addresses) helped a good bit as well.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of w...@brolinembedded.se
Sent: Wednesday, November 02, 2011 1:10 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Automatic Rx DMA ring replenish

 

On 30 okt 2011 18:13 "Simon Goldschmidt"  
 wrote:



"w...@brolinembedded.se"  
 wrote:



What if I make the Rx DMA buffer descriptor ring large enough to hold all
POOL pbufs. At start-up all POOL pbufs are allocated and put in the Rx DMA
ring.
pbuf_free() is modified so that whenever a POOL pbuf is freed it is
immediately put in the Rx DMA ring.

This should improve performance, as well as simplify the ethernet driver a
bit.


If it works for your hardware, good enough. The modification would probably
be calling your custom free function instead of memp_free from pbuf_free.

However, I don't think that will work with many DMA enabled MACs: the ones
I've worked with have the RX descriptors in internal memory, so the ring
can't be made larger. And because RX packets are sometimes buffered (i.e.
TCP OOS data), you will want to have many more PBUF_POOL pbufs than fit into
your DMA ring (depending on its size and the expected throughput, of
course).

However, I guess providing a way to change memory allocation/deallocation to
use custom functions would be a good thing to support many different types
of zero copy MACs without having to change the lwIP code for every hardware,
so I guess it's well worth a try for your target!

Simon


I have tested this method on my hardware and it works nicely.
This is my suggestion for how it can be implemented in LwIP:

In pbuf.c, function pbuf_free(), change this:

   /* is this a pbuf from the pool? */
   if (type == PBUF_POOL) {
 memp_free(MEMP_PBUF_POOL, p);

To this:

   if (type == PBUF_POOL) {
 if( !DMA_RING_REPLENISH( p ) ) {
   memp_free(MEMP_PBUF_POOL, p);
 }

In opt.h, add this:

#ifndef DMA_RING_REPLENISH
#define DMA_RING_REPLENISH( p ) 0
#endif

In lwipopts.h, the feature can be enabled by a define like this:

#define DMA_RING_REPLENISH( p ) MAC_ReplenishRx( p )


The way it works is that whenever a PBUF_POOL is deallocated, it is first
offered to the Ethernet driver via the function DMA_RING_REPLENISH(). If the
Ethernet driver wants the pbuf, it returns true. If however the Ethernet
driver does not want the pbuf at this time (DMA ring is already full), then
the pbuf is is freed normally using memp_free().

By offering the pbuf to the Ethernet driver directly, the entire
memp_free(), context switch, pbuf_alloc() sequence is bypassed, saving CPU
cycles.

Regards,
Timmy Brolin

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] TCP bandwidth limited by rate of ACKs

[Bill Auerbach]

That 7.4% for memcpy is a direct hit on throughput.  You're seeing a
breakdown of total CPU time.  How much of that 7+% for memcpy comes out of
the total time used by lwIP?  I think you'll find that to be a much larger
hit and a large contributor to lower bandwidth.

>OS21 profile analysis for main.out
>(16 bytes per bucket, sampled at 1000 Hz, system wide profile)
>
> 515.859 seconds (100.00%) :  Total duration
>
>Task breakdown:
> 218.810 seconds ( 42.42%) :  tcpip_thread
> 144.978 seconds ( 28.10%) :  rxapp
> 121.828 seconds ( 23.62%) :  RxTask
>   0.476 seconds (  0.09%) :  Idle Task
>   0.350 seconds (  0.07%) :  STLAYER-GFX/CUR
>   0.120 seconds (  0.02%) :  STLAYER-GFX/CUR
>   0.092 seconds (  0.02%) :  STDVM_ServiceTa
>   0.071 seconds (  0.01%) :  STLAYER-GFX/CUR
>   0.041 seconds (  0.01%) :  phy: link
>
>Interrupt level breakdown:
>  27.996 seconds (  5.43%) :  Interrupt level 8
>   0.968 seconds (  0.19%) :  Interrupt level 13
>   0.085 seconds (  0.02%) :  Interrupt level 15
>
>Symbolic breakdown:
> 261.467 seconds ( 50.69%) :  _md_kernel_intr_mask
>  38.134 seconds (  7.39%) :  memcpy
>  14.321 seconds (  2.78%) :  stxmac_dma_isr
>  13.661 seconds (  2.65%) :  tcp_input
>   9.797 seconds (  1.90%) :  _md_timer_system_time
>   7.401 seconds (  1.43%) :  _st40_kernel_interrupt_handler600
>   7.133 seconds (  1.38%) :  tcp_receive
>   6.450 seconds (  1.25%) :  _malloc_r
>   5.746 seconds (  1.11%) :  lwip_recvfrom
>   5.469 seconds (  1.06%) :  stxmac_dma_rx_start
>   4.537 seconds (  0.88%) :  _free_r
>   4.333 seconds (  0.84%) :  mutex_release
>   4.216 seconds (  0.82%) :  event_callback
>   4.189 seconds (  0.81%) :  ip_input
>   3.878 seconds (  0.75%) :  stxmac_dma_tx_start
>   3.572 seconds (  0.69%) :  _md_kernel_intr_mask_all
>   3.331 seconds (  0.65%) :  mutex_lock
>   3.315 seconds (  0.64%) :  __divdi3
>   3.016 seconds (  0.58%) :  device_ioctl
>   2.950 seconds (  0.57%) :  _os21_scheduler_lock
>   2.887 seconds (  0.56%) :  ip_output_if
>   2.830 seconds (  0.55%) :  _message_q_remove
>   2.806 seconds (  0.54%) :  __udiv_qrnnd_16
>   2.799 seconds (  0.54%) :  pbuf_alloc
>   2.746 seconds (  0.53%) :  sys_timeouts_mbox_fetch
>   2.701 seconds (  0.52%) :  semaphore_wait
>   2.700 seconds (  0.52%) :  interrupt_unmask
>   2.685 seconds (  0.52%) :  semaphore_wait_timeout
>   2.628 seconds (  0.51%) :  __libc_lock_init_complete_recursive
>   2.514 seconds (  0.49%) :  sys_arch_mbox_fetch
>   2.373 seconds (  0.46%) :  osplus_physical_address
>   2.308 seconds (  0.45%) :  pbuf_header
>   2.190 seconds (  0.42%) :  _message_q_add
>   2.137 seconds (  0.41%) :  _os21_task_is_valid
>   2.121 seconds (  0.41%) :  ethernet_input
>   2.101 seconds (  0.41%) :  recv_tcp
>   1.838 seconds (  0.36%) :  ethernet_api_ioctl
>   1.746 seconds (  0.34%) :  _os21_interrupt_handler
>   1.697 seconds (  0.33%) :  cache_purge_data
>   1.688 seconds (  0.33%) :  lwip_standard_chksum
>   1.654 seconds (  0.32%) :  _st40_cache_purge_data_work_1
>   1.582 seconds (  0.31%) :  __malloc_lock
>   1.551 seconds (  0.30%) :  profile_start_all
>   1.549 seconds (  0.30%) :  pbuf_copy_partial
>   1.485 seconds (  0.29%) :  __malloc_unlock
>   1.479 seconds (  0.29%) :  tcp_output
>   1.450 seconds (  0.28%) :  message_receive_timeout
>   1.444 seconds (  0.28%) :  ip4_addr_isbroadcast
>   1.414 seconds (  0.27%) :  ethernet_ops_do_async_tx
>   1.413 seconds (  0.27%) :  netconn_recv_data
>   1.335 seconds (  0.26%) :  etharp_output
>   1.321 seconds (  0.26%) :  do_recv
>   1.291 seconds (  0.25%) :  tcp_output_alloc_header
>   1.178 seconds (  0.23%) :  sys_arch_unprotect
>   1.175 seconds (  0.23%) :  _os21_scheduler_unlock
>   1.162 seconds (  0.23%) :  inet_chksum_pseudo
>   1.105 seconds (  0.21%) :  sys_arch_protect
>   1.090 seconds (  0.21%) :  semaphore_signal
>   1.086 seconds (  0.21%) :  sys_arch_sem_wait
>   1.073 seconds (  0.21%) :  sys_mbox_trypost
>   1.032 seconds (  0.20%) :  _os21_is_active
>   1.011 seconds (  0.20%) :  locate_handle
>   1.011 seconds (  0.20%) :  rx_task
>   0.982 seconds (  0.19%) :  tcp_recved
>   0.950 seconds (  0.18%) :  release_handle
>   0.947 seconds (  0.18%) :  __libc_lock_release_recursive
>   0.934 seconds (  0.18%) :  message_claim_timeout
>   0.922 seconds (  0.18%) :  tcp_parseopt
>   0.908 seconds (  0.18%) :  message_send
>   0.899 seconds (  0.17%) :  claim_handle
>   0.885 seconds (  0.17%) :  inet_chksum
>   0.881 seconds (  0.17%) :  ip_output
>   0.875 seconds (  0.17%) :  interrupt_mask
>   0.787 seconds (  0.15%) :  __libc_lock_acquire_recursive
>   0.786 seconds (  0.15%) :  pbuf_cat
>   0.760 seconds (  0.15%) :  time_now_set
>   0.728 seconds (  0.14%) :  tcpip_input
>   0.712 seconds (  0.14%) :  _os21_scheduler_exception_context
>   0.680 seconds (  0.13%) :  handle_frame
>   0.660 seconds (  0.13%) :  pbuf_free
>   0.621 seconds (  0.12%) :  osplus_handle
>   0.620 seconds (  0.12%) :  raw_input
>   0.607 seconds (  0.12%) :  icmp_input
> 

Re: [lwip-users] TCP bandwidth limited by rate of ACKs

[Bill Auerbach]

>Bill Auerbach wrote:
>
>> Mason wrote:
>>
>>> I was expecting to reach 80+ Mbit/s, so I captured the conversation
>>> with Wireshark, and I noticed that the sender is being throttled
>>> because the receiver (the STB running lwip) is not sending ACKs
>>> fast enough.
>>>
>>> cf. STB_TCP_RX_2.pcap (6 MB -- I truncated payloads to 100 bytes)
>>> http://dl.free.fr/tKDBuYTrc
>>>
>>> Can someone nudge me in the right direction to optimize my
>>> build of lwip?
>>
>> Some things are to optimize are the internet checksum,
>
>As a first-order approximation, I simply disabled CHECKSUM_CHECK_TCP.
>I don't think the IPv4 checksum check (20 bytes) has much of an impact
>on performance, do you?
>
>> use zero-copy receive and transmit,
>
>I wish I could, but I've no idea how to accomplish that.
>cf. my previous thread "Custom memory management"
>http://lists.gnu.org/archive/html/lwip-users/2011-10/msg8.html

For DMA RX receive (which also allows zero-copy) there was a post here a
long time ago on how to do that since I needed the same thing for the
PowerPC and implemented it based on the idea described.  The idea was you
have a queue of pbuf pointers.  You set up DMA into the payload of the first
pbuf.  The Eth RX ISR increments the RX count and sets up DMA for the next
pbuf in the list (looping at the end).  If applicable, post to a waiting
task that a packet (or more) is ready.  I used this RX count in a background
polling loop.  In the main app or task waiting for packets, remove the
oldest packet from the queue and allocate a new pbuf and replace the old
pbuf pointer with the new one.  Nothing is copied- just swap pointers.  Pass
this pbuf to ethernetif_input.  I process all packets that are waiting in
one shot.  lwIP frees the pbuf when done.

>> do SMEMCPY more efficiently,
>
>I'm not sure I can do it better than my platform's memcpy.

You definitely can.  I did a better memcpy (over the one supplied with GCC)
with some assembly using unrolled index addressing and dword copies when
data was aligned and improved most copies by 50%.

>I will try profiling to see if we're indeed spending most of
>the time copying data.

It doesn't have to be most of the time to pick up 20Mbps of speed.  It is
unfortunately harder to receive than transmit.  We use lwIP in real-time
products where either RX is critical (so we used a PowerPC there) or where
TX was critical (so we used UDP since it was a 100Mhz FPGA-based processor).
Currently on the 100Mhz product, RX is important but we only need 40Mbps.  I
found forcing 100Mpbs was better than 1000Mbps because of the packet drops
at the processor from not being able to handle packets fast enough.

>> and use RAW API.
>
>I can't. I need to implement the BSD sockets API.

This requirement may be the show-stopper.

Bill


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] TCP bandwidth limited by rate of ACKs

[Bill Auerbach]

>-Original Message-
>I was expecting to reach 80+ Mbit/s, so I captured the conversation
>with Wireshark, and I noticed that the sender is being throttled
>because the receiver (the STB running lwip) is not sending ACKs
>fast enough.
>
>cf. STB_TCP_RX_2.pcap (6 MB -- I truncated payloads to 100 bytes)
>http://dl.free.fr/tKDBuYTrc
>
>(I've also attached a copy of my current lwipopts.h)
>
>Can someone nudge me in the right direction to optimize my
>build of lwip?

Some things are to optimize are the internet checksum, use zero-copy receive
and transmit, do SMEMCPY more efficiently, review/optimize memcpy, and use
RAW API.

Use LWIP_CHKSUM_ALGORITHM = 3 as it looks like it might be the best choice
for your processor.  Or better, code the checksum in assembly language.

If you can't use zero-copy receive and you have to copy the data, use a DMA
memory-to-memory copy if your hardware supports it.  The less you touch the
data the better.

Everything else I've done has been hardware dependent or used FPGA resources
(e.g. internet checksum).

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Custom memory management

[Bill Auerbach]

>Can someone explain how to make lwip happy with this buffer
>management model, without using memcpy, i.e. having lwip
>deal directly with the buffers from TX pool and RX pool?

>I've come up with a slightly hackish solution to deal with
>receiving, but I don't see how to make sending work?

I handle this TX problem by storing the last sent pbuf in the ethernetif
structure, which is NULL at first.  When I get the next TX interrupt and
this last pbuf pointer isn't NULL, I pbuf_free it.  Then of course the one
I'm sending becomes the new previous one.  This works because I know when I
get the next TX interrupt the previous TX pbuf has to have been completely
sent.

Bill


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Nios II TSE MAC

[Bill Auerbach]

Dave,

I wonder if the NIOS II core for the Stratix is different from the NIOS II
for the Cyclone III (which is what we use).  What memory allocation are you
referring to?  We've been shipping Cyclone III NIOS II products for almost 2
years and have had no issues.  When I did see cache consistency problems
with the NIOS II, it's not been with the driver but with my application
calling into lwIP.  On the Cyclone III, cache consistency issues with SGDMA
do lock up the processor.

Bill

>-Original Message-
>I'm using the Bill Auerbach's lwIP implementation on Nios II Development
>kit Stratix II edition (rohs).
>I am experiencing some problems with memory allocation: it seems that
>the call alt_remap_uncached causes a sort of misalignment of dma data,
>so structure pointers became inconsistent. The annoying thing is that in
>most cases the whole system appears to be tolerant to the fault and the
>flow carries on through random memory locations but sometimes a simple
>call to a free makes the pointer structure to collapse and the system to
>go in error.
>
>best regards,
>Dave



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Ang: Re: Bare Metal / Memory Alignment

[Bill Auerbach]

Maybe it clears things up to say ETH_PAD_SIZE (which is usually 0 or 2) adds
bytes to eth_hdr so that everything *after* the header is 32-bit aligned.
But this must be used with Ethernet controllers that support either packet
offsets of 2 (meaning they skip the ETH_PAD_BYTES), or ones that store 16
bytes at the start (filling in the ETH_PAD_SIZE bytes).

Bill

>-Original Message-
>Most protocol headers happen to be aligned correctly for 32-bit
>processors if you insert 2 bytes before the Ethernet header. However,
>that's not supported by us, currently. So if it works, it does so by
>chance... If you get it to work without packing, you're lucky enough,
>but I doubt that it has too big of an influence on throughput, as many
>header members are only read once.
>
>Simon


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] how lwip know internet cable is unplug

[Bill Auerbach]

Vincent,

 

I have to poll the link state as well on 2 platforms but it’s a simple PHY I/O 
read and it takes very little time. I do that as part of my incoming packet 
check when there are no packets to process.  If there are packets to process 
obviously the link is up. J

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
vincent cui
Sent: Tuesday, September 06, 2011 7:14 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] how lwip know internet cable is unplug

 

 My approach is to send a signal to a separate task to handle the 
 cable-plug/unplug events

 

Ake:

 

For your approach, who send a signal to the task ? the driver ?  my driver can 
get the link status by polling, not interrupt, so it takes more cpu time..I 
stop using it 

And try to find another one to replace… maybe it need HW sensor support.

Vincent Cui
Sr.Firmware Engineer
Mobile: +8613482482211
Tel: +86 21 34612525x6104
Fax: +86 21 34619770
E-Mail: vincent@enlogic.com
Shanghai EnLogic Electric Technology Co., Ltd.
Address: 1104-1106, Building A, No.391, Guiping Road, Xuhui District, Shanghai, 
200233
http://www.enlogic.com

 

From: lwip-users-bounces+vincent.cui=enlogic@nongnu.org 
[mailto:lwip-users-bounces+vincent.cui=enlogic@nongnu.org] On Behalf Of 
ake.forsl...@nibe.se
Sent: 2011年9月2日 14:50
To: Mailing list for lwIP users
Subject: Re: [lwip-users] how lwip know internet cable is unplug

 

Hi! 

I think that is something you define in your ethernet driver. My approach is to 
send a signal to a separate task to handle the cable-plug/unplug events. In the 
task I currently disable dhcp (if active) on cable-unplug signal and reenable 
it on cable-connect. it might be good to set an auto-ip when unplugged as well, 
but I'm not sure. Maybe it should be handled with the 
netif_set_up/down-functions instead, I'm still experimenting... 

/Åke 

-
Åke Forslund
0433-273296
NIBE AB
Box 14
S-285 21  Markaryd
Tel +46-(0)433-273296




From: 

vincent cui  


To: 

Mailing list for lwIP users  


Date: 

2011-09-02 07:27 


Subject: 

[lwip-users] how lwip know internet cable is unplug 


Sent by: 

lwip-users-bounces+ake.forslund=nibe...@nongnu.org

 

  _  




Hi;

When unplug internet cable, how lwip deal it ? I want to show message to user 
in LCD to notice user !

锘?Vincent Cui
Sr.Firmware Engineer
Mobile: +8613482482211
Tel: +86 21 34612525x6104
Fax: +86 21 34619770
E-Mail: vincent@enlogic.com
Shanghai EnLogic Electric Technology Co., Ltd.
Address: 1104-1106, Building A, No.391, Guiping Road, Xuhui District, Shanghai, 
200233
  http://www.enlogic.com

-Original Message-
From: lwip-users-bounces+vincent.cui=enlogic@nongnu.org [ 
 
mailto:lwip-users-bounces+vincent.cui=enlogic@nongnu.org] On Behalf Of 
Kieran Mansley
Sent: 2011年9月2日 3:22
To: Mailing list for lwIP users
Subject: Re: [lwip-users] FreeRTOS / lwip multiple connections


On 31 Aug 2011, at 01:18, vincent cui wrote:

> K:
> You mean I need make accept socket to be non-blocking , right ?

No, I'm not sure why you need any of your sockets to be non-blocking.

Kieran

___
lwip-users mailing list
lwip-users@nongnu.org
  
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
  
https://lists.nongnu.org/mailman/listinfo/lwip-users 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] netconn->acceptmbox is NULL

[Bill Auerbach]

For UDP I think it is. You get a callback for each UDP packet that comes in.
It works very well for me.

Bill

>Ok, perhaps it would be simpler and work better to use raw API then...
>
>Thanks for all the help :)
>
>/Emil



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] std includes

[Bill Auerbach]

>To me it always was the other way round as I can then be sure that the
>(lwIP) header files do not depend on the system/library files:

Maybe this is heading off topic, but why does it matter or do you care about
this? Is there a requirement somewhere that lwIP use no references to
standard C definitions?

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] std includes

[Bill Auerbach]

I concur with this style - it's almost universal practice to include system
headers (in angle brackets) first following by application headers (in
quotes), probably for exactly the reason you state.

 

Bill

 

>The easiest solution was to make the standard includes the first includes
in all lwIP files. I also think it makes some sense to have the standard
 and  

>includes at the top of the list of includes before any project specific
includes, since project specific includes may be depending on the standard
libraries, while the standard 

>libraries will of course never be depending on any project specific
includes.



 

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] std includes

[Bill Auerbach]

>Anyone got any preferences on this?

Thoughts maybe.  Those header files are defined for ISO Standard C, at least
in C89 and later.  To make these changes means you're now catering to
non-standard compilers.  It's one thing to makes changes for warnings in
popular standard C compilers (e.g. GCC) but I thought handling special
platforms or sub/non-standard compilers was not a goal of lwIP.

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] having trouble with 'ethernetif_init' & 'ethernetif_input'

[Bill Auerbach]

>Since you are using NIOS, chances are high that a driver for
>your MAC already exists.

Yes, there's been one for over a year, right on the Wikia too:
http://lwip.wikia.com/wiki/Available_device_drivers

This was developed for 1.3.2 - I and others have had no problems using it
with 1.4.x.

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] DHCP, switch to static IP if no answer

[Bill Auerbach]

Yes, I know it can be a problem, but it was more important that our devices
could be found quickly by a discovery program than by the (probably rare)
occurrence of a slow DHCP server.

But, you got me thinking...  it would be interesting if devices had AutoIP
addresses while waiting for the DHCP server.  Wouldn't it make sense to
provide an AutoIP address immediately to be able to talk to and/or find
devices and let the DHCP code change it when (or if) the address is
assigned?

Bill

>Just for the protocol: Doing this, you might run into problems if you
>only wait 5s. RFC2131 (DHCP spec) says:
>
>"4.4.1 [...] The time over which the client collects messages and the
>mechanism used to select one DHCPOFFER are implementation dependent."
>
>Well, they don't give any numbers, but Windows/Linux/BSD all wait far
>more than 5s before giving up. Reasons might be ARP checking timeouts at
>the DHCP server wait longer before sending a DHCPOFFER.


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Pbuf pool size and network interface

[Bill Auerbach]

>Is such a small MSS valid?  All IP networks are supposed to guarantee
>that they can receive a segment of 576 bytes without fragmenting, so
>assuming the default header sizes that would make a TCP segment of 536
>bytes.  While setting it smaller might be OK in most situations, you
>might find that this causes interoperability problems with other stacks,
>as they could ignore your MSS request and just use 536 instead.

As there is a minimum (i.e., if an RFC states that there is one) it would be
a good init.c compile-time check.

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] DHCP, switch to static IP if no answer

[Bill Auerbach]

Simon,

 

Good points, yes.  I did handle RX packets in that loop in a way I didn't
want to get sidetracked into if I showed the real code.  So I should have
mentioned that I did this.  I was trying to simplify things to simply show
the lwIP API calls that could be used to achieve the desired result.  Hoping
that helped out better than not replying at all. J

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Simon Goldschmidt
Sent: Friday, June 24, 2011 4:40 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] DHCP, switch to static IP if no answer

 

"Bill Auerbach"  wrote:

I used dhcp_start and then checked in a loop netif_is_up for a connection
for 5 seconds.

Might be a bit late, but I do have to note that this can't work when using
lwIP correctly, as it does not obey the lwIP threading requirements. You
would have to use an lwIP timer or a callback to orctly implement the 5
second timeout instead of a loop. Or you would have to handle RX packets in
that loop...

 

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] DHCP, switch to static IP if no answer

[Bill Auerbach]

Walter,

 

I used dhcp_start and then checked in a loop netif_is_up for a connection
for 5 seconds.  If the 5 seconds ran out, I used dhcp_stop, netif_set_down,
netif_set_addr, netif_set_up, and dhcp_inform to set a static IP address.
This worked well for me.  I guess the dhcp_inform isn't needed but I used
this same code if I was simply setting a static IP address in which case I
wanted the DHCP server to know about this.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Walter Saegesser
Sent: Wednesday, June 22, 2011 8:37 AM
To: lwip-users@nongnu.org
Subject: [lwip-users] DHCP, switch to static IP if no answer

 

In the current project DHCP is enabled by default, assuming that in most
cases there is a DHCP server around.

But what, if not.

1.   How can I realize there is no answer from a DHCP server? Do I have
to wait for some time, say a minute, and then check whether the netif IP
address is still 0? Or is there a better and more convenient way? (I'm
working with netconn API).

2.   Assuming I have detected the failure, what do I have to do to
switch to a static default IP (and GW, and mask)? Would this be the correct
code?

dhcp_stop ( &mNetIf ); 
mNetIf.flags &= ~NETIF_FLAG_DHCP;
netif_set_addr ( &mNetIf, &xIpAddr, &xNetMask, &xGwAddr );

 

Thanks a lot.

Walter

 

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Re transmission problem?

[Bill Auerbach]

>Compared to what? 20-30% increase after moving from 1.3.2 to 1.4.0? That
>would be nice.

IMO it's quite possible. The inlined IP header checksumming could be a good
part of this depending on platform and compiler and its optimizations.

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Partial read on receive callback

[Bill Auerbach]

> I don't want to be picky, but this is potentially confusing to beginners:
it should be named receive callback, as tcp_recved() is a function which
does something totally

> different ;-)

 

Being clear is not being picky - thanks for making it clearer.

 

> Yep, I introduced that when changing tha httpd to allow request packets to
be spanned accross multiple packets. I'm essentially doing the same thing as
you do there.

 

I see 2 big differences - my implementation deletes pbufs as each one is
exhausted of data and I don't need to keep track of where in the pbuf I'm
resuming from.  Each call for len bytes returns len bytes and the next read
is at byte len+1.

 

It would be nice if there were a sanctioned method to do what I did since I
see it as very common to want to know how much is received and then read
part of or all of that amount when it's large enough to read.

 

Bill

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Partial read on receive callback

[Bill Auerbach]

Maybe it will help you to know how I do what you're doing, since I'm in the
same situation.  But more, I sometimes get a packet (which needs to be
complete) which then says here's a variable part of the remainder of the
application function (which the first packet has the size of).

 

My tcp_received takes the incoming pbufs and uses pbuf_cat to combine them
to a head packet (which is kept in a static variable).  Each tcp_received
calls back to the application with the total length of this pbuf chain.  If
there is enough data, the application calls a function 'TcpRead(u8_t *ptr,
u32_t len)'.  This function copies len bytes to ptr from the pbuf chain,
deleting pbufs as each one is completely read.  To leave data behind, I do
unfortunately have to modify the latest pbuf payload, len and tot_len but
this allows the pbuf_cat to continue to work for incoming tcp_received calls
and the next read from the application to find the leftover (and new) data.

 

Actually, I just checked and there is (is it new???) a pbuf_copy_partial
which does what I did in my own code.  I will switch to use this function.

 

This method allows me to read data into a contiguous memory block which was
a requirement for me.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Enrico Murador - Research & Development - CET
Sent: Friday, May 13, 2011 5:14 AM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] Partial read on receive callback

 

Dear Kieran,
Thank you for the reply.



The callback won't be called again until there is new data, and the data
passed to the callback will only be the new data; it won't (I think)
pass you the data you've been given already as you were hoping.  I'm
afraid you have to create a list of the data you're interested in until
you've got enough to process.  You don't need to copy it, as this is the
point of tcp_recved() - it allows you to keep hold of the data until
you've finished with them, even if that's not straight away during the
callback.  Once you've processed and finished with the data, call
tcp_recved() and the stack will be allowed to reuse those buffers.
 
Kieran
 

It is ok for me to keep the data on the packet buffers, but I'm concerned
with the
possibility that at the end of the buffer chain I will find a "partial"
message; in that
case, If I understand well, I have two choices:

- Leave all the data in the buffers by not calling tcp_recved() and waiting
for another
  chunk of data, hoping that at that time the buffers contains a "complete"
sequence
  of messages (some of wich I could have already processed);
- Copy the part of the uncomplete message in a separated buffer (and
advertise
  the stack that I have processed all the data), chaining it with
  the new data that will arrive the next time...

Am I supposing right?

Thank you very much
Enrico

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP driver from lwIP

[Bill Auerbach]

Maybe you (lwIP developers) shouldn't use the term STABLE because not having
it implies UNSTABLE which is far from the truth.  If no one used an RC
because it's an RC, then the risk of problems in the STABLE release is much
higher.  We've been shipping 1.4 in 4 products long before an RC was even
released.  If I've done my homework (i.e. testing) then whatever is there is
STABLE as far as I'm concerned because I don't find problems.  It's not like
this is 1.0 - it's 1.4.  IMO the more of us who use the latest release (RC
or not) the better for everyone, and the sooner we will have a more "stable"
release.

Bill

>-Original Message-
>From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
>[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On
>Behalf Of narke
>Sent: Thursday, May 05, 2011 10:16 AM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] PPP driver from lwIP
>
>On 5 May 2011 22:01, Simon Goldschmidt  wrote:
>>
>> narke  wrote:
>>> Actually, our company was using lwIP 1.1.1 long time ago. Now I am
>>> about to upgrade it to lwIP 1.3.2.
>>
>> I *strongly* suggest to use 1.4.0RC2 instead of 1.3.2, as it is about
>to be released and in my opinion much more stable as 1.3.2 was: there
>have been many bugs fixed since that last "stable" release!
>
>I will seriously consider the suggestion.  I just feel, a RC version
>is not a final version.  What does the RC stand for?
>
>BTW: When you think the 1.4.0 will be released?
>
>Thanks!
>
>
>>
>> Simon
>> --
>> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
>> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>
>
>
>--
>Life is the only flaw in an otherwise perfect nonexistence
>    -- Schopenhauer
>
>narke
>public key at http://subkeys.pgp.net:11371 (narkewo...@gmail.com)
>
>___
>lwip-users mailing list
>lwip-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] HOWTO LwIP if NO_SYS = 1

[Bill Auerbach]

Although it's obviously for a different platform, the Altera NIOS II port
here http://lwip.wikia.com/wiki/Available_device_drivers has a sample NO_SYS
program including a WEB server.  I would think using it with your driver
should work almost as-is.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Niraj Kulkarni
Sent: Thursday, April 28, 2011 10:15 AM
To: jeffba...@gmail.com
Cc: lwip-users@nongnu.org
Subject: [lwip-users] HOWTO LwIP if NO_SYS = 1

 

Hi,

I am porting LwIP on Renesas 16-bit controller with no OS. After reading 

1.   lwip-1.4.0.rc2\doc\rawapi.txt

2.   http://lwip.wikia.com/wiki/Porting_For_Bare_Metal

3.   http://lwip.wikia.com/wiki/LwIP_with_or_without_an_operating_system

4.   http://permalink.gmane.org/gmane.network.lwip.general/9824

I have understood that in my case "NO_SYS = 1" and All applications must be
written using the   raw (or
native) API.

I have following quires:

1.   Do I have to implement etharp_tmr(), ip_reass_tmr(), tcp_tmr(), etc
using some way ( may be Hardware time of the controller).

2.   I could not understand arguments of "netif_add" function ;
specially first and last two arguments. Out of the last two functions which
one I have

to implement.

3.   Is there any code ported on any controller with LwIP on it with
NO_SYS = 1 , available for download.  

 

Regards,

Niraj

 

 



Larsen & Toubro Limited 

www.larsentoubro.com 

This Email may contain confidential or privileged information for the
intended recipient (s) If you are not the intended recipient, please do not
use or disseminate the information, notify the sender and delete it from
your system. 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Usual lwIP performance on MCU

[Bill Auerbach]

Unless we (someone in this group) comes up with a standard lwipopts.h file
and a standard UDP and/or TCP performance test program, any numbers people
post here won't have much relevance to any system.  There is a lot that can
be done in lwipopts.h to improve (or hinder) performance.

Bill

>-Original Message-
>From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
>[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On
>Behalf Of Tn
>Sent: Friday, April 22, 2011 6:38 PM
>To: lwip-users@nongnu.org
>Subject: [lwip-users] Usual lwIP performance on MCU
>
>What's your usual performance you get from TCP/IP
>stack on microcontroller?
>
>On my LM3S9B90 (Cortex M3) with 16MHz clock I managed to get 4-5MBit/s.
>Is seems to be quite slow. I'd like to hear about some reference
>results out there.
>
>Thanks,
>TN


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Print Macros

[Bill Auerbach]

A format specifier is syntactically a % followed by optional width & precision 
and the final format type.  IMO the macro should include % to keep it together. 
 But I know it will involve many many changes through practically every file in 
the lwIP code base.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org 
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf Of 
Robert
Sent: Thursday, April 14, 2011 8:23 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Print Macros

 

On Wed, 2011-04-13 at 16:17 -0700, Roger Cover wrote: 

Greetings List, 

  

My compiler does not substitute macros inside quotes. The proposed change would 
not work for me at all, since the example in the original message would result 
in a final string of "tcp_bind: bind to port %U16_F\n". 

Regards,
Roger 


My compiler tries to process the format string at compile time, so that the 
application will run faster during execution.  That is the reason it fails with 
the macros as coded now. It apparently does that scan before concatenating the 
string.  So how about this:

Code the macros like this:


#define U16_F  "%u"

Then the invocation would look like this:


LWIP_DEBUG(TCP_DEBUG,("tcb_bind: bind to part "U16_F"\n, port));

The change here is that the % sign is part of the substitution rather than 
before.  The only disadvantage I think is that there are a few cases in the 
code where a "length" of the field is specified, and those would need their own 
macros.

Robert Laughlin 

___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

RE: [lwip-users] how to fix an IP address with DHCP while being recognized with the routers?

[Bill Auerbach]

I used functions netif_set_ipaddr, netif_set_up, and dhcp_inform if I am 
setting a static IP address in my lwIP device and had DHCP compiled in but not 
started up.

If I already had a DHCP IP address and was changing to static IP, then I used 
dhcp_stop, netif_set_down, netif_set_addr and netif_set_up.

That's not to say this is necessarily the correct procedure, but in testing 
this worked well for me.

Bill

>-Original Message-
>I work on the EVK1100 with studio 2.6 and I use the program EVK1100 -
>SERVICES - LWIP 1.3.2
>with DHCP exemple.
>
>I want my EVK1100 to be recognized by router then I need to use DHCP for
>to fix IP address.
>But if I manage to change my IP address without DHCP fonction, the
>router does not
>recognize my card.
>
>Fonctions of this program can achieve what I wishes?
>
>I work around DHCP_INFORM but is it a good way?
>
>Thanks for any help.
>
>Emmanuel.



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

RE: [lwip-users] disconnect - connect delay

[Bill Auerbach]

>Did you use it in HTTP server code? When I abort the multiple
>connection in the accept callback the web browser don't load all the
>webside elements. If browser get RST flag in TCP packet it doesn't try
>to download the element again. In firebug it is shown as Abort state
>instead of "200 OK".
>
>As you can see aborting connection can't be use in HTTP protocol. Or
>maybe I'm doing something wrong.

It will work if you refuse multiple connections from *different* IP
addresses.  In the accept handler if the ip address is the same as the first
accepted connection, allow it, otherwise refuse it.  I believe this is what
you really want to do - refuse connections from different IP addresses, yes?
Below acceptedPcb is the first pcb accepted and is set to NULL when the last
connection closes.

static struct pcb *acceptedPcb;

static err_taccept(void *arg, struct tcp_pcb *pcb, err_t err)
{
if(acceptedPcb != NULL && acceptedPcb->remote_ip.addr !=
pcb->remote_ip.addr)
{
tcp_close( pcb );
return ERR_OK;
}
.
.
.
.
}

Bill


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

RE: [lwip-users] disconnect - connect delay

[Bill Auerbach]

>Did you use it in HTTP server code? When I abort the multiple
>connection in the accept callback the web browser don't load all the
>webside elements. If browser get RST flag in TCP packet it doesn't try
>to download the element again. In firebug it is shown as Abort state
>instead of "200 OK".
>
>As you can see aborting connection can't be use in HTTP protocol. Or
>maybe I'm doing something wrong.

It will work if you refuse multiple connections from *different* IP
addresses.  In the accept handler if the ip address is the same as the first
accepted connection, allow it, otherwise refuse it.  I believe this is what
you really want to do - refuse connections from different IP addresses, yes?
Below acceptedPcb is the first pcb accepted and is set to NULL when the last
connection closes.

static struct pcb *acceptedPcb;

static err_taccept(void *arg, struct tcp_pcb *pcb, err_t err)
{
if(acceptedPcb != NULL && acceptedPcb->remote_ip.addr !=
pcb->remote_ip.addr)
{
tcp_close( pcb );
return ERR_OK;
}
.
.
.
.
}

Bill


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

RE: [lwip-users] disconnect - connect delay

[Bill Auerbach]

>I think you'd be better limiting the number of connections by modifying
>the webserver to only accept one at a time rather than trying to enforce
>this at the TCP level.

I agree and have done so successfully by simply closing the multiple
connection in the accept callback.  I even use the connection to post send
back a 'Multiple Connections Refused' error response that the PC programming
picks up and can notify the user why the connection is closed.

Bill



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

RE: [lwip-users] Quickest way to catch a UDP packet?

[Bill Auerbach]

Hello,

 

Use LWIP_RAW = 1 and raw_recv to install a hook to see packets before the
stack does (in ip_input).  You can return non-0 to stop lwIP from further
processing of the packet.

 

Bill

 

From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On Behalf
Of Chen
Sent: Friday, March 18, 2011 2:05 PM
To: lwip-users@nongnu.org
Subject: [lwip-users] Quickest way to catch a UDP packet?

 

Hi all,

In my application, I have both TCP and UDP communication, lwip + freeRTOS
(AVR32 project). If I rely on the thread on freeRTOS, I guess I can see UDP
packets in the order of several ms based on the CPU loads.

I'd like to find the quickest way to pre-examine any UDP packet (I don't
care about UDP or other packets), where is the best place to hook such a
piece of codes to eaversdrop?

Any suggestion?

Thanks,

Chen

___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users