TCP problems using pppos on stm32

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

TCP problems using pppos on stm32

Roman
Hello everyone,
I have a problem with lwip when I send data via sockets. After a random period of time, the transmission stops. My configuration: stm32f417, FreeRTOS V8.2.3, lwIP V2.0.2.
A piece of the log where I think the problem is displayed below:
============================LOG============================
tcp_out.c:1046) tcp_output: nothing to send (0)
(tcp_out.c:1054) tcp_output: snd_wnd 14600, cwnd 30612, wnd 14600, seg == NULL, ack 15221
(pppos.c:474) pppos_input[0]: got 1 bytes
(pppos.c:474) pppos_input[0]: got 37 bytes
(pppos.c:474) pppos_input[0]: got 12 bytes
(ppp.c:874) ppp_input[0]: ip in pbuf len=45
(tcp_in.c:329) +-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags
(tcp_in.c:331) -+-+-+-+-+-+-+-+-+-+-+-+-+-+
(tcp_out.c:1046) tcp_output: nothing to send (0)
(tcp_out.c:1054) tcp_output: snd_wnd 14600, cwnd 30612, wnd 14600, seg == NULL, ack 15221
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:650) tcp_write: queueing 15221:15252
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 30612, wnd 14600, effwnd 31, seq 15221, ack 15221
(tcp_out.c:1105) tcp_output: snd_wnd 14600, cwnd 30612, wnd 14600, effwnd 31, seq 15221, ack 15221, i 0
(tcp_out.c:1266) tcp_output_segment: 15221:15252
(pppos.c:294) pppos_netif_output[0]: proto=0x21, len = 71
(pppos.c:474) pppos_input[0]: got 2 bytes
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:650) tcp_write: queueing 15252:15283
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 30612, wnd 14600, effwnd 62, seq 15252, ack 15221
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 30612, wnd 14600, effwnd 62, seq 15252, ack 15221
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 30612, wnd 14600, effwnd 93, seq 15252, ack 15221
(tcp.c:1053) tcp_slowtmr: cwnd 1360 ssthresh 7300
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 31, seq 15221, ack 15221
(tcp_out.c:1105) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 31, seq 15221, ack 15221, i 0
(tcp_out.c:1266) tcp_output_segment: 15221:15252
(pppos.c:294) pppos_netif_output[0]: proto=0x21, len = 71
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 93, seq 15252, ack 15221
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 124, seq 15252, ack 15221
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 155, seq 15252, ack 15221
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 186, seq 15252, ack 15221
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 186, seq 15252, ack 15221
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 217, seq 15252, ack 15221
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 217, seq 15252, ack 15221
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 248, seq 15252, ack 15221
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 279, seq 15252, ack 15221
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 310, seq 15252, ack 15221
(tcp.c:1053) tcp_slowtmr: cwnd 1360 ssthresh 2720
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 31, seq 15221, ack 15221
(tcp_out.c:1105) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 31, seq 15221, ack 15221, i 0
(tcp_out.c:1266) tcp_output_segment: 15221:15252
(pppos.c:294) pppos_netif_output[0]: proto=0x21, len = 71
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 310, seq 15252, ack 15221
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 310, seq 15252, ack 15221
(tcp_out.c:397) tcp_write(pcb=0x2001d290, data=0x2000810e, len=31, apiflags=1)
(tcp_out.c:1061) tcp_output: snd_wnd 14600, cwnd 1360, wnd 1360, effwnd 341, seq 15252, ack 15221
============================LOG============================

Full log and lwip configuration in attached files. I'm new to lwip and if you need any more information let me know.
Regards, Roman.
lwipopts.h
log.txt
Reply | Threaded
Open this post in threaded view
|

Re: TCP problems using pppos on stm32

Roman
Hello again,
I think the problem may be in my modem driver. Maybe someone can check
Regards, Roman
Reply | Threaded
Open this post in threaded view
|

Re: TCP problems using pppos on stm32

Sylvain Rochet
Hi Roman,

On Thu, Jul 20, 2017 at 11:29:48PM -0700, Roman wrote:
> Hello again,
> I think the problem may be in  my modem driver
> <http://lwip.100.n7.nabble.com/file/n30206/modem.c>  . Maybe someone can
> check
> Regards, Roman

There is at least one obvious mistake here, but I'm pretty sure that's
not what fail here. You are calling sys_timeout/sys_untimout functions
outside the lwIP core thread, doing that is not thread safe. Other than
that it looks pretty well engineered, you are using pppos_input_tcpip
and so on, which is the right thing to do in your case.

I bet you are using the Socket or Netconn API in your task handling the
TCP session, which is right either.
       
Sylvain

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TCP problems using pppos on stm32

Roman
Hi, Sylvain!
I really appreciate your help. Now I use Timers FreeRTOS instead of sys_timeout/sys_untimout, but it did not give a positive result. Can my problems be related to the misuse of task priorities?
Reply | Threaded
Open this post in threaded view
|

Re: TCP problems using pppos on stm32

Roman
In reply to this post by Sylvain Rochet
Hi, lwip. I still can't solve my problem, it has been going on for a long time, and I feel very stupid.
When I stopped using sys_timeout / sys_untimout and started using the FreeRTOS timers, the average transmission time was about 15 minutes when I removed the FreeRTOS timer and started using pppos_input_tcpip () in the while cycle, the average transmission time was approximately 5 minutes. What do I mean when I say "average transmission time": through sockets I continuously send a small message to the server with a specified period, and the server answers me.
As can be understood from what I said above, the situation only worsened, but I hope this will help to localize the problem.
When I tried to debug a program, I noticed that when the transfer stops in the tcp_out () function, the tcp_out_segment () function is no longer called.
My modified modem driver:modem.c
Reply | Threaded
Open this post in threaded view
|

Re: TCP problems using pppos on stm32

Sylvain Rochet
Hi Roman,

On Wed, Jul 26, 2017 at 06:08:55AM -0700, Roman wrote:

> Hi, lwip. I still can't solve my problem, it has been going on for a long
> time, and I feel very stupid.
> When I stopped using sys_timeout / sys_untimout and started using the
> FreeRTOS timers, the average transmission time was about 15 minutes when I
> removed the FreeRTOS timer and started using pppos_input_tcpip () in the
> while cycle, the average transmission time was approximately 5 minutes. What
> do I mean when I say "average transmission time": through sockets I
> continuously send a small message to the server with a specified period, and
> the server answers me.
> As can be understood from what I said above, the situation only worsened,
> but I hope this will help to localize the problem.
> When I tried to debug a program, I noticed that when the transfer stops in
> the tcp_out () function, the tcp_out_segment () function is no longer
> called.
> My modified modem driver: modem.c
> <http://lwip.100.n7.nabble.com/file/n30266/modem.c>  
I'm no TCP expert. But, since it involve PPP, could you at least check
that PPP is not the issue here by testing the throughput over a long
period of time using simple ICMP or UDP packets ?  You really have to
troubleshoot layer by layer.

Sylvain

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TCP problems using pppos on stm32

Roman
Hi, Sylvain, I am grateful for your advice and help. I found hardware problem in my project.

27 июля 2017 г. 19:40 пользователь "Sylvain Rochet" <[hidden email]> написал:
Hi Roman,

On Wed, Jul 26, 2017 at 06:08:55AM -0700, Roman wrote:
> Hi, lwip. I still can't solve my problem, it has been going on for a long
> time, and I feel very stupid.
> When I stopped using sys_timeout / sys_untimout and started using the
> FreeRTOS timers, the average transmission time was about 15 minutes when I
> removed the FreeRTOS timer and started using pppos_input_tcpip () in the
> while cycle, the average transmission time was approximately 5 minutes. What
> do I mean when I say "average transmission time": through sockets I
> continuously send a small message to the server with a specified period, and
> the server answers me.
> As can be understood from what I said above, the situation only worsened,
> but I hope this will help to localize the problem.
> When I tried to debug a program, I noticed that when the transfer stops in
> the tcp_out () function, the tcp_out_segment () function is no longer
> called.
> My modified modem driver: modem.c
> <http://lwip.100.n7.nabble.com/file/n30266/modem.c>

I'm no TCP expert. But, since it involve PPP, could you at least check
that PPP is not the issue here by testing the throughput over a long
period of time using simple ICMP or UDP packets ?  You really have to
troubleshoot layer by layer.

Sylvain

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: TCP problems using pppos on stm32

sarp
Hi,
I got the same problem what you exactly talk about, how did you solve it?



--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users