PPTP not reconnecting

RouterOS General
1

Dear community,
I am trying to solve an annoying problem for quite some time now, and i hope that anybody can help:

I am running Router OS 6.27 and i got a dsl router in single user mode connected to my mikrotik.
Basically i have set up everything according to the tutorial in the following link http://robert.penz.name/484/howto-use-a-mikrotik-as-router-for-a-pppoa-dsl-internet-connection/ and the connection is working fine initially.

BUT: Every time when the line goes down and comes back up again, the router tries to reconnect but the connection to the modem doesnt get reestablished again. Status is connect…connected..terminating…in an infinite loop until i reboot the mikrotik,then the connection is established again without a problem.

(i have to reboot the mikrotik, not the modem in order to get it working again).

I already tried the following:

  • Disabling and reenabling the interface “DslInternet” → doesnt work
  • Disabling all firewall rules for testing → doesnt work
  • Making all the routes static wherever possible → doesnt work
  • Switch on logging (pptp,packet) shows that the mikrotik seems to send a LCP echo request and doesnt get a reply
    (which seems strange, because it works again if i reboot the mikrotik)
  • it also seems to work again if i delete the DslInternet interface alltogether and recreate it

What else can i test? Which logs should i provide in order to give more insight ?
Sorry for my bad english after all (its not my native language), i hope my post is not too hard to read/follow :smiley:

Thanks in advance
Andreas

2

Have you tried earlier versions of ROS - perhaps it’s a bug.

Tried setting dial on demand and then putting a ping test or some sort of scheduled traffic which would keep it nailed up that way? It really sounds like some state information is not getting cleared somewhere.

If an older version doesn’t fix, or lacks some other feature you need, you could always make a workaround (I would hate doing this, but if it’s what had to be done) where a script can delete the interface and build it back if it finds the state = down.
(yuck)

3

Hello ZeroByte!

Thanks for your suggestion (i didnt think of downgrading because mikrotik wants their devices being up to date in order to get support, i will try that :slight_smile: I did some further testing today and here is the log:


MMM MMM KKK TTTTTTTTTTT KKK
MMMM MMMM KKK TTTTTTTTTTT KKK
MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK
MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK
MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK
MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK

MikroTik RouterOS 6.27 (c) 1999-2015 http://www.mikrotik.com/

[?] Gives the list of available commands
command [?] Gives help on the command and list of arguments
Tab] Completes the command/word. If the input is ambiguous,



.. Move up one level
/command Use command at the base level
(2653 messages not shown)

DSL LINK RUNNING OK, INTERFACE “DSLINTERNET” in “RUNNING” STATE <<<<<<<<<<

apr/08/2015 09:34:39 pptp,ppp,debug,packet 2e 06 e0 24
apr/08/2015 09:34:49 pptp,ppp,debug,packet pptpDslInternet: rcvd LCP EchoReq id=
0x46
apr/08/2015 09:34:49 pptp,ppp,debug,packet <magic 0x146be199>
apr/08/2015 09:34:49 pptp,ppp,debug,packet 2e 06 e0 24
apr/08/2015 09:34:49 pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoRep id=
0x46
apr/08/2015 09:34:49 pptp,ppp,debug,packet <magic 0x2e06e024>
apr/08/2015 09:34:49 pptp,ppp,debug,packet 2e 06 e0 24
apr/08/2015 09:34:58 system,info,account user test logged in from xxxxxxxxx
via ssh



[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd LCP EchoReq id=0x47
echo: pptp,ppp,debug,packet <magic 0x146be199>
echo: pptp,ppp,debug,packet 2e 06 e0 24
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoRep id=0x47
echo: pptp,ppp,debug,packet <magic 0x2e06e024>
echo: pptp,ppp,debug,packet 2e 06 e0 24
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd LCP EchoReq id=0x48
echo: pptp,ppp,debug,packet <magic 0x146be199>
echo: pptp,ppp,debug,packet 2e 06 e0 24
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoRep id=0x48
echo: pptp,ppp,debug,packet <magic 0x2e06e024>
echo: pptp,ppp,debug,packet 2e 06 e0 24
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd LCP EchoReq id=0x49
echo: pptp,ppp,debug,packet <magic 0x146be199>
echo: pptp,ppp,debug,packet 2e 06 e0 24
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoRep id=0x49
echo: pptp,ppp,debug,packet <magic 0x2e06e024>
echo: pptp,ppp,debug,packet 2e 06 e0 24
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd LCP EchoReq id=0x4a
echo: pptp,ppp,debug,packet <magic 0x146be199>
echo: pptp,ppp,debug,packet 2e 06 e0 24
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoRep id=0x4a
echo: pptp,ppp,debug,packet <magic 0x2e06e024>
echo: pptp,ppp,debug,packet 2e 06 e0 24

DSL LINE DISCONNECTED FOR TESTING TO SIMULATE AN OUTAGE<<
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoReq id=0x0
echo: pptp,ppp,debug,packet <magic 0x2e06e024>
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoReq id=0x1
echo: pptp,ppp,debug,packet <magic 0x2e06e024>
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoReq id=0x2
echo: pptp,ppp,debug,packet <magic 0x2e06e024>
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoReq id=0x3
echo: pptp,ppp,debug,packet <magic 0x2e06e024>
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoReq id=0x4
echo: pptp,ppp,debug,packet <magic 0x2e06e024>

DISCONNECT DETECTED, INTERFACE DSLINTERNET LEAVES “RUNNING” STATE <<<<

echo: pptp,ppp,info pptpDslInternet: terminating… - peer is not responding
echo: pptp,ppp,info pptpDslInternet: disconnected
echo: pptp,ppp,info pptpDslInternet: initializing…
echo: pptp,ppp,info pptpDslInternet: connecting…
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0xd
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x771217a5>
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0xe
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x771217a5>
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0xf
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x771217a5>

DSL LINE RECONNECTED AGAIN, MODEM IN SYNC, INTERFACE “DSLINTERNET” DOESNT REVERT TO “RUNNING” STATE AGAIN, LOOPS FOREVER

[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0x10
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x771217a5>
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0x11
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x771217a5>
[test@cerberus] >
echo: pptp,ppp,info pptpDslInternet: terminating… - disconnected
echo: pptp,ppp,info pptpDslInternet: disconnected
echo: pptp,ppp,info pptpDslInternet: initializing…
echo: pptp,ppp,info pptpDslInternet: connecting…
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0x12
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x363b42eb>
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0x13
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x363b42eb>
[test@cerberus] >
echo: pptp,ppp,info pptpDslInternet: terminating… - disconnected
echo: pptp,ppp,info pptpDslInternet: disconnected
echo: pptp,ppp,info pptpDslInternet: initializing…
echo: pptp,ppp,info pptpDslInternet: connecting…
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0x14
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x5914183f>
[test@cerberus] >
echo: pptp,ppp,info pptpDslInternet: terminating… - disconnected
echo: pptp,ppp,info pptpDslInternet: disconnected
[test@cerberus] >
echo: pptp,ppp,info pptpDslInternet: initializing…
echo: pptp,ppp,info pptpDslInternet: connecting…
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0x15
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x4c28b95c>

DELETING INTERFACE “DSLINTERNET” MANUALLY <<<<<<<<<<<<<<<<<<<<<<<

echo: system,info device removed by test

RECREATE INTERFACE “DSLINTERNET” WITH THE SAME SETTINGS THAT EXISTED BEFORE <<<<

/interface pptp-client add add-default-route=no connect-to=10.0.0.138 disabled=no name=pptpDslInternet password=mydslpassword profile=pppProfileDslInternet user=mydslusername

\

COMMUNICATION SUCCESSFUL, LINK UP AGAIN <<<<<<<<<<<<<<<<<<<<<<<<<<

echo: pptp,ppp,info pptpDslInternet: initializing…
echo: pptp,ppp,info pptpDslInternet: connecting…
echo: system,info device added by test
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0x1
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x53b0a2d>
[test@cerberus] >
(8 messages discarded)
echo: pptp,ppp,debug,packet <mru 1500>
echo: pptp,ppp,debug,packet <magic 0x2132a7fb>
echo: pptp,ppp,debug,packet
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd LCP ConfAck id=0x2
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x53b0a2d>
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd CHAP Challenge id=0x1
echo: pptp,ppp,debug,packet
echo: pptp,ppp,debug,packet
echo: pptp,ppp,debug,packet pptpDslInternet: sent CHAP Response id=0x1
echo: pptp,ppp,debug,packet
echo: pptp,ppp,debug,packet
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent CHAP Response id=0x1
echo: pptp,ppp,debug,packet
echo: pptp,ppp,debug,packet
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: sent CHAP Response id=0x1
echo: pptp,ppp,debug,packet
echo: pptp,ppp,debug,packet
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd LCP TermReq id=0x42
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP TermAck id=0x42
echo: pptp,ppp,info pptpDslInternet: terminating…
echo: pptp,ppp,info pptpDslInternet: disconnected
echo: pptp,ppp,info pptpDslInternet: initializing…
echo: pptp,ppp,info pptpDslInternet: connecting…
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP ConfReq id=0x3
echo: pptp,ppp,debug,packet <mru 1450>
echo: pptp,ppp,debug,packet <magic 0x7ace0cbe>
[test@cerberus] >
(53 messages discarded)
echo: pptp,ppp,debug,packet <addr ww.www.www.ww>
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd IPCP ConfNak id=0x1
echo: pptp,ppp,debug,packet
echo: pptp,ppp,debug,packet pptpDslInternet: sent IPCP ConfReq id=0x2
echo: pptp,ppp,debug,packet
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd LCP ProtRej id=0x2
echo: pptp,ppp,debug,packet 80 57 01 01 00 10 01 0a 00 00 00 00 00 00 00 14
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd LCP ProtRej id=0x3
echo: pptp,ppp,debug,packet 82 81 01 01 00 06
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd IPCP ConfAck id=0x2
echo: pptp,ppp,debug,packet
echo: pptp,ppp,info pptpDslInternet: connected
[test@cerberus] >
echo: pptp,ppp,debug,packet pptpDslInternet: rcvd LCP EchoReq id=0x1
echo: pptp,ppp,debug,packet <magic 0x14b66e67>
echo: pptp,ppp,debug,packet 63 bd 76 a1
echo: pptp,ppp,debug,packet pptpDslInternet: sent LCP EchoRep id=0x1
echo: pptp,ppp,debug,packet <magic 0x63bd76a1>
echo: pptp,ppp,debug,packet 63 bd 76 a1
[test@cerberus] >

Since i deleted the interface, i have to adjust my NAT “MASQUERADE” rule to point to the correct interface in order to be able to surf the net again.


The whole thing can also be achieved by only rebooting the mikrotik…so i guess it has to be a problem on mikrotik side.
Maybe normis can shed some light on this ? :slight_smile:

I will of course also test the suggested workaround from ZeroByte and report back if i can get it to work.

IF its a bug, id like to file an official support case in order to get this fixed (should i create a supout.rif file of BOTH states ? (link working and NOT working? or only “not working” state ?

Probably i am just something missing and everything works as designed ? :slight_smile:

Thanks for your patience ;.)

Andreas

4

Well, the only thing I notice is that the counter on “confreq” goes back to 1 after you delete/add the interface.
Note that the CONFREQ counter is first at 10 after the simulated outage is over. The Mikrotik is sending confreq over and over, but is not receiving any replies from the modem. It’s possible that the modem is replying, but in some way that the pptp client is not recognizing as being the reply… a sniffer run on the physical ethernet interface would answer that.

You’re right about the usual ideal of having the most recent version. However, it’s not uncommon for bugs to get introduced into ROS (sorry, Mikrotik, but it’s true) so if this is a bug, and it’s a new bug, then an older version will fix the problem.

The only other thing I noticed in your debugs (not sure how significant it is) is that prior to the outage, only the server sends keepalives, then the link is down, and only the mikrotik is sending keepalives, which time out and the link marks as down.

One more interesting thing to try for the sake of testing- what happens if you manually disable the pptp interface while the link is up and working properly? Will it restore by simply re-enabling the interface? That would be interesting.

5

Hello ZeroByte!

Thanks for your assistance, i disabled the interface, waited a few seconds and then reenabled it again, the link restores properly.

Now i have to figure out how to perform the “sniffer test” you mentioned to see whats going on in more detail.
(dont expect a reply until tomorrow since i havent done this before :slight_smile:

What confuses me is, that from the logs one can see that theres no reply from the modem, but when i reboot the mikrotik or delete the interface and recreate it, all is fine again. I never have to touch the modem in any way to bring the link back up once the modem is in sync again.

best regards and thanks again :smiley:

Andreas

6

sniffer:
Tools > sniffer
Choose the ether1 interface (or whichever physical interface is directly connected to the modem)
Clear any and all other filters / protocol limits / etc…
On the main page, set a capture filename (e.g. MyPacketCapture.cap) with a limit of something like 2040 bytes.

Then hit apply before hitting start. (sneaky “gotcha” in RouterOS)

When finished capturing, click Stop, and then download the cap file to your computer and open it in Wireshark.


Another thing I thought to try is to disable / re-activate the actual physical ethernet interface and not just the pptp interface. It could be that the modem is not completely clearing out its ppp interworking.

7

Hello ZeroByte!

Thanks for the instructions, that made life easier (i was playing around with the streaming feature at first). :slight_smile:

I tried to disable/enable the physical interface while the modem was in sync and the mikrotik not connecting successfully, unfortunately it had no positive effect. The only result i got was “link down” and “link up”, and the mikrotik continued to send echo requests and still could not establish a successful connection.

The physical connection to the modem is eth10 in my case, i didnt want to waste a Gigabit port for WAN which ordinary ADSL with 4Mbit down at max.

Then i decided that its time for the “sniffer tests”. I did a trace of both situations:

  1. wireshark_unsuccessful_reconnect:

1 0.000000 10.0.0.138 10.0.0.1 TCP 60 1723→35798 [FIN, ACK] Seq=1 Ack=1 Win=3992 Len=0
2 0.000315 10.0.0.1 10.0.0.138 TCP 54 35798→1723 [FIN, ACK] Seq=1 Ack=2 Win=980 Len=0
3 0.000859 10.0.0.138 10.0.0.1 TCP 60 1723→35798 [ACK] Seq=2 Ack=2 Win=3992 Len=0
4 10.007238 10.0.0.1 10.0.0.138 TCP 74 35799→1723 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=5550273 TSecr=0 WS=16
5 10.034115 10.0.0.138 10.0.0.1 TCP 66 1723→35799 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2
6 10.034264 10.0.0.1 10.0.0.138 TCP 54 35799→1723 [ACK] Seq=1 Ack=1 Win=14608 Len=0
7 10.034937 10.0.0.1 10.0.0.138 PPTP 210 Start-Control-Connection-Request
8 10.035478 10.0.0.138 10.0.0.1 TCP 60 1723→35799 [ACK] Seq=1 Ack=157 Win=6912 Len=0
9 10.045768 10.0.0.138 10.0.0.1 PPTP 210 Start-Control-Connection-Reply
10 10.045872 10.0.0.1 10.0.0.138 TCP 54 35799→1723 [ACK] Seq=157 Ack=157 Win=15680 Len=0
11 10.046660 10.0.0.1 10.0.0.138 PPTP 222 Outgoing-Call-Request
12 10.060040 10.0.0.138 10.0.0.1 PPTP 86 Outgoing-Call-Reply
13 10.061322 10.0.0.1 10.0.0.138 PPP LCP 64 Configuration Request
14 10.096819 10.0.0.1 10.0.0.138 TCP 54 35799→1723 [ACK] Seq=325 Ack=189 Win=15680 Len=0
15 15.065818 10.0.0.138 10.0.0.1 TCP 60 1723→35799 [FIN, ACK] Seq=189 Ack=325 Win=7984 Len=0
16 15.066306 10.0.0.1 10.0.0.138 TCP 54 35799→1723 [FIN, ACK] Seq=325 Ack=190 Win=15680 Len=0
17 15.066884 10.0.0.138 10.0.0.1 TCP 60 1723→35799 [ACK] Seq=190 Ack=326 Win=7984 Len=0
18 20.461475 10.0.0.1 255.255.255.255 MNDP 175 Source port: 5678 Destination port: 5678
19 20.461917 fe80::4e5e:cff:fe43:8644 ff02::1 MNDP 195 Source port: 5678 Destination port: 5678
20 20.462406 Routerbo_43:86:44 CDP/VTP/DTP/PAgP/UDLD CDP 110 Device ID: cerberus Port ID: ether10vlanTransitModem
21 25.149762 10.0.0.1 10.0.0.138 TCP 74 35800→1723 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=5551787 TSecr=0 WS=16
22 25.150484 10.0.0.138 10.0.0.1 TCP 66 1723→35800 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2
23 25.150630 10.0.0.1 10.0.0.138 TCP 54 35800→1723 [ACK] Seq=1 Ack=1 Win=14608 Len=0
24 25.151202 10.0.0.1 10.0.0.138 PPTP 210 Start-Control-Connection-Request
25 25.151687 10.0.0.138 10.0.0.1 TCP 60 1723→35800 [ACK] Seq=1 Ack=157 Win=6912 Len=0
26 25.161842 10.0.0.138 10.0.0.1 PPTP 210 Start-Control-Connection-Reply
27 25.161943 10.0.0.1 10.0.0.138 TCP 54 35800→1723 [ACK] Seq=157 Ack=157 Win=15680 Len=0
28 25.162726 10.0.0.1 10.0.0.138 PPTP 222 Outgoing-Call-Request
29 25.176325 10.0.0.138 10.0.0.1 PPTP 86 Outgoing-Call-Reply
30 25.206820 10.0.0.1 10.0.0.138 TCP 54 35800→1723 [ACK] Seq=325 Ack=189 Win=15680 Len=0
31 25.207149 10.0.0.1 10.0.0.138 PPP LCP 64 Configuration Request
32 30.181688 10.0.0.138 10.0.0.1 TCP 60 1723→35800 [FIN, ACK] Seq=189 Ack=325 Win=7984 Len=0
33 30.182177 10.0.0.1 10.0.0.138 TCP 54 35800→1723 [FIN, ACK] Seq=325 Ack=190 Win=15680 Len=0
34 30.182719 10.0.0.138 10.0.0.1 TCP 60 1723→35800 [ACK] Seq=190 Ack=326 Win=7984 Len=0
35 40.187216 10.0.0.1 10.0.0.138 TCP 74 35801→1723 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=5553291 TSecr=0 WS=16
36 40.188046 10.0.0.138 10.0.0.1 TCP 66 1723→35801 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2

Looks like the modem is ending the communication for some reason instead of sending a proper reply to me (?)

  1. wireshark_successful_communication

1 0.000000 10.0.0.1 255.255.255.255 MNDP 175 Source port: 5678 Destination port: 5678
2 0.000246 fe80::4e5e:cff:fe43:8644 ff02::1 MNDP 195 Source port: 5678 Destination port: 5678
3 0.000323 Routerbo_43:86:44 CDP/VTP/DTP/PAgP/UDLD CDP 110 Device ID: cerberus Port ID: ether10vlanTransitModem
4 11.520194 10.0.0.1 10.0.0.138 TCP 74 35916→1723 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=5732479 TSecr=0 WS=16
5 11.521445 10.0.0.138 10.0.0.1 TCP 66 1723→35916 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2
6 11.521589 10.0.0.1 10.0.0.138 TCP 54 35916→1723 [ACK] Seq=1 Ack=1 Win=14608 Len=0
7 11.551957 10.0.0.1 10.0.0.138 PPTP 210 Start-Control-Connection-Request
8 11.552551 10.0.0.138 10.0.0.1 TCP 60 1723→35916 [ACK] Seq=1 Ack=157 Win=6912 Len=0
9 11.572637 10.0.0.138 10.0.0.1 PPTP 210 Start-Control-Connection-Reply
10 11.572761 10.0.0.1 10.0.0.138 TCP 54 35916→1723 [ACK] Seq=157 Ack=157 Win=15680 Len=0
11 11.573503 10.0.0.1 10.0.0.138 PPTP 222 Outgoing-Call-Request
12 11.587596 10.0.0.138 10.0.0.1 PPTP 86 Outgoing-Call-Reply
13 11.600525 10.0.0.1 10.0.0.138 PPP LCP 64 Configuration Request
14 11.627470 10.0.0.1 10.0.0.138 TCP 54 35916→1723 [ACK] Seq=325 Ack=189 Win=15680 Len=0
15 12.654436 10.0.0.1 10.0.0.138 PPP LCP 64 Configuration Request
16 12.706500 10.0.0.138 10.0.0.1 GRE 60 Encapsulated PPP
17 12.716786 10.0.0.138 10.0.0.1 PPP LCP 108 Configuration Request
18 12.717028 10.0.0.138 10.0.0.1 PPP LCP 108 Configuration Ack
19 12.729692 10.0.0.1 10.0.0.138 PPP LCP 73 Configuration Ack
20 12.738849 10.0.0.138 10.0.0.1 PPP CHAP 112 Challenge (NAME=‘G-GMIT-PE1349’, VALUE=0xd843ac330a612f443091b55b5c3dcf84b489f8cd756201e7…
21 12.779209 10.0.0.1 10.0.0.138 PPP CHAP 92 Response (NAME=‘mydslusername’, VALUE=0x938942911de9d23de6acdae2d97fdbfd)
22 12.830424 10.0.0.138 10.0.0.1 GRE 60 Encapsulated PPP
23 12.843062 10.0.0.138 10.0.0.1 PPP LCP 108 Configuration Request
24 12.847308 10.0.0.1 10.0.0.138 PPP LCP 68 Configuration Request
25 12.859084 10.0.0.138 10.0.0.1 PPP LCP 112 Configuration Nak
26 12.877566 10.0.0.1 10.0.0.138 PPP LCP 72 Configuration Ack
27 12.897822 10.0.0.1 10.0.0.138 PPP LCP 68 Configuration Request
28 12.909488 10.0.0.138 10.0.0.1 PPP LCP 112 Configuration Ack
29 12.922174 10.0.0.1 10.0.0.138 PPP PAP 85 Authenticate-Request (Peer-ID=‘mydslusername’, Password=‘mydslpassword’)
30 12.943998 10.0.0.138 10.0.0.1 PPP PAP 112 Authenticate-Ack (Message=‘’)
31 12.944331 10.0.0.138 10.0.0.1 PPP IPCP 108 Configuration Request
32 13.037454 10.0.0.1 10.0.0.138 GRE 46 Encapsulated PPP
33 13.081660 10.0.0.1 10.0.0.138 PPP IPCP 64 Configuration Request
34 13.083434 10.0.0.1 10.0.0.138 PPP IPV6CP 68 Configuration Request
35 13.084028 10.0.0.1 10.0.0.138 PPP MPLSCP 58 Configuration Request
36 13.084539 10.0.0.1 10.0.0.138 PPP IPCP 64 Configuration Ack
37 13.092658 10.0.0.138 10.0.0.1 PPP IPCP 112 Configuration Nak
38 13.093342 10.0.0.1 10.0.0.138 PPP IPCP 64 Configuration Request
39 13.096014 10.0.0.138 10.0.0.1 PPP LCP 112 Protocol Reject
40 13.096502 10.0.0.138 10.0.0.1 PPP LCP 108 Protocol Reject
41 13.103943 10.0.0.138 10.0.0.1 PPP IPCP 108 Configuration Ack
42 13.123260 my.ext.ip.addr 255.255.255.255 MNDP 177 Source port: 5678 Destination port: 5678
43 13.174411 10.0.0.138 10.0.0.1 GRE 60 Encapsulated PPP
44 13.569240 my.ext.ip.addr yy.yyy.yyy.yyy ICMP 110 Echo (ping) request id=0x05b4, seq=0/0, ttl=255 (reply in 45)
45 13.582352 yy.yyy.yyy.yyy my.ext.ip.addr ICMP 112 Echo (ping) reply id=0x05b4, seq=0/0, ttl=255 (request in 44)
46 13.677442 10.0.0.1 10.0.0.138 GRE 46 Encapsulated PPP
47 15.260299 my.int.ip.addr xx.xx.xx.xx DNS 124 Standard query 0x2a36 A some.internet.machine
48 15.311394 10.0.0.138 10.0.0.1 GRE 60 Encapsulated PPP
49 16.277002 my.ext.ip.addr www.www.www.www NTP 130 NTP Version 4, client
50 16.290896 www.www.www.www my.ext.ip.addr NTP 130 NTP Version 4, server
51 16.387416 10.0.0.1 10.0.0.138 GRE 46 Encapsulated PPP
52 18.280549 my.ext.ip.addr www.www.www.www NTP 130 NTP Version 4, client
53 18.293965 www.www.www.www my.ext.ip.addr NTP 130 NTP Version 4, server
54 18.387416 10.0.0.1 10.0.0.138 GRE 46 Encapsulated PPP
55 18.676107 my.int.dns.srv zzz.zzz.zzz.zzz DNS 124 Standard query 0x2a36 A some.internet.machine
56 18.727313 10.0.0.138 10.0.0.1 GRE 60 Encapsulated PPP
57 19.278457 my.ext.ip.addr www.www.www.www NTP 130 NTP Version 4, client
58 19.292354 www.www.www.www my.ext.ip.addr ICMP 158 Destination unreachable (Port unreachable)
59 19.387452 10.0.0.1 10.0.0.138 GRE 46 Encapsulated PPP
60 20.276374 my.ext.ip.addr www.www.www.www NTP 130 NTP Version 4, client
61 20.289595 www.www.www.www my.ext.ip.addr NTP 130 NTP Version 4, server
62 20.387415 10.0.0.1 10.0.0.138 GRE 46 Encapsulated PPP
63 22.276402 my.ext.ip.addr www.www.www.www NTP 130 NTP Version 4, client
64 22.289409 www.www.www.www my.ext.ip.addr NTP 130 NTP Version 4, server
65 22.387416 10.0.0.1 10.0.0.138 GRE 46 Encapsulated PPP
66 22.801571 xx.xxx.xxx.xx yy.yy.yy.yy OSPF 126 Hello Packet
67 22.897414 10.0.0.1 10.0.0.138 GRE 46 Encapsulated PPP
68 22.945852 10.0.0.138 10.0.0.1 PPP LCP 108 Echo Request
69 22.946680 10.0.0.1 10.0.0.138 PPP LCP 66 Echo Reply
70 22.998367 10.0.0.138 10.0.0.1 GRE 60 Encapsulated PPP
71 23.200640 my.int.dns.srv yyy.yyy.yyy.yyy DNS 135 Standard query 0x2a36 A some.internet.machine
72 23.200749 my.int.dns.srv yyy.yyy.yyy.yyy DNS 124 Standard query 0x2a36 A some.internet.machine
73 23.252385 10.0.0.138 10.0.0.1 GRE 60 Encapsulated PPP
74 23.460469 my.int.dns.srv yyy.yyy.yyy.yyy DNS 117 Standard query 0x5b88 A some.internet.machine
75 23.488340 my.ext.ip.addr zzz.zzz.zzz.zzz ICMP 110 Echo (ping) request id=0x05b4, seq=1/256, ttl=255(reply in 76)
76 23.501020 zzz.zzz.zzz.zzz my.ext.ip.addr ICMP 112 Echo (ping) reply id=0x05b4, seq=1/256, ttl=255 (request in 75)
77 23.597414 10.0.0.1 10.0.0.138 GRE 46 Encapsulated PPP
78 24.276421 my.ext.ip.addr ww.www.www.www NTP 130 NTP Version 4, client
79 24.289990 ww.ww.ww.ww my.ext.ip.addr NTP 130 NTP Version 4, server

The only way apart from rebooting the mikrotik to get a successful connection again is to remove the ppp interface and add it again, then the connection works instantly and the trace looks like “wireshark_successful_communication”

Very strange, i still dont see any logic :slight_smile:

8

Ok - look at the timestamps.

Failed goes like this:
tcp establishes
mikrotik requests a pptp control session, and gets reply
mikrotik requests pptp outgoing call, and gets reply
mikrotik sends LCP request and a TCP ack for the pptp outgoing call reply packet.

      • 5 seconds goes by - - -
        modem “hangs up the phone” (TCP SYN,ACK)

Successful goes lthe same up to the LCP request part…
mikrotik sends LCP request and a TCP ack for the pptp outgoing call reply packet.

      • 1 second goes by - - -
        mikrotik sends another LCP request (ostensibly, a re-try) and the modem replies to this one.
        the connection continues.

So either the contents of the PPTP setup messages are different, or else the Mikrotik has some different timers in play for a connection that’s brand spankin’ new, vs one that’s been dead for a while.
It appears that the modem won’t wait for more than 5 seconds to begin the LCP phase.
I’m not sure why the working one appears to fail the first request and work on the second one.

Maybe the modem is beginning to create a new connection on the pppoa side, and during that creation, it can’t reply to the Mikrotik’s first LCP (i.e. - there is no pppoa going yet, so until that’s up to the LCP phase, I can’t interwork for you, mr mikrotik) Mikrotik tries again one second later, at which point the PPPoA connection is up to the LCP phase and the modem is now able to begin handing packets between interfaces.

I don’t know why the mikrotik doesn’t retry after 1 second when the link is coming back online after a failure.

9

Hello ZeroByte!

Sorry that i didnt reply for a few days, i wasnt at home during the weekend, so just a status update (in fact nothing changed) :slight_smile:
First of all,thanks a lot for your clarification, i will check if its also possible to get some log info from the modem

What i also noticed:

If the modem goes out of sync, at first nothing is logged until the ppp-interface reaches its timeout.
If the modems connection is reestablished before the ppp-timeout, then internet connection is working again as soon the modem is back in sync (for example a short outage).

If the outage lasts longer,the ppp interface reaches its timeout and the link is not marked as “running” anymore by mikrotik, the MT starts to send configuration requests and the internet connection can only be brought up again by either reboot Mikrotik or recreate the ppp interface.

I will try if its possible to get some logging info from the modem to get an idea if the problem is on the modem or the Mikrotik…especially what causes the modem to simply end the communication.

Everything i found for this situation (client side constantly sending requests which arent replied) on the net was “GRE packets cannot pass through” which arent matching for my case as the modem constantly “hangs up” and i currently have no firewall active that could block something.

10

I think you missed my point.

The modem isn’t “hanging up the phone in the Mikrotik’s face”

The Mikrotik says “I want PPtP”
The modem apparently does not hear the request. (it does not reply to the request)
The modem waits 5 seconds, assumes nobody is there, and closes the TCP socket.
It’s not hanging up because it’s refusing to handle the request.
If so, then it would do so immediately and not wait 5 seconds.
It’s 99.9% likely that the modem isn’t seeing this request.

When the connection works properly, it begins the same way:
Mikrotik says “I want PPtP”
The modem apparently hears nothing because no reply comes.
After just 1 second, the Mikrotik re-sends its request.
The modem hears this one, and sends a reply to the handshake, and everything proceeds normally.
The connection is established, and you can now get to your funny kitten videos on youtube…


See the difference:
After a live connection was broken, the Mikrotik doesn’t re-try its PPtP handshake after 1 second of not hearing back from the modem.


Try this - reboot the Mikrotik with the DSL unplugged. Let it go through a few failure cycles and then plug in the DSL line - so the router has rebooted, but has never been online. I bet it fails in that combination as well.

Likely there is some sort of retry timer fall-back that happens when several connection attempts are unsuccessful.

11

Hello ZeroByte!

Just a short update, i will have the chance to swap my modem with one of a different brand in the next 1 or 2 weeks…lets see how it works out.

Best regards

Andreas

12

Hello ZeroByte!

Finally i got my new modem (different brand) this weekend and the Problem is solved! :slight_smile:

Thanks for all your patience and support !

Best regards and have a nice weekend!

Andreas

13

I recommend the Draytek Vigor 120 modem.
I’m running this with a RB750 on ADSL2+ and works great.
Modem just worries about keeping the DSL in sync, RB750 handles the PPP login.

14

i also replied you over at “dieschmids” :wink: (http://www.dieschmids.at/forum/18-pirelli/51608-pptp-link-probleme-mikrotik-rb2011-pirelli-prg4202?start=18#68274)

i guess there was a problem with the modem or its (shitty A1) firmware :wink: and i had a lot of firmware problems with PRG AV4202N modems from A1 Telekom :wink: