Advise on PPPoS implementation

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

Advise on PPPoS implementation

Raivis
Hi,


I've been trying to implement a PPPoS on STM32 micro-controller for the last couple weeks. I think I've reached a point where I'm stuck and due to lack of my experience in this field I don't know how to proceed.


Project background:
1. I'm using GPRS/GSM modem A6
2. It is done on Nucleo F207ZG board
3. I'm using the cubemx version of lwip, with PPPoS enabled
4. I also use FreeRTOS


Progress so far:
1. I've managed to implement the PPPoS modem interface up to the point where I successfully connect to the APN and get an IP address
2. Finally got the debugging working as well, even though it's not big of a help for myself
3. I've managed to make netconn TCP connection to my server and send TCP data via the Ethernet interface, but not through PPP.



Basically, where I'm stuck at the moment is, the netconn TCP client doesn't work through PPP. I can see with my scope or logic analyzer that data has been transmitted to the modem, but there is no response at all.  Any advice on the issue, or what to look for would be greatly appreciated!

The problem is I have no experience with the PPP protocol and I'm not sure what I should be expecting.

I've also noticed that the primary and secondary DNS are 0.0.0.0. I tried manually setting them, didn't help, still can't connect.


In any case here is my log up to the point, where it starts to re-transmit the TCP packet over and over again:



AT RESPONSE: [..OK..AT+CGATT=1...+CGATT:1....OK..]
AT COMMAND: AT+CGDCONT=1,"IP","mobile.o2.co.uk"
: 37
AT RESPONSE: [AT+CGDCONT=1,"IP","mobile.o2.co.uk"....OK..]
AT COMMAND: ATD*99***1#
: 13
AT RESPONSE: [ATD*99***1#....CONNECT..]
GSM initialised.
netif: IP address of interface  set to 0.0.0.0
netif: netmask of interface  set to 255.255.255.255
netif: GW address of interface  set to 0.0.0.0
netif: added interface pp IP addr 0.0.0.0 netmask 255.255.255.255 gw 0.0.0.0
ppp phase changed[0]: phase=0
netif: setting default interface pp
netif: setting default interface pp
ppp_connect[0]: holdoff=0
ppp phase changed[0]: phase=3
pppos_connect: unit 0: connecting
ppp_start[0]
ppp phase changed[0]: phase=6
pppos_send_config[0]: out_accm=FF FF FF FF
ppp_send_config[0]
pppos_recv_config[0]: in_accm=FF FF FF FF
ppp_recv_config[0]
ppp: auth protocols: PAP=1
pppos_write[0]: len=24
ppp_start[0]: finished
tcpip_thread: PACKET 0x20006454
pppos_input[0]: got 94 bytes
pppos_write[0]: len=24
netif_set_mtu[0]: mtu=1500
pppos_send_config[0]: out_accm=0 0 0 0
ppp_send_config[0]
pppos_recv_config[0]: in_accm=0 0 0 0
ppp_recv_config[0]
ppp phase changed[0]: phase=7
ppp phase changed[0]: phase=9
pppos_write[0]: len=20
tcpip_thread: PACKET 0x20006454
pppos_input[0]: got 1 bytes
pppos_write[0]: len=20
tcpip_thread: PACKET 0x20006454
pppos_input[0]: got 18 bytes
pppos_input[0]: Dropping incomplete packet 5
pppos_write[0]: len=14
tcpip_thread: PACKET 0x20006454
pppos_input[0]: got 19 bytes
pppos_write[0]: len=14
tcpip_thread: PACKET 0x20006454
pppos_input[0]: got 36 bytes
pppos_write[0]: len=14
sifvjcomp[0]: VJ compress enable=0 slot=0 max slot=0
netif: netmask of interface pp set to 255.255.255.255
netif: GW address of interface pp set to 192.200.1.21
netif_set_ipaddr: netif address being changed
netif: IP address of interface pp set to 10.160.53.166
sifup[0]: err_code=0
status_cb: Connected
  ipaddr    = 10.160.53.166
  gateway   = 192.200.1.21
  netmask   = 255.255.255.255
  dns1        = 0.0.0.0
  dns2        = 0.0.0.0
local  IP address 10.160.53.166
remote IP address 192.200.1.21
ppp phase changed[0]: phase=10
PPPoS initialised.
Starting TCP client...
I think it is up
Looked up addr: 0.0.2.32   [-16]
Dest addr: 80.233.190.7
tcp_bind: bind to port 49153
tcp_connect to port 2020
ip4_output_if: pp0
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |        44     | (v, hl, tos, len)
+-------------------------------+
|        0      |000|       0   | (id, flags, offset)
+-------------------------------+
|  255  |    6  |    0x0000     | (ttl, proto, chksum)
+-------------------------------+
|   10  |  160  |   53  |  166  | (src)
+-------------------------------+
|   80  |  233  |  190  |    7  | (dest)
+-------------------------------+
ip4_output_if: call netif->output()
pppos_netif_output[0]: proto=0x21, len = 44
tcpip_thread: PACKET 0x20006454
pppos_input[0]: got 1 bytes
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
ip4_output_if: pp0
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |        44     | (v, hl, tos, len)
+-------------------------------+
|        1      |000|       0   | (id, flags, offset)
+-------------------------------+
|  255  |    6  |    0x0000     | (ttl, proto, chksum)
+-------------------------------+
|   10  |  160  |   53  |  166  | (src)
+-------------------------------+
|   80  |  233  |  190  |    7  | (dest)
+-------------------------------+
ip4_output_if: call netif->output()
pppos_netif_output[0]: proto=0x21, len = 44
tcp_slowtmr: polling application
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
ip4_output_if: pp0
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |        44     | (v, hl, tos, len)
+-------------------------------+
|        2      |000|       0   | (id, flags, offset)
+-------------------------------+
|  255  |    6  |    0x0000     | (ttl, proto, chksum)
+-------------------------------+
|   10  |  160  |   53  |  166  | (src)
+-------------------------------+
|   80  |  233  |  190  |    7  | (dest)
+-------------------------------+
ip4_output_if: call netif->output()
pppos_netif_output[0]: proto=0x21, len = 44
tcp_slowtmr: polling application
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
tcp_slowtmr: polling application
tcp_slowtmr: processing active pcb
tcp_slowtmr: processing active pcb
ip4_output_if: pp0





Best Regards.

Raivis Strogonovs

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

Re: Advise on PPPoS implementation

Sylvain Rochet
Hi,

On Wed, Oct 25, 2017 at 09:27:12PM +0100, Raivis wrote:
>
> In any case here is my log up to the point, where it starts to re-transmit
> the TCP packet over and over again:

Looks like PPP is working properly here. Do you actually receive those
TCP packets on the remote side ?

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: Advise on PPPoS implementation

Raivis
Hi,

No, the connection is not even established with the remote server.

In the debugger I see, that netconn API definitely invokes the PPP interface, and goes into my serial write function, but no connection is established whatsoever. 


Note I tested whether the server works via telnet. 


Another thing is, I've noticed that the GSM module is not talking back at all when transmitting TCP packets. Looking through the RX/TX data from logic analyzer, it seems I'm sending data to the module, but it never sends anything back.

Which is very odd, since the PPP connection gets established, and during that, I can confirm via logic analyzer that the module and micro-controller are chatting back and forth.



I'm beginning to think the issue might be one of these:
1. O2 is blocking my connection, and not establishing TCP connection
              However, I'm not so sure about this, because the A6 modem has their own PPP stack, and I can connect to my server via their TCP commands and send data.
              I'm not able to use their stack, because I'm very interested in getting PPP working as a learning stepping stone, ultimately, I'll be using a satellite modem which requires PPP to establish a connection to my server.
2. Faulty modem. I ordered another one just to test it, instead of A6, I'll test with sim800l. I've noticed that this one doesn't comply with it's own datasheet AT commands. e.g. ATE0 should disable echo, and it doesn't.
3. ST implementation of LwIP is faulty. I'm using LwIP version which comes with CubeMX. I've noticed it is version 2.0.0 instead of 2.0.3.




Any other ideas, what I should be looking for or what could be the cause?

Best Regards.

Raivis Strogonovs

On Thu, Oct 26, 2017 at 10:48 AM, Sylvain Rochet <[hidden email]> wrote:
Hi,

On Wed, Oct 25, 2017 at 09:27:12PM +0100, Raivis wrote:
>
> In any case here is my log up to the point, where it starts to re-transmit
> the TCP packet over and over again:

Looks like PPP is working properly here. Do you actually receive those
TCP packets on the remote side ?

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: Advise on PPPoS implementation

goldsimon@gmx.de
Raivis wrote:

> 3. ST implementation of LwIP is faulty. I'm using LwIP version which
> comes with CubeMX. I've noticed it is version 2.0.0 instead of 2.0.3.

I don't think it is. Comparing it to our original 2.0.0 sources, they
seem to have changed only compiler warnings this time.
ST *eth drivers* may be faulty, but since you're using a serial line,
this can't be your problem. I can't comment on the serial connection though.
There have been some lines changed in PPP from 2.0.0 to 2.0.2, but those
were mostly retry/restart handling if I remember correctly. So I guess
your problem won't be fixed by upgrading the lwIP sources...

Simon

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

Re: Advise on PPPoS implementation

Sylvain Rochet
In reply to this post by Raivis
Hi,

On Thu, Oct 26, 2017 at 12:34:16PM +0100, Raivis wrote:
>
> Any other ideas, what I should be looking for or what could be the cause?

I'm confident lwIP isn't the problem here, you can still enable PPP
debugging PPP_DEBUG and PPP print packet support with PRINTPKT_SUPPORT.
Since you are having an issue with IP packets you might want to remove
packet print filtering in the ppp_dump_packet() function.

Anyway, this is the first time we hear of IP packets not working at all
once PPP session is properly established. We usually have to deal with
session establishment issues and, unfortunately usual, threading issues
in packet input path.

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: Advise on PPPoS implementation

Raivis
Hi,

I just connected the satellite modem to the micro-controller, and I get the same results. Where I'm able to establish the PPP session, but it won't connect to my TCP server.

I wanted to ask, is there a debug define I can enable which would let me know what bytes it tried to transfer over the serial? So I'm able to verify that, that is actually working?

Best Regards.

Raivis Strogonovs

On Fri, Oct 27, 2017 at 4:23 PM, Sylvain Rochet <[hidden email]> wrote:
Hi,

On Thu, Oct 26, 2017 at 12:34:16PM +0100, Raivis wrote:
>
> Any other ideas, what I should be looking for or what could be the cause?

I'm confident lwIP isn't the problem here, you can still enable PPP
debugging PPP_DEBUG and PPP print packet support with PRINTPKT_SUPPORT.
Since you are having an issue with IP packets you might want to remove
packet print filtering in the ppp_dump_packet() function.

Anyway, this is the first time we hear of IP packets not working at all
once PPP session is properly established. We usually have to deal with
session establishment issues and, unfortunately usual, threading issues
in packet input path.

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: Advise on PPPoS implementation

Sylvain Rochet
Hi,

On Wed, Nov 01, 2017 at 03:22:07PM +0000, Raivis wrote:
> Hi,
>
> I just connected the satellite modem to the micro-controller, and I get the
> same results. Where I'm able to establish the PPP session, but it won't
> connect to my TCP server.
>
> I wanted to ask, is there a debug define I can enable which would let me
> know what bytes it tried to transfer over the serial? So I'm able to verify
> that, that is actually working?

You can easily add one in your serial low level driver, which is even a
better place than before we call low level handlers; your driver might
still drop an output buffer for whatever reason.

Anyway, as previously said, enabling PPP_DEBUG, PRINTPKT_SUPPORT, and
removing IP filters in ppp_dump_packet(), is, in my opinion, the first
thing to do.

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: Advise on PPPoS implementation

Raivis
That's a very good, point, I've been so frustrated that it didn't occur to me that I can just print the packet in my serial function.

Apologies I somehow over glanced your suggestion before.

I enabled the PPP_DEBUG and PRINTPKT_SUPPORT, and removed all filters from ppp_dump_packet() in utils.c, leaving just "pp_dbglog()"  function call.


From my inexperienced point of view, the PPP side seems to work fine I guess. Is it something to do with netif? 
If you could take a look, it would be greatly appreciated.

This is the output I got:

netif: IP address of interface \0x00\0x00 set to 0.0.0.0

netif: netmask of interface \0x00\0x00 set to 255.255.255.255

netif: GW address of interface \0x00\0x00 set to 0.0.0.0

netif: added interface pp IP addr 0.0.0.0 netmask 255.255.255.255 gw 0.0.0.0

ppp phase changed[0]: phase=0

netif: setting default interface pp

ppp_connect[0]: holdoff=0

ppp phase changed[0]: phase=3

pppos_connect: unit 0: connecting

ppp_start[0]

ppp phase changed[0]: phase=6

pppos_send_config[0]: out_accm=FF FF FF FF

ppp_send_config[0]

pppos_recv_config[0]: in_accm=FF FF FF FF

ppp_recv_config[0]

ppp: auth protocols: PAP=1

sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x5851f469> <pcomp> <accomp>]

pppos_write[0]: len=24

ppp_start[0]: finished

pppos_input[0]: got 72 bytes

rcvd [LCP ConfReq id=0x1 <asyncmap 0xa0000> <auth pap> <pcomp> <accomp>]

sent [LCP ConfAck id=0x1 <asyncmap 0xa0000> <auth pap> <pcomp> <accomp>]

pppos_write[0]: len=22

rcvd [LCP ConfNak id=0x1 <asyncmap 0xa0000>]

sent [LCP ConfReq id=0x2 <asyncmap 0xa0000> <magic 0x5851f469> <pcomp> <accomp>]

pppos_write[0]: len=24

pppos_input[0]: got 45 bytes

rcvd [LCP ConfAck id=0x2 <asyncmap 0xa0000> <magic 0x5851f469> <pcomp> <accomp>]

netif_set_mtu[0]: mtu=1500

pppos_send_config[0]: out_accm=0 0 A 0

ppp_send_config[0]

pppos_recv_config[0]: in_accm=0 0 A 0

ppp_recv_config[0]

ppp phase changed[0]: phase=7

sent [PAP AuthReq id=0x1 user="payandgo" password="password"]

pppos_write[0]: len=26

pppos_input[0]: got 27 bytes

rcvd [PAP AuthAck id=0x1 ""]

PAP authentication succeeded

ppp phase changed[0]: phase=9

sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]

pppos_write[0]: len=14

rcvd [IPCP ConfReq id=0x1 <addr 192.168.254.254>]

sent [IPCP ConfAck id=0x1 <addr 192.168.254.254>]

pppos_write[0]: len=14

pppos_input[0]: got 17 bytes

rcvd [IPCP ConfNak id=0x1 <addr 10.160.149.184>]

sent [IPCP ConfReq id=0x2 <addr 10.160.149.184>]

pppos_write[0]: len=14

pppos_input[0]: got 16 bytes

rcvd [IPCP ConfAck id=0x2 <addr 10.160.149.184>]

netif: netmask of interface pp set to 255.255.255.255

netif: GW address of interface pp set to 192.168.254.254

netif_set_ipaddr: netif address being changed

netif: IP address of interface pp set to 10.160.149.184

sifup[0]: err_code=0

status_cb: Connected

ipaddr = 10.160.149.184

gateway = 192.168.254.254

netmask = 255.255.255.255

local IP address 10.160.149.184

remote IP address 192.168.254.254

ppp phase changed[0]: phase=10

PPPoS initialised.

Starting TCP client...

Dest addr: 80.233.190.7

tcp_bind: bind to port 49153

tcp_connect to port 2020

pppos_netif_output[0]: proto=0x21, len = 44

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

pppos_netif_output[0]: proto=0x21, len = 44

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

pppos_netif_output[0]: proto=0x21, len = 44

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

pppos_netif_output[0]: proto=0x21, len = 44

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

pppos_netif_output[0]: proto=0x21, len = 44

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

pppos_netif_output[0]: proto=0x21, len = 44

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: processing active pcb

pppos_netif_output[0]: proto=0x21, len = 44

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_slowtmr: max SYN retries reached

tcp_pcb_purge

tcp_pcb_purge: data left on ->unacked

TCP connect failed: -13

Couldn't connect to TCP server


Best Regards.

Raivis Strogonovs

On Thu, Nov 2, 2017 at 3:52 PM, Sylvain Rochet <[hidden email]> wrote:
Hi,

On Wed, Nov 01, 2017 at 03:22:07PM +0000, Raivis wrote:
> Hi,
>
> I just connected the satellite modem to the micro-controller, and I get the
> same results. Where I'm able to establish the PPP session, but it won't
> connect to my TCP server.
>
> I wanted to ask, is there a debug define I can enable which would let me
> know what bytes it tried to transfer over the serial? So I'm able to verify
> that, that is actually working?

You can easily add one in your serial low level driver, which is even a
better place than before we call low level handlers; your driver might
still drop an output buffer for whatever reason.

Anyway, as previously said, enabling PPP_DEBUG, PRINTPKT_SUPPORT, and
removing IP filters in ppp_dump_packet(), is, in my opinion, the first
thing to do.

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: Advise on PPPoS implementation

Sylvain Rochet
Hi,

On Thu, Nov 02, 2017 at 05:02:36PM +0000, Raivis wrote:

> That's a very good, point, I've been so frustrated that it didn't occur to
> me that I can just print the packet in my serial function.
>
> Apologies I somehow over glanced your suggestion before.
>
> I enabled the PPP_DEBUG and PRINTPKT_SUPPORT, and removed all filters from
> ppp_dump_packet() in utils.c, leaving just "pp_dbglog()"  function call.
>
>
> From my inexperienced point of view, the PPP side seems to work fine I
> guess.
It is, pppos_netif_output() is the last step in the lwIP PPP stack, it
means (if it succeed, which is the case here), that your serial output
callback was called.


> Is it something to do with netif?

I don't understand to which scope this question apply; The netif is
properly configured for me, we can undoubtfuly see the TCP SYN attempt
in the debug log, meaning the packet goes down all the stack up to your
serial low level writer.

If you are talking about your low level flow serial driver, it looks
fine from here, you already said you saw the TCP packet properly sent on
wire.

However, there might be some missing dark magic in your dialup
chatscript ("AT" commands) before starting the PPP session. Your modem
accepts the PPP session and set a apparently usable IP address so it
should work but, well, some of these modems (all?), especially cellular
ones, have some quirks[*] in their firmwares.

   [*] I'm saving a strong word here


Maybe you could try with UDP first instead of TCP; I don't think it
would help in this case but we never know.


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: Advise on PPPoS implementation

Raivis
Hi,

I tested with UDP, and it didn't work.


But, whole day, I've been working on porting the PPP GSM interface to unix system. Took me a while since, I hadn't worked with LwIP at this detail before.

Thankfully, I can confirm it works on my linux machine, but not on stm32. So I've probably made a mistake somewhere with stm32.


Now that I have a working system, I can compare it to stm32 and see what goes wrong, and try to solve it. My main suspect is the way I'm using HAL layer for serial transmission. (which is still odd, since PPP get's the IP)



In any case, thank you all for your help.
I also wanted to add that contribution package was a massive help and once you know what you are looking for, the documentation is nicely structured and I was able to find exactly what I need.


Best Regards.

Raivis Strogonovs

On Thu, Nov 2, 2017 at 5:48 PM, Sylvain Rochet <[hidden email]> wrote:
Hi,

On Thu, Nov 02, 2017 at 05:02:36PM +0000, Raivis wrote:
> That's a very good, point, I've been so frustrated that it didn't occur to
> me that I can just print the packet in my serial function.
>
> Apologies I somehow over glanced your suggestion before.
>
> I enabled the PPP_DEBUG and PRINTPKT_SUPPORT, and removed all filters from
> ppp_dump_packet() in utils.c, leaving just "pp_dbglog()"  function call.
>
>
> From my inexperienced point of view, the PPP side seems to work fine I
> guess.

It is, pppos_netif_output() is the last step in the lwIP PPP stack, it
means (if it succeed, which is the case here), that your serial output
callback was called.


> Is it something to do with netif?

I don't understand to which scope this question apply; The netif is
properly configured for me, we can undoubtfuly see the TCP SYN attempt
in the debug log, meaning the packet goes down all the stack up to your
serial low level writer.

If you are talking about your low level flow serial driver, it looks
fine from here, you already said you saw the TCP packet properly sent on
wire.

However, there might be some missing dark magic in your dialup
chatscript ("AT" commands) before starting the PPP session. Your modem
accepts the PPP session and set a apparently usable IP address so it
should work but, well, some of these modems (all?), especially cellular
ones, have some quirks[*] in their firmwares.

   [*] I'm saving a strong word here


Maybe you could try with UDP first instead of TCP; I don't think it
would help in this case but we never know.


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: Advise on PPPoS implementation

Sylvain Rochet
Hi,

On Thu, Nov 02, 2017 at 11:15:18PM +0000, Raivis wrote:

> Hi,
>
> I tested with UDP, and it didn't work.
>
> But, whole day, I've been working on porting the PPP GSM interface to unix
> system. Took me a while since, I hadn't worked with LwIP at this detail
> before.
>
> Thankfully, I can confirm it works on my linux machine, but not on stm32.
> So I've probably made a mistake somewhere with stm32.
>
> Now that I have a working system, I can compare it to stm32 and see
> what goes wrong, and try to solve it. My main suspect is the way I'm
> using HAL layer for serial transmission. (which is still odd, since
> PPP get's the IP)
This is not necessarily odd, the stack path is totally different between
a tx packet which source is the PPP stack itself and a tx packet which
source is external to lwIP such as a UDP or a TCP packet generated from
your user code. If you look closely at the PPP source you will see that
the path distinction actually goes down to the PPP low level protocol
(oS,oE,oL2TP).

And it matters, it matters a lot, frames sent by the PPP stack itself
are mostly driven by received packets (we are negotiating with a
classical do-don't-will-won't manner), meaning tx caller is called in
the exact same context of the rx context. Rationale is the same for
packets sent from user applications, they are sent from the current user
application context (unless you are using one of messagebox driven APIs
indeed). Context for both output paths *MUST* *BE* the same.

The more you say, the more I am suspecting a usual violation of lwIP
contexts (threads, interrupt handlers) requirements. Are you sure you
are using the proper PPPoS input API for your case ? Are you sure you
are not using lwIP RAW API outside your lwIP core context ?

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: Advise on PPPoS implementation

Raivis
Hi,

I re-implemented on Unix system with threading, the code is basically 99% identical as the one I'm running on stm32.
I double checked the priorities, and they are the same as on unix system. All relative to default thread priority

Also I only used tcpip_init() to initialize it, as far as I know I never touched raw LwIP API after that.

However, by saying that, I just managed to get it working on stm32, by transferring my unix lwipopts.h config file to the stm32 and adding some stm32 specific defines to it.

Honestly I'm not sure why it works, and what caused the issue, maybe you as an expert can get an idea why it works by quickly glancing at the two config files:

Here is the original stm32 lwipopts.h:


And here is the one which started working


Thanks

Best Regards.

Raivis Strogonovs

On Fri, Nov 3, 2017 at 6:17 PM, Sylvain Rochet <[hidden email]> wrote:
Hi,

On Thu, Nov 02, 2017 at 11:15:18PM +0000, Raivis wrote:
> Hi,
>
> I tested with UDP, and it didn't work.
>
> But, whole day, I've been working on porting the PPP GSM interface to unix
> system. Took me a while since, I hadn't worked with LwIP at this detail
> before.
>
> Thankfully, I can confirm it works on my linux machine, but not on stm32.
> So I've probably made a mistake somewhere with stm32.
>
> Now that I have a working system, I can compare it to stm32 and see
> what goes wrong, and try to solve it. My main suspect is the way I'm
> using HAL layer for serial transmission. (which is still odd, since
> PPP get's the IP)

This is not necessarily odd, the stack path is totally different between
a tx packet which source is the PPP stack itself and a tx packet which
source is external to lwIP such as a UDP or a TCP packet generated from
your user code. If you look closely at the PPP source you will see that
the path distinction actually goes down to the PPP low level protocol
(oS,oE,oL2TP).

And it matters, it matters a lot, frames sent by the PPP stack itself
are mostly driven by received packets (we are negotiating with a
classical do-don't-will-won't manner), meaning tx caller is called in
the exact same context of the rx context. Rationale is the same for
packets sent from user applications, they are sent from the current user
application context (unless you are using one of messagebox driven APIs
indeed). Context for both output paths *MUST* *BE* the same.

The more you say, the more I am suspecting a usual violation of lwIP
contexts (threads, interrupt handlers) requirements. Are you sure you
are using the proper PPPoS input API for your case ? Are you sure you
are not using lwIP RAW API outside your lwIP core context ?

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: Advise on PPPoS implementation

Sylvain Rochet
Hi,

On Sun, Nov 05, 2017 at 08:05:28PM +0000, Raivis wrote:
>
> Here is the original stm32 lwipopts.h:
> https://pastebin.com/LEueShJv

Well, I'm confident CHECKSUM_GEN_* values set to 0 won't work when using
PPPoS. I know none hardware UART able to compute them on the fly on HDLC
formatted packets...

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: Advise on PPPoS implementation

Raivis
Hi,

Yup, you were absolutely correct.

By default all checksums are disabled in Stm32 CubeMX. 
I just enabled them, regenerated the code via CubeMX, now PPPoS and TCP client works without me faffing around with the config file.


That was a bit of challenge to get it working :)

Thank you again for your help.

Best Regards.

Raivis Strogonovs

On Wed, Nov 8, 2017 at 5:26 PM, Sylvain Rochet <[hidden email]> wrote:
Hi,

On Sun, Nov 05, 2017 at 08:05:28PM +0000, Raivis wrote:
>
> Here is the original stm32 lwipopts.h:
> https://pastebin.com/LEueShJv

Well, I'm confident CHECKSUM_GEN_* values set to 0 won't work when using
PPPoS. I know none hardware UART able to compute them on the fly on HDLC
formatted packets...

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: Advise on PPPoS implementation

sarp
Was the only problem checksum enabling?



--
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
Reply | Threaded
Open this post in threaded view
|

Re: Advise on PPPoS implementation

Raivis-2
Hi Sarp,

Just to get it working, yes.

But also to avoid crashing on high latency medium I had to enable SYS_LIGHTWEIGHT_PROT as well.



sarp <[hidden email]> (šajā datumā: Ce, 2018. g. 21. jūn. 11:48) rakstīja:
Was the only problem checksum enabling?



--
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

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

Re: Advise on PPPoS implementation

sarp

I am using HAL_UART_RxCpltCallback() with SysTick to fill pppos_input.

PPP negotiation goes well and I get IP.

I am opening a netconn socket in the second thread.

However, socket seems it is halfly opened and cannot communicate with the pppnetif in the granularity level.

May I want you to send the part of the code where you feet ppp and where you open socket?

 

Your help will honor me since there is not any example on this specific area and I will get fired if I could not manage TCP sockets properly with pppos..

 

From: [hidden email]
Sent: Thursday, June 21, 2018 3:37 PM
To: [hidden email]
Subject: Re: [lwip-users] Advise on PPPoS implementation

 

Hi Sarp,

 

Just to get it working, yes.

 

But also to avoid crashing on high latency medium I had to enable SYS_LIGHTWEIGHT_PROT as well.

 

 

 

sarp <[hidden email]> (šajā datumā: Ce, 2018. g. 21. jūn. 11:48) rakstīja:

Was the only problem checksum enabling?



--
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

 


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

Re: Advise on PPPoS implementation

bszekely
In reply to this post by Raivis
Hi Raivis,

By any chance - can you share source codes which would help me to achieve a
similar setup?
I'm using an STM32F429 with CubeMX, attached a SIM800l GSM modul and I need
to enable PPPOS connectivity.

I would really appreciate the help.

Thank you,
Balas



--
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