We tried to connect to MicroTik L2tp server and it works perfect with ping
and HTML and everything else. Super!
We think that was an additional (and probably wrong) ZLB packet from the
server after ICRP message.
We tried to change that "special case" like this:
/* Handle the special case of
We tried to connect to MicroTik L2tp server and it works perfect with ping
and HTML and everything else. Super!
We think that was an additional (and probably wrong) ZLB packet from the
server after ICRP message.
We tried to change that "special case" like this:
/* Handle the special case of
Sequence number is losted somewhere... I put l2tp->our_ns = l2tp->peer_nr
at the start of pppol2tp_input and now it works without interruptions. But
still no any ping through VPN server from Windows client to the device with
LwIP, only to static ip of the device.
--
View this message in
But if server requests with ns=2, nr=4, why LwIP responds with ns=3, nr=3?
nsnr
Data input: c8 02 00 14 d0 b3 00 00 [00 02] [00 04] 80 08 00 00 00 00 00 06
UDP send: c8 02 00 0c 76 c4 00 00 [00 03] [00 03]
--
View this message
No, sorry, it asks. If "Hello" is:
pppol2tp: input packet, len=20, tunnel=53427, session=0, ns=2, nr=4
Data input: c8 02 00 14 d0 b3 00 00 00 02 00 04 80 08 00 00 00 00 00 06
than in pppol2tp_udp_send:
UDP send: c8 02 00 0c 76 c4 00 00 00 03 00 03
--
View this message in context:
Hi
Sylvain Rochet wrote
> Could you try replacing
>
> if (l2tp->iccn_retried >= PPPOL2TP_MAXICCN) {
> pppol2tp_abort_connect(l2tp);
> return;
> }
>
> by
>
> if (l2tp->iccn_retried >= PPPOL2TP_MAXICCN) {
> PPPDEBUG(LOG_DEBUG, ("pppol2tp: reached max
Hi,
On Thu, Jul 06, 2017 at 11:10:41PM -0700, odobryabov wrote:
> Yes, you are right, these are just echo requests and replies:
>
> ppp phase changed[1]: phase=10
> pppol2tp: input packet, len=0, tunnel=21944, session=8324, ns=0, nr=0
> rcvd [LCP EchoReq id=0x1 magic=0x5e33e1ff]
> sent [LCP
Yes, you are right, these are just echo requests and replies:
ppp phase changed[1]: phase=10
pppol2tp: input packet, len=0, tunnel=21944, session=8324, ns=0, nr=0
rcvd [LCP EchoReq id=0x1 magic=0x5e33e1ff]
sent [LCP EchoRep id=0x1 magic=0xb4b7bbcf]
pppol2tp: input packet, len=0, tunnel=21944,
Hi,
On Wed, Jul 05, 2017 at 09:02:02PM -0700, odobryabov wrote:
>
> (...)
>
> pppol2tp: input packet, len=0, tunnel=47089, session=35933, ns=0, nr=0
> Data hex: ff 03 c0 21 09 1c 00 08 d9 bb 4b cc
^
LCP
^^
And if move that printf in l2tp_input with other debug information (sometimes
Data hex: doesn't work):
ppp phase changed[1]: phase=0
ppp_connect[1]: holdoff=0
ppp phase changed[1]: phase=3
pppol2tp: input packet, len=107, tunnel=47089, session=0, ns=0, nr=1
Data hex: 80 08 00 00 00 00 00 02 80 08
I paisted some printf-s in ppp_input
printf("Data hex: ");
uint8_t* a = (uint8_t*)pb->payload;
for(uint8_t i=0; i < pb->len; i++)
{
printf("%02x ", a[i]);
}
printf("\n");
Now I have a bytes picture:
Data hex: 01 02 00 0f 03 05 c2
Here is a log with PRINTPKT_SUPPORT and PPP_PROTOCOLNAME:
ppp phase changed[1]: phase=0
ppp_connect[1]: holdoff=0
ppp phase changed[1]: phase=3
pppol2tp: input packet, len=107, tunnel=53427, session=0, ns=0, nr=1
pppol2tp: Assigned tunnel ID 42226
pppol2tp: input packet, len=12, tunnel=53427,
Hi,
On Fri, Jun 30, 2017 at 02:52:18AM -0700, odobryabov wrote:
> We don't use IPSec on our server.
Please enable PRINTPKT_SUPPORT and PPP_PROTOCOLNAME, you have to find
out what is behind the mysterious retries we see on your first log,
until now, we don't even know if those are PPP packets.
We don't use IPSec on our server.
I also turned on udp and IP debug. Logs of these frames:
udp_input: received datagram of length 28
UDP header:
+---+
| 1701 | 49154 | (src port, dest port)
+---+
|28 | 0x
Hi,
On Thu, Jun 29, 2017 at 05:31:31AM -0700, odobryabov wrote:
>
> ppp phase changed[1]: phase=10
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427,
15 matches
Mail list logo