Mon 23 Apr 2012 10:04:24 AM UTC, original submission:
Hello,
With MEM_LIBC_MALLOC = 0, when doing multiples TCP connexions before UDP connexions,
UDP netconn_recv returns a pbuf at always the same address,
and data associated is wrong:
I have (UDP DATA FIELD, with WireShark):
E..2..
................
.....c*** DONNEE
DE TEST ***
Instead of (UDP DATA FIELD, with WireShark):
*** DO
NNEE DE TEST ***
Output with MEM_LIBC_MALLOC = 0:
CAS1: Connexion TCP acceptée par la pile LWIP sur le port 1102!
CAS1: TEST OK: Donnée TCP reçue sur port 1102: *** DONNEE DE TEST ***!
CAS1: TEST OK: Acquittement reçu: ACK!!
CAS1: Fin de la connexion!
CAS2: Connexion TCP acceptée par la machine UNIX sur le port 1202.
CAS2: TEST OK: Donnée TCP reçue sur port 1202: *** DONNEE DE TEST ***!
CAS2: TEST OK: Acquittement reçu: ACK!!
CAS2: Fin de la connexion!
CAS3: TEST OK: Donnée UDP reçue sur port 1102: E! ===> BUG
CAS3: TEST OK: Acquittement reçu: E! ===> BUG (same pbuf, but another netconn_recv call)
CAS4: TEST OK: Donnée UDP reçue sur port 1202: E! ===> BUG (same pbuf, but another netconn_recv call)
CAS4: TEST OK: Acquittement reçu: E! ===> BUG (same pbuf, but another netconn_recv call)
CAS1: Connexion TCP acceptée par la pile LWIP sur le port 1102!
CAS1: TEST OK: Donnée TCP reçue sur port 1102: *** DONNEE DE TEST ***! ==> pbuf is OK for netconn_recv TCP!
CAS1: TEST OK: Acquittement reçu: ACK!!
CAS1: Fin de la connexion!
etc...
Note that if I don't use TCP connexions (only CAS3 and CAS4), the problem is not present.
It's looks like the problem occurs when a TCP netconn is closed on a side when TCP netconn is receiving in the other size.
With MEM_LIBC_MALLOC = 1, no problem found.
Sorry for my english ;)
|