Hey all,
a slightly off-topic question that kept stirring in my head:
Why do nearly all people on this list seem to use the raw API instead of
netconn or sockets?
Performance-gain? Flexibility?
regards,
Fabian___
lwip-users mailing list
Why do nearly all people on this list seem to use the raw API instead of
netconn or sockets?
Performance-gain? Flexibility?
Maybe the ones using netconn or socket API don't have any problems? :-)
But really, I haven't used the netconn API so far, but the socket API solves
many lwIP-related
Why do nearly all people on this list seem to use the raw API instead of
netconn or sockets?
Performance-gain? Flexibility?
I'm using the raw API to implement my own API which is specified by
others. It is really useful and provide room for hard tweaking
(reduction on non-blocking case).
2009/7/29 JM hon...@yahoo.com:
while(data 0)
{
data = data - (int)current_pbuf-len;
tcp_recved(pcb, current_pbuf-len);
next_pbuf = current_pbuf-next;
pbuf_free(current_pbuf);
current_pbuf = next_pbuf;
}
There is no need to walk the pbuf
2009/7/29 Fabian Koch fabian.k...@de.abb.com:
Why do nearly all people on this list seem to use the raw API instead of
netconn or sockets?
Performance-gain? Flexibility?
When there's no OS, the raw API is the only option. Besides, the raw
API should need less RAM.
- mike
Hi all,
My firmware is made of a bootloader and an application. Only one is
running at a time but both start by initializing the lwip stack and
launching a DHCP discovery in order to get an IP address.
In the case of my application is running an IP address is assigned
to my
Baptiste Chaboud-crousaz a écrit :
Hi all,
My firmware is made of a bootloader and an application. Only one is
running at a time but both start by initializing the lwip stack and
launching a DHCP discovery in order to get an IP address.
In the case of my application is running an IP
On Tue, 2009-07-28 at 15:11 -0700, Chris_S wrote:
Well it's still running, still serving pages, so things look good.
Kieran said that lwIP was not closing the connections, like the other end
was. So does that mean it is still doing something wrong? I've attached
the PCAP file.
I'll
Besides, the raw API should need less RAM.
- mike
Bingo. That's my reason. If you want high performance on an embedded
system with limited RAM, lwIP-raw is about the best choice. In fact the
choices are very few. I looked at and tried several different TCP/IP stacks
that cost real money,
Still looks like the lwIP side is not closing its end of the
connections. There are no FIN packets coming from 192.168.2.1. Most
likely this is due to the stack waiting for the application to call
tcp_close().
This sounds like there is something missing in the HTTPd I'm using. I will
look
Hi,
I know that a DHCP server tends to always re-assign the same IP
address to a MAC address. But it is not compulsory.
Moreover, what happens when several DHCP servers are listening on
the network. When my bootloader sends its DHCP discovery (a DHCP
server has already offered an
Wouldn't it be easier for the main application to skip the DHCP part
and just assign the IP address that the bootloader obtained?
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
On Wed, 2009-07-29 at 02:20 -0700, Chris_S wrote:
Still looks like the lwIP side is not closing its end of the
connections. There are no FIN packets coming from 192.168.2.1. Most
likely this is due to the stack waiting for the application to call
tcp_close().
This sounds like there is
Hi,
Yes my bootloader can assign its IP with which the application
obtained. But I want that the bootloader is still able to renew the
DHCP lease (my bootloader should continue to work in DHCP mode). I
think that dhcp_start must be called for that purpose; but this
function always
Still looks like the lwIP side is not closing its end of the
connections. There are no FIN packets coming from 192.168.2.1. Most
likely this is due to the stack waiting for the application to call
tcp_close().
Well I'm confused now. I checked this out, and tcp_close() is being
On Wed, 2009-07-29 at 04:01 -0700, Chris_S wrote:
I turned on all the LWIP TCP debug options,
here is what the debug strs are for one page refresh,
HTML and GIF files sent.
That shows the stack sending the FIN. Can you get a packet capture and
a full debug log from the same connection so we
Here's another one. It's the same as before - no FIN shown.
Where do you see a FIN being sent in the debug log?
I just see an ACK being sent.
Look below. lwIP gets a FIN, but sends back an ACK.
That's what debug strs show, and that's what Wireshark shows.
.
CONtcp_receive: received FIN.
The way I read this:
- on 1st HTML, lwIP gets [FIN,ACK]
- and sends back [SYN,ACK]
- on 2nd GIF, lwIP gets [FIN,ACK]
- and sends back [ACK]
Chris.
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
lwip-users-bounces+fabian.koch=de.abb@nongnu.org wrote on 29.07.2009
13:16:28:
Here's another one. It's the same as before - no FIN shown.
Where do you see a FIN being sent in the debug log?
I just see an ACK being sent.
Look below. lwIP gets a FIN, but sends back an ACK.
That's
On Wed, 2009-07-29 at 04:16 -0700, Chris_S wrote:
Here's another one. It's the same as before - no FIN shown.
Where do you see a FIN being sent in the debug log?
I just see an ACK being sent.
Look below. lwIP gets a FIN, but sends back an ACK.
That's what debug strs show, and that's
On Wed, 2009-07-29 at 04:16 -0700, Chris_S wrote:
Here's another one. It's the same as before - no FIN shown.
Where do you see a FIN being sent in the debug log?
I just see an ACK being sent.
CONClosing connection 0x400072f4
CONtcp_close: closing in CONState: CONESTABLISHED
On Wed, 2009-07-29 at 13:24 +0200, Fabian Koch wrote:
lwip-users-bounces+fabian.koch=de.abb@nongnu.org wrote on
29.07.2009 13:16:28:
Here's another one. It's the same as before - no FIN shown.
Where do you see a FIN being sent in the debug log?
I just see an ACK being sent.
Yes I saw that tcp_enqueue after the HTML that had flags=1 [FIN]
But what seems odd to me, where is the trailing tcp_enqueue sequence after
the GIF? I don't see one. Instead this tcp_pcb_purge is listed and then
the [ACK] spits out.
CONTCP connection closed 3989 - 80.
CONtcp_pcb_purge
On Wed, 2009-07-29 at 04:33 -0700, Chris_S wrote:
Here ya go...fresh off the grill...
Great, thanks. This shows that the FIN flag is getting lost somewhere
after the packet is enqueued, but I've looked at the code and can't see
an obvious problem. I'll need to look in more depth, and set up a
On Wed, 2009-07-29 at 13:00 +0100, Kieran Mansley wrote:
On Wed, 2009-07-29 at 04:33 -0700, Chris_S wrote:
Here ya go...fresh off the grill...
Great, thanks. This shows that the FIN flag is getting lost somewhere
after the packet is enqueued, but I've looked at the code and can't see
an
Are you sure? All I see in wireshark is [ACK] listed, where is the [FIN]
you see?
Is this a bug in wireshark?
Chris.
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
Hey guys,
I'm starting to use the Loopback connection at the moment and am running
into what appears to be race conditions.
(Still using 1.3.0 and in the process of looking at 1.3.1)
Now in 1.3.0 in loopif.c it is said that loopif_output() copies the pbuf
and calls netif-input() with it. And
Dear Group :
I found a strange problem about gratuitous arp .With the same code, my
udp-client send udp packets successfully sometimes ,but ,it would send
failed sometimes.
After i check the Ethereal ,i found when it send successfully ,the udp
packets always be sent before the PC's three
the_gadfly wrote:
ps: kieran ,simon ,i think i have to use the old version lwip 0.7.1 .because
it's diffcult to me to port 1.3.0to nios .I think it will be ok with
0.7.0 ,couse udp_echo runs ok in my board .
That's sad because now, we cannot help you: chances are very *very* high
you
29 matches
Mail list logo
