Re: [lwip-users] tcp echo example
What can I tell you... I've seen the code running fine, if it doesn't run fine on your scenario, then either your scenario is faulty or mine didn't trigger the bug. You are not supposed to have ticks and/or timing here, the stack works when a frame is received, you have to always call the stack from a single thread, no interrupts here (if it works, fine, but if it doesn't, then don't complain), and call the system timers frequently enough. Since long ago there is sys_check_timeouts() that will take care of everything, you can call it from your main loop. Make sure you are doing that. I will see if I can run the linux port later with several message sizes and check again, I've run it on a taiwanese Cortex-M3 last month and had fun watching it work as expected. -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp echo example
I've run the example on my linux port, with TCP_MSS set to 536 bytes,
connecting via telnet and sending messages from 4 to ~800 bytes.
It works as expected.
Unless there is something not exercised by the tests I've run, your
problem lies on your port or your usage. If you need further help,
please provide specific details of what you are doing. If you didn't
write the port, and your schema is not somehow like the following, I
suggest you ask for help to the guy(s) that wrote the port.
E.g.:
main()
{
lwip_init();
setipaddress
netif_add(netif0,...);
netif_set_default(netif0);
netif_set_up(netif0);
echo_init();
while(1){
ethernetif_input(netif0);
sys_check_timeouts();
}
}
ISR: fight the chip and set heyIhaveaframehere=1;
ethernetif_input(netif0)
{
if(heyIhaveaframehere){
alloc
netif-input();
}
}
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp echo example
Hi, when you say echo example, do you mean the echo example in the contrib tree or some vendor distributed (and probably modified) file ? 'cause i've run the echo example from the 1.4.1 contrib tree some weeks ago and I don't recall seeing anything strange. And btw, I don't see anything close to what you are describing in that code, and there is only one tcp_write() call in echo.c: [scaprile@Hal ~]$ grep -n tcp_write programming/lwip/contrib/apps/tcpecho_raw/echo.c 311: wr_err = tcp_write(tpcb, ptr-payload, ptr-len, 1); BTW, if you want to really test the net throughput (or at least come closer) get the netio patch: https://savannah.nongnu.org/patch/?7026 Regards -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp echo example
Il 01/08/2014 20:35, Sergio R. Caprile ha scritto: Hi, when you say echo example, do you mean the echo example in the contrib tree or some vendor distributed (and probably modified) file ? 'cause i've run the echo example from the 1.4.1 contrib tree some weeks ago and I don't recall seeing anything strange. And btw, I don't see anything close to what you are describing in that code, and there is only one tcp_write() call in echo.c: [scaprile@Hal ~]$ grep -n tcp_write programming/lwip/contrib/apps/tcpecho_raw/echo.c 311: wr_err = tcp_write(tpcb, ptr-payload, ptr-len, 1); yes, it isn't the only one directly called but if you search for echo_send() you will find it in echo_recv(), echo_poll(). echo_sent(). The code is exactly that, the port is that for LPC176x. The port is working perfectly but every echo message is sent 2 times, the 1st is correct but the second call to tcp_write() cames from the call to echo_send() inside echo_sent(). Debugging the situation I found that pbuf_free() is correctly called but the pointer to pbuf (es-p) is not NULL. So seems that the effect of the problem is quite clear but is not clear why. What I can say is that if I want to send a message, it will be copied to a pbuf and this pbuf in some way will be only enqueued to be transmitted, right? Supposing that I write 3 messages, I should call tcp_write() 3 times so at least 3 pbufs will be enqueued. Considering that messages are really sent calling tcp_output() that it is called in tcp_fasttmr() and in tcp_slowtmr() I really don't understand why inside the sent callback the pbuf pointer is checked and the message re-sent if the pointer is not null... that it is the last message enqued and this doesn't mean that it is always the 1st message that will be sent. I simply think that the call to echo_send() inside the sent callback is totally wrong . BTW, if you want to really test the net throughput (or at least come closer) get the netio patch: https://savannah.nongnu.org/patch/?7026 Regards logo * Massimo Manca*/, Micron Engineering/ via della Ferriera, 48 33170 Pordenone PN ITALIA Tel: 39 0434 1856131| Mobile: 39 349 4504979 www.micronengineering.it Twitter http://s.wisestamp.com/links?url=https%3A%2F%2Ftwitter.com%2Fmassimomanca LinkedIn http://s.wisestamp.com/links?url=http%3A%2F%2Fit.linkedin.com%2Fpub%2Fmassimo-manca%2F7%2Fa15%2F479%2F SlideShare http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2Fmicronpn Contact me: Skype micron.engineering Designed with WiseStamp - http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Daaa0e17b0c4ca423%26v%3D3.13.31%26t%3D1406923781901%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10Get yours http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Daaa0e17b0c4ca423%26v%3D3.13.31%26t%3D1406923781901%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10 --- Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus. http://www.avast.com attachment: m_manca.vcf___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp echo example
Not really. tcp_write() allocates an internal pbuf itself, but you can only send 3 times in a row if yu have enough memory, and as TCP works, there is no concept of packet and no need to call 3 times in a row. You have a sndbuf and you can send as much as you can fit inside that sndbuf for that pcb. Once your buf is filled, you can only send again once data has been sent out, acknowledged by the receiver, and so that buffer freed, and that is signalled to you via the tcp_sent() callback. The whole point of calling echo_send() from inside the callback function is that in this case the total amount of data actually sent might not equal the amount of data received (in the whole pbuf). The first call to tcp_write() sends only the first pbuf in the pbuf chain, and once this is acked, the tcp_sent() callback will try to send the remaining pbufs in the chain. A pbuf may be a chain of pbufs, linked by p-next Either you have some memory problems or I've been lucky enough to get whole data inside a single pbuf and didn't trigger the possible bug. I recall sending small packets, what are you sending ? Again, I suggest you use netio for big chunks of data. I don't have the time to build a short tcp_mss version of my linux port and try it, maybe on monday. I suggest you (besides going for netio) try with small messages, I'm sure those work OK. If they do, then check the pbuf chains, if they don't... check your port. Regards -- ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] tcp echo example
Il 01/08/2014 23:46, Sergio R. Caprile ha scritto: Not really. tcp_write() allocates an internal pbuf itself, but you can only send 3 times in a row if yu have enough memory, and as TCP works, there is no concept of packet and no need to call 3 times in a row. I mean a different thing. I said that also if I could send 3 packets calling 3 times tcp_write() there is no reason to send a message inside the sent callback because it could only resend the last message sent but if the callback is entered means that the packet was sent. Of course sending only 1 message (I mean calling tcp_write() only 1 time) there is really no reason to provide the possibility to send hte same packet another time. You have a sndbuf and you can send as much as you can fit inside that sndbuf for that pcb. Once your buf is filled, you can only send again once data has been sent out, acknowledged by the receiver, and so that buffer freed, and that is signalled to you via the tcp_sent() callback. Yes, the problem is that for me the pcb is not freed. It contains valid data, exactly the last data sent and also the pbuf pointer is not null. The whole point of calling echo_send() from inside the callback function is that in this case the total amount of data actually sent might not equal the amount of data received (in the whole pbuf). I made a test running all night... it sent more then 20 messages and received always the reply in a single message, same behavior for the messages sent. The first call to tcp_write() sends only the first pbuf in the pbuf chain, and once this is acked, the tcp_sent() callback will try to send the remaining pbufs in the chain. If I correctly understand the code a tcp_write will try to put all data of a single tcp_write() in a single pcb also if I found some documentation saying that it could fit the message in more then 1 pcb so it will fit in a pcb chain. May you know what is the maximum data size in a pcb? In my case I am sure it will fit always in a pcb because the message is shorter then 50 bytes. A pbuf may be a chain of pbufs, linked by p-next Either you have some memory problems or I've been lucky enough to get whole data inside a single pbuf and didn't trigger the possible bug. I recall sending small packets, what are you sending ? Sure, the memory problem is that the tcp_write() pcb seems to be not deallocated and also its pointer is not null, so may be more a problem related to pbuf_free(). It is correctly called after tcp_write() so it frees the user pcb, then tcp_write() should copy the data in a new pcb that will be used by tcp_output() (and sent). The pcb that is not free is the pcb used by tcp_write to send the message, I shouldn't have any control on it. My message is sprintf(szEchoMsg, Raw message %d\n, iCount); and szEchoMsg is 50 bytes length. The echo server triggers on \n so echoes line by line. Again, I suggest you use netio for big chunks of data. I don't have the time to build a short tcp_mss version of my linux port and try it, maybe on monday. I suggest you (besides going for netio) try with small messages, I'm sure those work OK. If they do, then check the pbuf chains, if they don't... check your port. I suppose that I found something like a bug because all other examples (also netio) work well with no problems. I started with tcp_echo raw example because until now I designed server applications using lwip but this time I have to write a tcp client application. Because it wasn't working I tried the ping example and it worked perfectly. Take care that my mcu is working at 120MHz, my system tick is 1 ms and the timed functions are called every 250ms (I tryed also at 125ms with no difference). Now my application seems to be working but I would test it with messages divided on several pcbs to be sure it really works well. Also in my application I didn't provide to send pcbs inside the sent callback function. Kind regards. Regards logo * Massimo Manca*/, Micron Engineering/ via della Ferriera, 48 33170 Pordenone PN ITALIA Tel: 39 0434 1856131| Mobile: 39 349 4504979 www.micronengineering.it Twitter http://s.wisestamp.com/links?url=https%3A%2F%2Ftwitter.com%2Fmassimomanca LinkedIn http://s.wisestamp.com/links?url=http%3A%2F%2Fit.linkedin.com%2Fpub%2Fmassimo-manca%2F7%2Fa15%2F479%2F SlideShare http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2Fmicronpn Contact me: Skype micron.engineering Designed with WiseStamp - http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Daaa0e17b0c4ca423%26v%3D3.13.31%26t%3D1406929657462%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10Get yours
