lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Advise on PPPoS implementation


From: Raivis
Subject: Re: [lwip-users] Advise on PPPoS implementation
Date: Thu, 2 Nov 2017 17:02:36 +0000

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 <address@hidden> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


reply via email to

[Prev in Thread] Current Thread [Next in Thread]