Menu

#54 Add support for RFC-4638 (Accommodating a MTU/MRU > 1492 in the PPPoE)

None
closed
5
2015-10-29
2015-08-19
gbrackley
No

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.

https://tools.ietf.org/html/rfc4638

Related

Bugs: #54

Discussion

  • Dmitry S. Lukhtionov

    • assigned_to: Dmitry S. Luhtionov
    • Group: -->
     
  • gbrackley

    gbrackley - 2015-09-18

    Thank 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?

     
    • Dmitry S. Lukhtionov

      Wait, please for MFC to 10.2-STABLE

      2015-09-18 12:53 GMT+03:00 gbrackley gbrackley@users.sf.net:

      Thank 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?


      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.

      https://tools.ietf.org/html/rfc4638

      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/mpd/bugs/54/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #54

  • gbrackley

    gbrackley - 2015-09-18

    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?

     
    • David Wood

      David Wood - 2015-09-19

      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.

       
      • Dmitry S. Lukhtionov

        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:

        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.

        https://tools.ietf.org/html/rfc4638

        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/mpd/bugs/54/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

         

        Related

        Bugs: #54

  • David Wood

    David Wood - 2015-09-19

    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'.

    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:

    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.

    I hope this is helpful.

     

    Last edit: David Wood 2015-09-19
  • Dmitry S. Lukhtionov

    • status: open --> closed
     
  • Dmitry S. Lukhtionov

    Commited to CVS

     

Log in to post a comment.

MongoDB Logo MongoDB