RouterOS 6.20 is not sending LCP Term-Req when receives PoD

RouterOS General
1

Centos 6.5 pppd client(00:1e:67:a4:c8:db) <----> RouterOS 6.20(d4:ca:6d:01:23:36) <-----> Radius

When RouterOS receives PoD(packet of disconnect) message from Radius server, it sends PADT message, but not LCP Term-Request message:

11:29:52.830788 d4:ca:6d:01:23:36 > 00:1e:67:a4:c8:db, ethertype PPPoE D (0x8863), length 60: PPPoE PADT [ses 0x14e6]

After receiving PADT message without LCP Term-Req, pppd waits for LCP timeout (lcp-echo-interval*lcp-echo-failure) - it’s not good.

But if client(centos 6.5 pppd) terminates the connection, it sends LCP Term-Request:

11:31:07.671227 00:1e:67:a4:c8:db > d4:ca:6d:01:23:36, ethertype PPPoE S (0x8864), length 38: PPPoE [ses 0x14e7] LCP (0xc021), length 18: LCP, Term-Request (0x05), id 2, length 18
encoded length 16 (=Option(s) length 12)
0x0000: c021 0502 0010
11:31:07.671617 d4:ca:6d:01:23:36 > 00:1e:67:a4:c8:db, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x14e7] LCP (0xc021), length 6: LCP, Term-Ack (0x06), id 2, length 6
11:31:07.675547 d4:ca:6d:01:23:36 > 00:1e:67:a4:c8:db, ethertype PPPoE D (0x8863), length 60: PPPoE PADT [ses 0x14e7]

Is it possible to send LCP Term-Req message from Mikrotik to the client when it receives PoD from radius?

2

I have the same problem.
Lot of SOHO PPPoE routers do not reconnect again after PoD (or CLI, Winbox method, it makes no difference)
disconnect if do not receive correct LCP Term-Req packet before PADT.
MikroTik sends only PADT. It is incorrect.
Please fix it.

3

You have the same problem someone on a 4 year old version of RouterOS had? I’m not a 100% it’s the same problem even though you might see some of the same symptoms. You should open a post for your issue with actual details of the issue. Tagging on to a 4 year old post that had no traction to begin with and a rather vague “I have the same problem” is going to get your request ignored.

4

Yes. This is old problem has not been solved to this day.

I work in ISP and last days we conducted several tests to identify issue with disconnecting (bad reconnecting) after replacing one of the PPPoE BRAS to a MikroTik.
Down below, RouterOS session terminating dump. This is always only one PPPoE PADT packet, nothing else.
And at the second screen with pppd session terminating, it always starts with LCP Term-req packet. And this is very important for most of SOHO routers.
Without it, the routers waits for the LCP timeout to reconnect, or, worse, considers the session still to be active.

For example, today i found CPE TP-LINK 841 v13 (0.9.1 3.16 v0283.0 Build 161115 Rel.53860n) that after RoutesOS PPPoE disconnect
“think” that the PPPoE session was not terminated, until client reboot it. And the same router with rp-pppe (pppd), accel-pppd disconnects perfect.

Investigation have shown that the difference is only in the absence of LCP Ter-Req packet.
I think one LCP Term-req packet before PADT not will be big problem for right implementation of RFC 1661.
Снимок1.JPG
Снимок2.JPG

5

I just replaced all mikrotiks to normal linux with accel-pppd software. it works much more better and they fix all the issues

I recommend not to use mikrotik as BRAS. it’s just SOHO router for small enterprise

6

MikroTik works well, It has its own amenities for some tasks and cpu load is comparable to the linux accel-ppp.
I accidentally discovered the problem with incorrect PPPoE disconnects and was surprised here that such an old bug is still not fixed.

RFC 2516, 5.5. https://tools.ietf.org/html/rfc2516

When a PADT is received, no further PPP traffic is allowed to be sent
using that session. Even normal PPP termination packets MUST NOT be
sent after sending or receiving a PADT. > A PPP peer SHOULD use the
PPP protocol itself to bring down a PPPoE session> , but the PADT MAY
be used when PPP can not be used.

7

Experimentally, I found out,
that when I send a CoA (not PoD) request with attribute Session-Timeout = 1,
MikroTik drops session correctly with LCP-Termination.
That’s work fine for me.
But I hope, someday this issue will be solved finally.