ADSL MLPPP help

gnhb

Hi Guys,
Well, I'm not sure what's happening here. As you may know, pfSense is using the mpd5 application for PPP (MLPPP), PPPoE, PPtP and L2tP connections, so the mpd-5.5 code is the issue here. I didn't write that code, so my ability to help is limited. However, I search for the error message text in the mpd-5.5 source code. This is in the mpd-5.5/src/bund.c file.


	  if (b->n_up > 0 &&
	  (b->peer_mrru == 0 || lcp->peer_mrru == 0 || lcp->want_mrru == 0)) {
    	    Log(LG_BUND, ("[%s] Can't join bundle %s without "
		"multilink negotiated.", l->name, b->name));
	    return (0);
	}

It looks like the issue has to do with the mrru negotiation. I didn't expose the MRRU as a setting in the pfSense UI, so the negotiation is all going on behind the scenes. I also found this http://www.dslreports.com/forum/r21715415-FreeBSD-and-the-latest-MLPPP-issues which is also talking about difficulties with the mrru negotiation, but the error is slightly different.

Maybe the problem is the same as what they are seeing in the link above. Essentially, mpd5 won't allow MRRU less than 1500 and your ISP is trying to set MRRU less than 1500.

elsewhere in mpd-5.5/src/bund.c


	/* Configure the bundle */
	b->pppConfig.bund.enableMultilink = (lcp->peer_mrru && lcp->want_mrru)?1:0;
	/* ng_ppp does not allow MRRU less then 1500 bytes. */
	b->pppConfig.bund.mrru = (lcp->peer_mrru < 1500) ? 1500 : lcp->peer_mrru;
	b->pppConfig.bund.xmitShortSeq = lcp->peer_shortseq;
	b->pppConfig.bund.recvShortSeq = lcp->want_shortseq;
	b->pppConfig.bund.enableRoundRobin =
    	    Enabled(&b->conf.options, BUND_CONF_ROUNDROBIN);

A second possibility is shown here: (These logs are in reverse order; oldest on bottom)
Aug 3 11:34:27 ppp: [wan_link0] ENDPOINTDISC [802.1] 00 0c f1 97 15 66
Aug 3 11:34:27 ppp: [wan_link0] MP SHORTSEQ
Aug 3 11:34:27 ppp: [wan_link0] MP MRRU 2048
Aug 3 11:34:27 ppp: [wan_link0] LCP: rec'd Configure Reject #185 (Ack-Sent)
Aug 3 11:34:27 ppp: [wan_link0] LCP: state change Req-Sent –> Ack-Sent
Aug 3 11:34:27 ppp: [wan_link0] MAGICNUM 58920e14
Aug 3 11:34:27 ppp: [wan_link0] AUTHPROTO CHAP MD5
Aug 3 11:34:27 ppp: [wan_link0] MRU 1492
Aug 3 11:34:27 ppp: [wan_link0] LCP: SendConfigAck #164
Aug 3 11:34:27 ppp: [wan_link0] MAGICNUM 58920e14
Aug 3 11:34:27 ppp: [wan_link0] AUTHPROTO CHAP MD5
Aug 3 11:34:27 ppp: [wan_link0] MRU 1492
Aug 3 11:34:27 ppp: [wan_link0] LCP: rec'd Configure Request #164 (Req-Sent)

The ISP is rejecting SHORTSEQ and the requested MRRU value of 2048 in the third, fourth and fifth lines from the top of the log, but the ISP is not requesting an alternate MRRU value, so it looks like the MRRU negotiation is just dropped, leaving mpd5 with all MRRU values set to 0, and thus the error.

Please get confirmation from the ISP(s) about what MRRU value they are requesting for the link. If it's less than 1500, there's your problem.
If their MLPPP implementation is rejecting pfSense's MRRU value but isn't offering an MRRU value in the negotiation, then that causes a problem for mpd5. Just find out what their MRRU value they are assuming for the link if their PPP code isn't requesting one in the negotiation.

It looks like we might need to expose the MRRU setting in the GUI, and possibly also patch the mpd5 source (which Ermal can do) to allow MRRU values less than 1500.

Please get info from the ISP first.

Thanks,
GB

eri--

AFAIK it does not make sense to have MRRU less than mru!

From Mpd manual:

The set link mtu command sets the maximum transmit unit (MTU) value for the link. This is the size of the largest single PPP frame (minus PPP header) that this link will transmit, unless the peer requests an even lower value. The default value is 1500 bytes.

The set link mru command sets maximum receive unit (MRU) value for the link, which is the size of the largest single PPP frame (minus PPP header) that this link is capable of receiving. The default value is 1500 bytes.

If PPP multilink is negotiated on a link, then these values are less important, because multilink allows PPP frames themselves to be fragmented, so a PPP frame up to MRRU bytes can always pass through no matter how small the MTU is in a particular direction.

Probably try forcing your MRU to 1500 bytes and try again. After all that is the whole point of MLPPP.
Though it seems like you need to provide a MRRU value in config.

itbit

I followed up with my ISP

MRRU is negotiated first at 2048
and later on negotiated and accepted at 1524

MTU is done at 1492

I have attempted to set MTU at 1500 but the problem stayed to be the same

So I wonder if the MRRU of 1524 too low or failing somewhere else.

Any Ideas?

Thanks

eri--

try setting MRU to 1500 not MTU to 1500!

itbit

Hi ermal,

I'm sorry it was a typo, what I meant was

MRRU is negotiated first at 2048
and later on negotiated and accepted at 1524

MRU is done at 1492

I have attempted to set MRU at 1500 but the problem stayed to be the same

eri--

I belive you should ask the ISP what those values should be.
And enter them in your config for testing. For MRRU you have to edit the file manually i think.

gnhb

I just made two commits to the source tree, so future builds should have these features.

1. MRRU is exposed in the GUI so you can set it there now.

2. If you copy the mpd_wan.conf (or mpd_optX.conf) file generated by pfSense from the /var/etc/ directory on the pfSense box to the /conf directory (keeping the SAME file name), you can tweak that file manually and pfSense will use it for the link configuration instead of what's stored in the pfSense configuration data (config.xml). So you can massage it (in /conf ) as much as you want, and then just delete it when you're done with it.

GB

gnhb

Where are we with this? Any improvements, changes, or more testing?

GB

nybble

Hi gnhb,
I'm going to give this a try over the weekend. I will let you know.
Thanks!

valunthar

Would the procedure mentioned earlier in this thread be applicable for setting up single link MLPPP as well?