Without this feature PPPoE on FreeBSD is limited to links with a MTU of 1492.
I understand the work for this feature has started, but it is not complete. I hope this ticket can make clear the priority of the work and be used to track progress.
Status: open Group: Labels: PPPoE RFC-4638 Created: Wed Aug 19, 2015 08:09 AM UTC by gbrackley Last Updated: Wed Aug 19, 2015 09:53 AM UTC Owner: Dmitry S. Luhtionov
Without this feature PPPoE on FreeBSD is limited to links with a MTU of
1492.
I understand the work for this feature has started, but it is not
complete. I hope this ticket can make clear the priority of the work and be
used to track progress.
Status: open Group: Labels: PPPoE RFC-4638 Created: Wed Aug 19, 2015 08:09 AM UTC by gbrackley Last Updated: Wed Aug 26, 2015 07:41 AM UTC Owner: Dmitry S. Luhtionov
Without this feature PPPoE on FreeBSD is limited to links with a MTU of
1492.
I understand the work for this feature has started, but it is not
complete. I hope this ticket can make clear the priority of the work and be
used to track progress.
I read from that there are kernel changes in current (11) that are required and they they are likely to be in the next MFC (merge from current) to v10.2. However the required changes are not likely to be merged to 10.1. How much of that is true?
The approach I have posted for 10.2-RELEASE (sourceforge.net) should work equally well for any FreeBSD 10, as the code in question has been stable for a long time.
In particular, you can use svn to obtain and patch the FreeBSD source. I have tested the patching step with releng/10.1 though I haven't gone on to build the resulting kernel. I see no reason why it should not build successfully.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The approach I have posted for 10.2-RELEASE https://sourceforge.net/p/mpd/bugs/54/#14d2 should work equally well
for any FreeBSD 10, as the code in question has been stable for a long time.
In particular, you can use svn to obtain and patch the FreeBSD source.
I have tested the patching step with releng/10.1 though I haven't gone on
to build the resulting kernel. I see no reason why it should not build
successfully.
Status: open Group: Labels: PPPoE RFC-4638 Created: Wed Aug 19, 2015 08:09 AM UTC by gbrackley Last Updated: Sat Sep 19, 2015 12:21 PM UTC Owner: Dmitry S. Luhtionov
Without this feature PPPoE on FreeBSD is limited to links with a MTU of
1492.
I understand the work for this feature has started, but it is not
complete. I hope this ticket can make clear the priority of the work and be
used to track progress.
I've been doing some outline testing with the work in progress implementation. I have a Zen Internet FTTC connection (on the Zen network, not via BT Wholesale WBMC) with a Huawei HG612 'modem'.
I rebuilt and reinstalled the kernel, giving a patched version of FreeBSD 10.2-RELEASE-p3 (at the time of writing).
INSTALLING MPD
I'm hoping the pfSense developers will include RFC 4638 support, so felt it prudent to backport the two patches from CVS to 'vanilla' mpd-5.7 rather than suggesting they switch to an unreleased CVS version of mpd. This patch against mpd-5.7 is in the attached 'patch-rfc4638' file.
I did some testing with some packet sniffing, and found a small bug. mpd doesn't clear the PPP-Max-Payload tag when it is not needed (I switched back from MTU 1500 to MTU 1492, but mpd didn't tell the kernel to stop sending the tag). I fixed this in the attached 'patch-rfc4638-supplementary' (for my patched mpd-5.7) and 'patch-rfc4638-supplementary-against-cvs' (for CVS HEAD).
If you copy 'patch-rfc4638' and 'patch-rfc4638-supplementary' into /usr/ports/net/mpd5/files, you can build the mpd5 port with the patch incorporated.
IN OPERATION
To set an MTU less than or equal to 1492:
set link mtu <n>
(as normal)</n>
To set an MTU greater than 1492:
set pppoe max-payload <n>
(do not use set link mtu, as this leads to a configuration error before being ignored)</n>
TESTING
Because I don't have a build environment for pfSense, I can't build a custom kernel for my pfSense box. I have tested the connection briefly from the FreeBSD box I used to build the software.
I proved using a packet sniffer that the Max-Payload option tag was being included when it should be and (once my supplementary patch above was included) omitted when it was unnecessary. I proved, too, that the 1500 byte MRU was being negotiated via LCP when appropriate.
To prove the 1500 byte MTU/MRU operation for IPv4 and IPv6, I used ping/ping6 with the 'don't fragment' option:
ping -D -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1472 data bytes
1480 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=12.438 ms
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=12.081 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=12.094 ms
1480 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=12.361 ms
etc.
ping6 -D -s 1452 -I pppoe0 2a01:348:0:1::f:1
PING6(1500=40+8+1452 bytes) [source obscured] --> 2a01:348:0:1::f:1
1460 bytes from 2a01:348:0:1::f:1, icmp_seq=0 hlim=61 time=10.966 ms
1460 bytes from 2a01:348:0:1::f:1, icmp_seq=1 hlim=61 time=10.907 ms
1460 bytes from 2a01:348:0:1::f:1, icmp_seq=2 hlim=61 time=11.011 ms
1460 bytes from 2a01:348:0:1::f:1, icmp_seq=3 hlim=61 time=10.415 ms
etc.
also see discussion http://ehc.ac/p/mpd/discussion/44692/thread/6674faeb/ (Achieving 1500 MTU with PPPoE with BT FTTC / rfc4638 )
Can you test CVS version mpd and FreeBSD-11-CURRENT from SVN ?
2015-08-26 10:41 GMT+03:00 gbrackley gbrackley@users.sf.net:
Related
Bugs:
#54Thank you for the changes.
Will the changes to the CVS version work with FreeBSD v10.1p13? or are there kernel changes since then that are required?
Wait, please for MFC to 10.2-STABLE
2015-09-18 12:53 GMT+03:00 gbrackley gbrackley@users.sf.net:
Related
Bugs:
#54I read from that there are kernel changes in current (11) that are required and they they are likely to be in the next MFC (merge from current) to v10.2. However the required changes are not likely to be merged to 10.1. How much of that is true?
The approach I have posted for 10.2-RELEASE (sourceforge.net) should work equally well for any FreeBSD 10, as the code in question has been stable for a long time.
In particular, you can use svn to obtain and patch the FreeBSD source. I have tested the patching step with releng/10.1 though I haven't gone on to build the resulting kernel. I see no reason why it should not build successfully.
MFC has been not to 10.2-RELEASE. To 10.2-STABLE only.
I am a not FreeeBSD commiter.
2015-09-19 16:12 GMT+03:00 David Wood davidjwood@users.sf.net:
Related
Bugs:
#54I've been doing some outline testing with the work in progress implementation. I have a Zen Internet FTTC connection (on the Zen network, not via BT Wholesale WBMC) with a Huawei HG612 'modem'.
PATCHING THE KERNEL
I MFCed the kernel patch to releng/10.2:
svn co http://svn.freebsd.org/base/releng/10.2 /usr/src
svn merge -c 287654 ^/head /usr/src
I rebuilt and reinstalled the kernel, giving a patched version of FreeBSD 10.2-RELEASE-p3 (at the time of writing).
INSTALLING MPD
I'm hoping the pfSense developers will include RFC 4638 support, so felt it prudent to backport the two patches from CVS to 'vanilla' mpd-5.7 rather than suggesting they switch to an unreleased CVS version of mpd. This patch against mpd-5.7 is in the attached 'patch-rfc4638' file.
I did some testing with some packet sniffing, and found a small bug. mpd doesn't clear the PPP-Max-Payload tag when it is not needed (I switched back from MTU 1500 to MTU 1492, but mpd didn't tell the kernel to stop sending the tag). I fixed this in the attached 'patch-rfc4638-supplementary' (for my patched mpd-5.7) and 'patch-rfc4638-supplementary-against-cvs' (for CVS HEAD).
If you copy 'patch-rfc4638' and 'patch-rfc4638-supplementary' into /usr/ports/net/mpd5/files, you can build the mpd5 port with the patch incorporated.
IN OPERATION
To set an MTU less than or equal to 1492:
set link mtu <n>
(as normal)</n>
To set an MTU greater than 1492:
set pppoe max-payload <n>
(do not use set link mtu, as this leads to a configuration error before being ignored)</n>
TESTING
Because I don't have a build environment for pfSense, I can't build a custom kernel for my pfSense box. I have tested the connection briefly from the FreeBSD box I used to build the software.
I proved using a packet sniffer that the Max-Payload option tag was being included when it should be and (once my supplementary patch above was included) omitted when it was unnecessary. I proved, too, that the 1500 byte MRU was being negotiated via LCP when appropriate.
To prove the 1500 byte MTU/MRU operation for IPv4 and IPv6, I used ping/ping6 with the 'don't fragment' option:
I hope this is helpful.
Last edit: David Wood 2015-09-19
Commited to CVS