The lwip stack stops responding completely when an IPscan on the subnet is
performed. This spews out a series of ARP requests.
It looks like the Ethernet MAC stops generating interrupts because
ethernetif_input() is no longer called.
lwIPstats() reports an ETHARP drop and lenerr which makes me
I'm having an issue where the lwIP stack stops responding completely after an
IPscan on the subnet is performed. This spews out a rapid series of ARP
requests which, I assume, is flooding the stack's ARP handler. It could be
something else causing, but I don't know what yet.
The stack stops res
Subject: Re: SV: [lwip-users] TCP payload is doubled
David Shmelzer wrote:
> I'm still confused as to why the the window size is decreasing in the
> first place in 1.3.1 and not in 1.3.0. Isn't that causing the silly
> window syndrome? The lwIP server is processing the packets
I'm still confused as to why the the window size is decreasing in the
first place in 1.3.1 and not in 1.3.0. Isn't that causing the silly
window syndrome? The lwIP server is processing the packets immediately
via the callback API so the window should not be decreasing.
Dave
-Original Message
ers] Re: TCP payload is doubled (Hans-Joerg)
David Shmelzer wrote:
> Thanks Hans.
> I was indeed calling tcp_recvd.
> Problem was my TCP_WND == TCP_MSS.
> I doubled TCP_WND and it now works.
>
David, did it totally stop working or was it just slow (high latencies)?
The reason I a
message with subject or body 'help' to You can
> reach the person managing the list at When replying, please edit your
> Subject line so it is more specific than "Re: Contents of lwip-users
> digest..."
> Today's Topics:
> 1. RE: TCP payload is doubled (D
Mine works now too.
I was also having the same problem where the window size kept decreasing.
Thanks all.
Dave
-Original Message-
From: lwip-users-bounces+daves=pmdcorp@nongnu.org
[mailto:lwip-users-bounces+daves=pmdcorp@nongnu.org] On Behalf Of Jan Wester
Sent: Tuesday, October
u.org] För David Shmelzer
Skickat: den 15 oktober 2009 21:56
Till: Mailing list for lwIP users
Ämne: RE: [lwip-users] TCP payload is doubled
I did a wireshark capture and the window size from lwip keeps decreasing by the
packet length received by lwip for each transaction. When it finally decrease
I did a wireshark capture and the window size from lwip keeps decreasing
by the packet length received by lwip for each transaction. When it
finally decreases to less than the packet size my s/w hiccups because it
expects a full packet. So this problem exposed a flaw in my software. Is
anyone else
u.org/bugs/?27504
There is a patch attached to the bug report, and Simon checked it into
LWIP a couple of days ago. If you can get CVS-head or apply that patch
to your existing code it will hopefully fix the problem.
- Original Message -
From: "David Shmelzer"
To: "Mailing
Occasionally, the payload in my TCP return packet sent from lwip is more
bytes than I'm expecting.
It looks like it may be concatenating two copies of the payload.
When it happens, it enters this section of tcp_enqueue():
/* If there is room in the last pbuf on the unsent queue,
chain the firs
return NULL;
}
-Original Message-
From: lwip-users-bounces+daves=pmdcorp@nongnu.org
[mailto:lwip-users-bounces+daves=pmdcorp@nongnu.org] On Behalf Of
Kieran Mansley
Sent: Thursday, October 08, 2009 4:28 AM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] conn->er
s
Subject: Re: [lwip-users] conn->err = ERR_CLSD in api_lib.c
On Tue, 2009-10-06 at 17:32 -0400, David Shmelzer wrote:
> I'm calling netconn_recv() in a loop in another thread with a zero
timeout.
> help?
Does that mean you're using the same connection from two different
threa
-users-bounces+daves=pmdcorp@nongnu.org] On Behalf Of
Kieran Mansley
Sent: Wednesday, October 07, 2009 4:09 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] conn->err = ERR_CLSD in api_lib.c
On Tue, 2009-10-06 at 17:32 -0400, David Shmelzer wrote:
> I'm calling netconn_rec
I upgraded to 1.3.1 and it fixed the zero timeout problem I was having. Thanks.
However, I'm still getting a peculiar issue where netconn_recv erroneously sets
conn->err to ERR_CLSD after 3 or so packets in the following section:
/* If we are closed, we indicate that we no longer wish to use
Simon, or whoever,
I want to call netconn_recv without blocking to check for a message.
In a previous message you said:
"If you are using lwIP 1.3.0 or newer (CVS), to achieve what you want,
have a look into the netconn_recv() function: when you have
LWIP_SO_RCVTIMEO defined to 1, sys_arch_mbox_
t implementation is not ideal and subject to change
in lwIP 1.4.0. With the intended solution (having a function like
get_time()), your approach would have worked ;-)
Simon
David Shmelzer wrote:
> My application requires that netconn_recv() be non-blocking and to
> return immediately of t
My application requires that netconn_recv() be non-blocking and to
return immediately of there is no message waiting.
So I modified sys_arch.c to convert small timeout values to zero for the
queue wait.
But I run into problems if the xQueueReceive timeout is 0. The TCP
connection closes after ~5 n
r lwIP users
> Message-ID: <4984cdc9.7000...@ecoscentric.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> David Shmelzer wrote:
> > Thanks for pointing me to the example in lwIP.pdf
> >
> > I copied the example from the lwIP.pdf verbatim in
Thanks for pointing me to the example in lwIP.pdf
I copied the example from the lwIP.pdf verbatim into a test function
that I execute twice. The second time through I get an exception in
netconn_bind().
The exception occurs in the first 'for' loop in tcp_bind().
The cause of the exception is cpc
Hi,
I'm getting a processor exception in the second call to netconn_bind.
Here is the simplified version of the code that reproduces the problem:
conn=netconn_new( NETCONN_TCP );
netconn_bind(conn, NULL, portnum);
netconn_listen( conn );
netconn_delete(conn);
conn=netconn_new( NETCONN_TC
Thanks all for your reply.
I should have mention that I did read the 1.3.0 release notes.
I just found it odd that I had to set the ETH_PAD_SIZE to 2 to get it to
work in 1.3.0.
It was set to 0 in the 1.2.0 version. And as far as I know the STR9
should be able to handle all word alignments.
Maybe
I think I may have fixed my problem by setting ETH_PAD_SIZE to 2.
I say 'I think' because it doesn't seem like the right solution as my
implementation with 1.2.0 had a PAD size of 0.
While I was stepping through the 1.3.0 code I noticed the low word of
the ipaddr was garbage if I stepped through t
Hi,
I just upgraded to lwIP 1.3.0 from 1.2.0 and I'm now getting "ip_input:
packet not for us." from ip.c. I'm using the raw api and my tcp_accept()
callback function no longer gets called.
Did I miss something in the upgrade?
Thanks,
Dave
___
lwip-u
D: <1229010618.4586.9.ca...@moonstone.uk.level5networks.com>
> Content-Type: text/plain
>
> On Thu, 2008-12-11 at 10:18 -0500, David Shmelzer wrote:
>
> > Any ideas how the used value of TCP_MSG went negative?
>
> At a guess, something got freed twice.
>
> Kier
Hi,
I have a problem where lwip stops responding after an hour or so and the
STATS show the following:
MEM TCP_MSG
avail: 8
used: 65535
max: 3
err: 0
also
PBUF
avail: 10
used: 1
max: 3
err: 7
Any ideas how the used value of TCP_MSG went negative?
The network traffic that lwip has to respond
I'm attempting to call netconn_new( NETCONN_UDP ) to open a UDP
connection from the same thread as lwip and it hangs at
sys_mbox_fetch(). In other words, in a packet I send to lwip I tell it
to open a UDP connection. Either that's just not allowed or I'm doing
something wrong. I can open the connec
27 matches
Mail list logo