Hello, thank you all for your work! I've just upgraded to 2.0.3.
One question: do you plan to release the changes currently underway in
head revision soon?
Thank you again
Enrico
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nong
Dear Sergio,
On 18/11/2015 15:42, Sergio R. Caprile wrote:
I see wrong TCP checksums on your client side, in both capture files;
but that is common when capturing on the same machine and it has hw
checksum offloading
True, the TCP checksum check option is disabled (by default?) on my
Wireshark.
Dear Sergio,
I agree you can't see any problem from the logs, because in theory, that
401 header should be followed (at least in my case) by an HTTP message
body, so an RST from the server would be expected. This somewhat "hides"
the issue I'm trying to point out.
The TCP stack sends RST *"ins
Dear Simon,
On 11/11/2015 15:25, Simon Goldschmidt wrote:
Enrico Murador wrote:
Update: now I've found why Chrome sends the FIN+ACK after the header
(also after I added the Content-Length field to that header). Server was
telling the client that reply was in HTTP 1.0, and Chrome doesn't take
ca
Update: now I've found why Chrome sends the FIN+ACK after the header
(also after I added the Content-Length field to that header). Server was
telling the client that reply was in HTTP 1.0, and Chrome doesn't take
care of the Content-Length field unless reply is in HTTP 1.1 (and maybe
this is co
Dear Colin,
If I can add one possible cause to the list, maybe your netif driver ran
out of receive buffers. This could happen e.g. if you advertised a too
big TCP receive window. To check this, maybe you can place a breakpoint
on your low level driver at the code point (if you already have on
...and if it could help (and if I'm not wrong) that packet was correctly
retransmitted (packet 188), so maybe packet 167 has effectively been
altered after creation.
On 09/11/2015 10:29, Enrico Murador - Research & Development - CET wrote:
Hi,
I gave only a quick look at the log...
Hi,
I gave only a quick look at the log... I stopped at packet 167, that is
a malformed part of a TCP ECHO response sent by Xilinx board. This
message has some fields not OK: Ethernet frame type, IP version field,
and an IP service field. All of these are located in a 32bit word
starting at 0x
An update (please read previous post for details):
The issue seems to be only in TCP part.
From Wireshark log, we can see that the client asks for a page and the
first message in reply is not malformed as I thought, but simply the
header part of the HTTP 401 "Unauthorized" page I've put on fil
Dear Sergio and Simon,
Well, first of all, in my opinion it would be great if the HTTP server
from contrib and the Sergio's fork could "re-converge" into one. Sergio
added some useful features, and on the other hand community code gets
debug, test and improvements from a lot of people. Still m
Dear Simon,
On 02/11/2015 15:03, Simon Goldschmidt wrote:
Enrico Murador wrote:
[..]
If I'm not wrong, lwIP TCP takes care of the presence of a FIN (for the current
receive window calculation)
on line 468 of tcp_in.c file (hoping you haven't changed the file in the last
few days), on tcp_inp
On 02/11/2015 13:46, Sergio R. Caprile wrote:
There are two HTTP servers on the contrib tree.
Which one are you using ? RAW API or ?
Raw API.
The webserver worked more than OK the last time I checked. If you
modified it and it doesn't work, common sense dictates you rollback and
examine if th
Dear Sirs,
I'm using lwIP from head revision, together with semi-stock HTTP server
from contrib head. I've modified it to add basic authentication
capabilities, although I think my patch should not be related with the
issue.
And please note I'm not so confident with TCP window calculations, so
Dear Sergio,
On 15/10/2015 00:03, Sergio R. Caprile wrote:
Well, I'm by no means even close to an expert, but afaik that certainly
depends on how you configure lwip.
PBUF_RAM is a single consecutive chunk of RAM for a pbuf, taken from the
heap.
PBUF_POOL is a pbuf which is itself a chain of pbuf
Dear Sergio,
GMAC is Atmel stuff, of course.
It seems to me that in the Atmel application note, deduction of MEM_SIZE
meaning is wrong.
So if someone aware of lwIP memory internals can confirm it, we can tell
Atmel to correct that app note... before using it for improving lwIP
documentation ;-)
me (the product ships soon) I'll be able to
spend some more time on this issue. I'm just glad to get it out there
and let others know it's happening.
__
Steve
.
On 10/14/2015 3:22 AM, Enrico Murador - Research & Development - CET
wrote:
Hi Stephen,
Maybe your workaround is not
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 Atme
Hi Stephen,
Maybe your workaround is not a safe way to overcome the problem: at that
point the pcb chain is already corrupted (and probably unrecoverable?).
What compiler/toolchain are you using?
Enrico
On 13/10/2015 11:48, Sylvain Rochet wrote:
Hi Stephen,
On Tue, Oct 13, 2015 at 10:15:42A
Hi Kieran,
Thank you very much for all your work and support!
Regards
Enrico
On 07/06/2013 20:27, Kieran Mansley wrote:
Hi lwIP folks,
It's been many months now since I've had the time I'd like to devote to lwIP
and my increasing work commitments and a growing family mean I can't see it
gett
As Simon said, if checksum calculation is the most time consuming task
in lwIP,
maybe without optimization the ethernet driver is fast enough to never
see more
than one packet at a time; could it be that only with optimization the
driver has to
handle more than one packet in the DMA queue, and i
Dear wurzel,
thank you for the clarification.
On 09/09/2011 23.08, wurzel wrote:
As an aside, typically when IP addresses are changing or moving,
it's common to do a "gratuitious ARP" so that ARP tables are refreshed
with the new data.
Does anybody know if LWIP does this by itself after netif_s
Dear Kyle,
For changing IP address "on the fly", I call netif_set_addr()
passing the new ip address to my existing network interface, keeping
listening pcbs (TCP in my case) running.
By looking at the code, it seems that the functions called by
netif_set_addr() do so
Dear Kieran,
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
migh
Dear Kieran,
(1) 500 bytes is a very small window. Please make sure you
set it to be at least 2*MSS to avoid very poor TCP performance;
This is ok, as my application (luckily!) requires a very small MSS; I
have set
the TCP window as 2 * MSS obtaining a window of about 620 bytes.
(2) if you h
Hi all,
I'm using the callback API's of LWIP, with a network interface based on
the Coldfire MCF5223x driver.
The Coldfire interface is DMA based, and the driver pre-allocates a
number of pbufs from the pool that will be "filled" by DMA.
the maximum number of buffers that my interface can alloc
Dear Kieran,
Thank you for your reply.
Can I use SO_REUSEADDR on listening PCBs without compromising
reliability, or it is "safer" to wait?
I think you'll be fine setting SO_REUSEADDR.
I've seen that SO_REUSEADDR flag is inerithed from listen pcb to
connection pcb;
Do you think it should be
Hi all,
I'm writing a TCP/UDP server that should allow the user to change the
TCP/UDP listening port number,
but I'm not sure what is the best way to do this. I think I have to
close the listening pcb bound to the "old" port number, create a new
listen PCB
and bind the "new" port number to it.
This is all a bit of an API violation, so I wouldn't do it that way.
Ok. I placed these "checks" since my first tries with lwip, after I
found that I was trying to
close a pcb that was already deallocated... All the code for catching
the pcb closure
was already there, but maybe there was some
Hi all,
On my application (TCP-server based with callback API) I need to limit
the number of TCP connections in this way:
the application keeps a list of connection information structures of
limited size; when a client requests a connection,
the accept callback searches the list for an empty
Thank you for your tips, I think I'll make something similar...
Enrico
On 13/05/2011 20.25, Bill Auerbach wrote:
> I don't want to be picky, but this is
potentially
confusing to beginners: it should be named
Ok, now it's very clear and I have a couple of options to try...
Thank you all for your support!
Enrico
On 13/05/2011 11.54, Simon Goldschmidt wrote:
Kieran Mansley wrote:
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 fin
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
Hi all,
I'm using LWIP with TCP and callback API.
I'm writing code to parse a sequence of messages, sent serially to my
board and embedded into one (or more) TCP packets.
It could be useful to me, when processing received data into receive
callback function, to parse only the complete
messages
Dear Simon,
You don't need to define LWIP_PLATFORM_ASSERT to fatal when
LWIP_NOASSERT is defined: just define it to nothing to ensure no code
gets built. Aside from that, the definition of LWIP_ERROR is purposely
surrounded with "#ifndef" so that you are free to define it to
"if(!expression)
ut LWIP_ERROR "calls" directly LWIP_PLATFORM_ASSERT that is (and
remains) defined from the custom application...
Thanks
Enrico
On 10/05/2011 15.45, Simon Goldschmidt wrote:
Enrico Murador - Research& Development - CET wrote:
(maybe LWIP_ERROR could be "fatal" only if LWIP_NOASS
Hi all,
On LWIP_ERROR(message, expression, handler) macro, if "expression" is
false, "message" is printed using
LWIP_PLATFORM_ASSERT (that, as described in sys_arch.txt, should be a
never-returning call), so the
subsequent call to "handler" seems useless.
If the LWIP_ERROR call has not to be
Dear Kieran,
Thank you... now (maybe) I got the point and I think I'm a little more
confident with TCP.
- But now, why the device repeats (with packet 10687) the data from
byte 27857? Because it has not received an acknowledgment for that
packet
That retransmission is a little confusing. You
Dear Kieran,
Thank you for your support.
We was already considering UDP as a base for communication on other
devices in development,
maybe we will "switch back" to UDP also on this device!
Regarding the handshake issue, I think the phrase I wrote yesterday
Thank you Kieran!
On Tue, 2011-05-03 at 15:17 +0200, Enrico Murador - Research &
Development - CET wrote:
Can someone take a look and tell me if the described situation could
be normal in case of packet collisions, or if there is effectively an
i
the device that causes problems has address 192.168.6.112.
(the rows I've previously posted are those filtered with "ip.addr eq
192.168.6.112",
toward the end of the file)
Thanks
Enrico
On 03/05/2011 21.48, goldsi...@gmx.de wrote:
Enrico Murador - Research & Development - CET w
Dear Kieran,
Is there a way to send attachments to this mailing list?
Thanks
Enrico
On 03/05/2011 15.29, Kieran Mansley wrote:
On Tue, 2011-05-03 at 15:17 +0200, Enrico Murador - Research &
Development - CET wrote:
Can som
Hi all,
I'm currently using Lwip 1.4.rc2, but the issue I will describe was
present also in 1.3.2.
I noticed a strange behaviour when one (or more?) packet is lost (in my
case, by "induced" collisions)
during a communication between the software on the (linux-based) PC and
my custom board ru
42 matches
Mail list logo
