Update on the problem below. I added some debug code and enabled
LWIP_STATS. After letting my system run overnight (continuously polling
modbus data) it had finally failed once again. Connection attempts are
usually timing out (even connection attempts to port number with no
listening pcb). When it does connect, my system can send no data
whatsoever. My debug code indicates that the size of the data buffer I
am trying to send is 128, tcp_sndbuf() is returning 1072 (decimal), so I
call tcp_write() to send the data. It returns an error code of -1 (ERR_MEM).
lwip_stats contains the following (hexadecimal dump, values are 16 bit
little endian, first 128 bytes shown):
20FD:7C24 59 0e 8a 23 00 00 00 00 00 00 00 00 00 00 00 00 Y..#............
20FD:7C34 00 00 00 00 00 00 00 00 b3 00 f3 05 00 00 02 00 ................
20FD:7C44 00 00 00 00 f2 90 00 00 02 00 00 00 00 00 a6 0d ................
20FD:7C54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20FD:7C64 00 00 00 00 00 00 00 00 a7 18 95 1d 00 00 05 00 ................
20FD:7C74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20FD:7C84 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20FD:7C94 00 00 00 00 00 00 00 00 0c 00 a8 02 00 00 00 00 ................
Link stats are first.
xmit=0e59, and it is NOT changing.
recv=238a, and it is increasing with network traffic
fw, drop, chkerr, lenerr, memerr, rterr, protoerr, opterr, err. cachehit
are all 0
Etharp stats are next:
xmit=00b3, and it is NOT changing
recv=05f3, and it is increasing with network traffic
fw=0
drop=0002 (why should anything be dropped?)
chkerr, lenerr are 0
memerr=0da6, this is very bad! Where did all my memory go?
rterr, protoerr, opterr, err. cachehit are all 0
It seems I have a memory error of some kind, but I don't know where to
look. Also, two things that I don't understand:
1) How can tcp_sndbuf() return 1072 (decimal), yet when I attempt to
write 128 bytes with tcp_write() it returns ERR_MEM?
2) Why does my system run perfectly for many hours of continuous modbus
data polling, and then suddenly get into this strange out-of-memory problem?
Any suggestions would be appreciated.
Keith Rubow
On 5/16/2018 11:07 AM, Keith Rubow wrote:
I am using lwip 2.0.3, NO_SYS=1, callback api. I have an application
that works for a while, then gets into a mode where it seems to be
unable to send and data over a TCP connection. I am listening for
incoming connections on two different ports. One port will accept only
1 connection at a time, the other can accept up to 5 connections. I
have the following on my lwipopts.h file:
#define MEMP_NUM_TCP_PCB_LISTEN 2
#define MEMP_NUM_TCP_PCB 6
#define TCP_WND (2*TCP_MSS)
I am using the defaults in opt.h for PBUF_POOL_SIZE (16) and MEM_SIZE
(1600).
For a while, everything works fine. Then suddenly everything seems to
break down and my application cannot send data. Further testing showed
that my application could send only very short blocks of data at a
time (14 bytes or less). Trying to send 15 bytes or more would not work.
My code for sending data is as follows (simplified):
if (tcp_sndbuf(mypcb) >= mydatasize) {
if (tcp_write(mypcb, mybuffer, mydatasize, TCP_WRITE_FLAG_COPY) ==
ERR_OK) {
tcp_output(mypcb);
}
}
The data I send is never more than 128 bytes (or 56 bytes on the port
that accepts 5 connections). I have determined that when my
application fails I have mydatasize=128, and tcp_sndbuf() returns
1072, but then tcp_write() fails. I have not enabled LWIP_STATS yet
(but I probably will later today).
I'm sorry I can't tell you what error code is being returned by
tcp_write(). I need to add more debug code in my program, and it takes
hours to get it into this failure mode. But it seems strange that
tcp_sndbuf() tells me I have plenty of space available, but yet I
cannot write my little 128 byte buffer of data. Could it be that the
1600 byte memory pool is becoming so fragmented that lwip cannot
allocate a sufficiently large block of memory?
Any Ideas would be appreciated. I will try to collect more data to
localize the problem, but it takes time.
Keith Rubow
_______________________________________________
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