Sadly, today I've catched lwip_stats when device was in 'natural hangup.
There were no errors in lwip_stats:
{link = {xmit = 0, recv = 0, fw = 0, drop = 0, chkerr = 0, lenerr = 0,
memerr = 0, rterr = 0, proterr = 0, opterr = 0, err = 0, cachehit = 0},
etharp = {xmit = 6, recv = 223, fw = 0, drop
In lwip_stats.tcp I see (non zero values):
- xmit 2478
- recv 2341
but in 'sys.mbox' section:
- used 21
- max 22
- err782
Could you tell me if you see anything incorrect in my opts (maybe any other
opts needed)?
#define TCPIP_MBOX_SIZE 64
#define
Tomek wrote:
but in 'sys.mbox' section:
- used 21
- max 22
- err 782
The meaning of that stats depends on your port. I don't know if it means mbox
full wehn trying to put something in the mbox or no more mboxes left when
creating a new mbox (every socket/netconn needs one).
In the latter
Hi,
I have some issues with device based on FreeRTOS (stm32F4 port) and lwIP
1.4.1 stack. There is parallel server and client functionality.
Case similiar to one described here:
http://lwip.100.n7.nabble.com/SYN-flood-attack-lwip-crash-td17632.html, but
with one significant difference: I don't
Tomek wrote:
Case similiar to one described here:
http://lwip.100.n7.nabble.com/SYN-flood-attack-lwip-crash-td17632.html, but
with one significant difference: I don't use backlog.
Does that mean you are absolutely sure that TCP_LISTEN_BACKLOG is set to 0?
Simon
Only one TCP_LISTEN_BACKLOG define in opt.h:
#ifndef TCP_LISTEN_BACKLOG
#define TCP_LISTEN_BACKLOG 0
#endif
Editor suggests that at this moment TCP_LISTEN_BACKLOG is not defined, so I
am as sure as I can.
--
View this message in context:
Tomek wrote:
Editor suggests that at this moment TCP_LISTEN_BACKLOG is not defined, so I
am as sure as I can.
Alright. That and the SYN/ACK/RST sequence you posted suggests that somewhere
in your application, the connection is dropped. Maybe because of some kind of
resource shortage. I'd try
I do not exclude possibility that there is something wrong in my code, but
when I have tried to debug server's task, I've noticed that lwip_accept is
called properly but never returns back (I mean: generally it works, but
after some time lwip_accept won't return, so I can't call lwip_read).
Is it
Tomek wrote:
Is it posibble under any circumstances for lwip_accept to drop incoming
connection?
Yes: if it ran out of memory.
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
In such a case, should it return or stay in lwip_accept (as described above)?
--
View this message in context:
http://lwip.100.n7.nabble.com/lwIP-1-4-1-server-s-SYN-flood-hang-no-backlog-tp23116p23127.html
Sent from the lwip-users mailing list archive at Nabble.com.
10 matches
Mail list logo
