Netgate SG-1000 microFirewall

Author Topic: RFC 4638 client support (PPPoE MTU > 1492) - testing  (Read 6722 times)

0 Members and 1 Guest are viewing this topic.

Offline David_W

  • Sr. Member
  • ****
  • Posts: 386
  • Karma: +74/-0
    • View Profile
RFC 4638 client support (PPPoE MTU > 1492) - testing
« on: October 01, 2015, 04:02:02 am »
As mentioned in Redmine Feature #4542 and the bounty thread, I've been working on RFC 4638 support for pfSense. The time has come to open up my work to wider testing and scrutiny.

This builds on work by Dmitry Luhtionov.



Before reading further, there are several important things you must understand:
  • The test binaries are for amd64 (64 bit) only - I will not be building i386 (32 bit) binaries.
  • This is designed to install on top of pfSense 2.2.4-RELEASE and no other version.
  • Back up your configuration before installation - you might leave your pfSense box unbootable if something goes wrong.
  • Have pfSense 2.2.4-RELEASE installation media to hand and check it boots before proceeding, as you might need it to reinstall pfSense!
  • You will be replacing the kernel and PPP daemon binaries with binaries built on my pfSense builder VM. If something goes wrong with this part of the installation, you will have to reinstall pfSense unless you know how to recover a broken FreeBSD installation.
  • This definitely will not be included in any future pfSense 2.2.x version as 2.2 is a feature frozen branch. I hope it will be included in pfSense 2.3.
  • If you want to use MTUs higher than 1492, you need:
    • the network interface you use for PPPoE to be jumbo capable - I'm using an igb(4) device
    • any network infrastructure to be jumbo capable - I'm using a Huawei HG612 VDSL2 bridge (an Openreach FTTC modem)
    • the ISP to support RFC 4638 operation. Most UK ISPs using PPPoE on Openreach FTTx support MTU up to 1500. I'm using Zen Internet
  • I regard SSH access to the target pfSense box as mandatory for installation.
  • I will not offer installation support - if you don't understand how to use a FreeBSD command prompt, this is not for you.
  • I take no responsibility if anything goes wrong. This is alpha test grade stuff, though it is working well for me.
  • The installation instructions are only minimally tested and may contain bugs.



Installing the modified kernel

At a SSH command prompt:

Code: [Select]
sh
fetch -o /root/kernel-rfc4638.tgz \
https://dl.dropboxusercontent.com/u/107909287/pfSense%20RFC4638/kernel-rfc4638.tgz &&
( if [[ -d /boot/kernel && ! -d /boot/kernel-2.2.4 ]]; then mv /boot/kernel /boot/kernel-2.2.4; fi ) &&
tar -C / -xzf /root/kernel-rfc4638.tgz
exit

Before going any further, check the contents of /boot/kernel are similar to the contents of /boot/kernel-2.2.4 (a backup of the 2.2.4-RELEASE kernel). diff -rN /boot/kernel-2.2.4 /boot/kernel is recommended, and should produce the following output:
Code: [Select]
diff -rN /boot/kernel-2.2.4 /boot/kernel
Files /boot/kernel-2.2.4/aesni.ko and /boot/kernel/aesni.ko differ
Files /boot/kernel-2.2.4/alpm.ko and /boot/kernel/alpm.ko differ
Files /boot/kernel-2.2.4/amdpm.ko and /boot/kernel/amdpm.ko differ
Files /boot/kernel-2.2.4/amdsmb.ko and /boot/kernel/amdsmb.ko differ
Files /boot/kernel-2.2.4/coretemp.ko and /boot/kernel/coretemp.ko differ
Files /boot/kernel-2.2.4/dummynet.ko and /boot/kernel/dummynet.ko differ
Files /boot/kernel-2.2.4/fdescfs.ko and /boot/kernel/fdescfs.ko differ
Files /boot/kernel-2.2.4/glxsb.ko and /boot/kernel/glxsb.ko differ
Files /boot/kernel-2.2.4/ichsmb.ko and /boot/kernel/ichsmb.ko differ
Files /boot/kernel-2.2.4/if_ic.ko and /boot/kernel/if_ic.ko differ
Files /boot/kernel-2.2.4/if_stf.ko and /boot/kernel/if_stf.ko differ
Files /boot/kernel-2.2.4/iic.ko and /boot/kernel/iic.ko differ
Files /boot/kernel-2.2.4/iicbus.ko and /boot/kernel/iicbus.ko differ
Files /boot/kernel-2.2.4/iicsmb.ko and /boot/kernel/iicsmb.ko differ
Files /boot/kernel-2.2.4/intpm.ko and /boot/kernel/intpm.ko differ
Files /boot/kernel-2.2.4/ipdivert.ko and /boot/kernel/ipdivert.ko differ
Files /boot/kernel-2.2.4/ipfw.ko and /boot/kernel/ipfw.ko differ
Files /boot/kernel-2.2.4/ipmi.ko and /boot/kernel/ipmi.ko differ
Files /boot/kernel-2.2.4/kernel.gz and /boot/kernel/kernel.gz differ
Files /boot/kernel-2.2.4/linker.hints and /boot/kernel/linker.hints differ
Files /boot/kernel-2.2.4/ndis.ko and /boot/kernel/ndis.ko differ
Files /boot/kernel-2.2.4/nfsmb.ko and /boot/kernel/nfsmb.ko differ
Files /boot/kernel-2.2.4/opensolaris.ko and /boot/kernel/opensolaris.ko differ
Files /boot/kernel-2.2.4/pcf.ko and /boot/kernel/pcf.ko differ
Files /boot/kernel-2.2.4/sfxge.ko and /boot/kernel/sfxge.ko differ
Files /boot/kernel-2.2.4/sfxge.ko.symbols and /boot/kernel/sfxge.ko.symbols differ
Files /boot/kernel-2.2.4/smb.ko and /boot/kernel/smb.ko differ
Files /boot/kernel-2.2.4/smbus.ko and /boot/kernel/smbus.ko differ
Files /boot/kernel-2.2.4/viapm.ko and /boot/kernel/viapm.ko differ
Files /boot/kernel-2.2.4/zfs.ko and /boot/kernel/zfs.ko differ

If something is wrong, sort it out before going any further, otherwise your pfSense box will not be bootable. In particular, check that /boot/kernel/kernel.gz exists!


Installing the modified mpd5 binary

At a SSH command prompt:

Code: [Select]
sh
fetch -o /root/mpd5-rfc4638.tgz \
https://dl.dropboxusercontent.com/u/107909287/pfSense%20RFC4638/mpd5-rfc4638.tgz &&
( if [[ -f /usr/local/sbin/mpd5 && ! -f /usr/local/sbin/mpd5-2.2.4 ]]; then mv /usr/local/sbin/mpd5 /usr/local/sbin/mpd5-2.2.4; fi ) &&
tar -C / -xzf /root/mpd5-rfc4638.tgz
exit


Reboot and check everything works normally

Once you are sure the binaries are installed correctly, you have several backups of your configuration and a backup of any other data you care about, reboot the pfSense box. Check everything works as before.


Install the 'System Patches' package

Using the pfSense package manager (System -> Packages), install the pfSense 'System Patches' package if you do not already have it installed.


Install the pfSense patch

In the patch manager (System -> Patches), add a new patch as follows:

FieldContents
DescriptionRFC 4638 patch
URL/Commit IDhttps://dl.dropboxusercontent.com/u/107909287/pfSense%20RFC4638/rfc4638.patch
Patch Contents(leave blank)
Path Strip Count1
Base Directory/
Ignore Whitespace(checked)
Auto Apply(unchecked)

Press the Save button, then, if necessary, press 'Fetch' next to the patch. At this point, the option to 'Apply' should appear, so press 'Apply'.


Configuring your interfaces

The patch sets the MTU of interfaces where necessary, but will not override explicitly configured interface MTUs. The code attempts to set the PPPoE interface MTU, then checks the MTU achieved when building the mpd5 configuration file. If your PPPoE interface is not jumbo capable, you will have a maximum MTU of 1492 as before.

The easiest way to get MTU 1500 operation is:
  • Set any other vlans on the same physical interface to the PPPoE interface to MTU 1500 (if you don't explicitly set an MTU, they will likely finish up with an MTU of 1508, which will cause various strange symptoms). (Edit: not necessary with the latest patch - the MTU of other vlans will not rise above 1500 without explicit configuration)
  • Set the PPPoE interface to MTU 1500.



Comments / feedback / suggestions

Feedback is welcome here or in Redmine Feature #4542. Reports of this working or not working will be useful.


The modified pfSense code can be found in the RELENG_2_2-rfc4638 branch of davidjwood/pfsense on GitHub. Pull requests are welcome if you want to suggest any improvements.

The modifications to the kernel and mpd5 can be found in the pull request against pfsense/pfsense-tools on GitHub (this is only accessible to those who have executed the agreements needed to have access to the pfsense-tools repository).
« Last Edit: October 12, 2015, 12:48:31 am by David_W »

Offline pf3000

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +10/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #1 on: October 01, 2015, 12:21:59 pm »
It's working! The only thing to do was enter "1500" as MTU in Interfaces>assign>PPPs>edit pppoe interface(advanced). I have a regular 1 WAN/1 LAN setup, and Zhone ZNID-GE-2424 optical modem.

Before setting MTU
Code: [Select]
[2.2.4-RELEASE][user]/root: ifconfig vmx0
vmx0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=60079b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 00:01:0a:21:6b:60
        inet6 fe80::201:aff:fe21:6b60%vmx0 prefixlen 64 scopeid 0x1
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect
        status: active
[2.2.4-RELEASE][user]/root: ifconfig pppoe0
pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
        inet 104.16.24.4 --> 190.93.246.58 netmask 0xffffffff
        inet6 fe80::201:aff:fe21:6b60%pppoe0 prefixlen 64 scopeid 0x7
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

After setting MTU
Code: [Select]
[2.2.4-RELEASE][user]/root: ifconfig pppoe0
pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
        inet 104.16.24.4 --> 190.93.246.58 netmask 0xffffffff
        inet6 fe80::201:aff:fe21:6b60%pppoe0 prefixlen 64 scopeid 0x7
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
[2.2.4-RELEASE][user]/root: ifconfig vmx0
vmx0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1508
        options=60079b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 00:01:0a:21:6b:60
        inet6 fe80::201:aff:fe21:6b60%vmx0 prefixlen 64 scopeid 0x1
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect
        status: active
[2.2.4-RELEASE][user]/root: ping -D -s 1472 8.8.4.4
PING 8.8.4.4 (8.8.4.4): 1472 data bytes
1480 bytes from 8.8.4.4: icmp_seq=0 ttl=46 time=254.497 ms
1480 bytes from 8.8.4.4: icmp_seq=1 ttl=46 time=254.081 ms
1480 bytes from 8.8.4.4: icmp_seq=2 ttl=46 time=253.628 ms
1480 bytes from 8.8.4.4: icmp_seq=3 ttl=46 time=252.947 ms
1480 bytes from 8.8.4.4: icmp_seq=4 ttl=46 time=253.229 ms
1480 bytes from 8.8.4.4: icmp_seq=5 ttl=46 time=253.980 ms
^C
--- 8.8.4.4 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 252.947/253.727/254.497/0.524 ms

Offline David_W

  • Sr. Member
  • ****
  • Posts: 386
  • Karma: +74/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #2 on: October 01, 2015, 12:56:52 pm »
It's working! The only thing to do was enter "1500" as MTU in Interfaces>assign>PPPs>edit pppoe interface(advanced). I have a regular 1 WAN/1 LAN setup, and Zhone ZNID-GE-2424 optical modem.

That's really good to hear.


Rather than setting the MTU of the PPP port, you can simply set the MTU of the PPPoE interface to 1500. Assuming this is your WAN interface, go into Interfaces->WAN and set MTU to 1500. You may have to drop and re-establish the connection (using Status->Interfaces, or simply reboot) before the connection works properly.

Offline pf3000

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +10/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #3 on: October 01, 2015, 01:01:09 pm »
Okay. Also I PM'd the ppp log.

Offline gregb

  • Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #4 on: October 04, 2015, 02:43:12 am »
David, thank you for the work to put this together. I followed the instructions above and got it semi-working. The scripts didn't quite cut-n-paste from your message (it didn't really matter, but the backup of the existing files part didn't work).  I managed to get the PPPoE to negotiate a payload of 1500 with my ISP (Snap, NZ) - see log below.

There were a few issues with the transition but a restart of pfSense sorted that out - I also incorrectly put the MTU on the PPPoE configuration page as a first try.  I am using a modem connected to it's own NIC (no VLAN, it is a Realtek RTL8111E port on an APU board).  Setting a MTU of 1500 on the NIC interface configuration seems a bit counter-intuitive (to me) when the interface MTU will be more than that.

Unfortunately that is as far as I can take it with my current ISP on my current plan. The larger frames didn't make it in or out.  I confirmed that my ADSL2 plan doesn't support this with my ISP (and no other technology is available at my address).

If I could get a modem that could do PPPoA with conversion to PPPoE **and** supported PPPoE max payload I might be ok (an end-to-end PPPoE to my ISP is limited to 1492). I have both a Vigor 120v2 and a Cisco 877 as modems. Can anyone recommend workarounds/alternatives/configurations?


Log
Code: [Select]
[wan_link0] PPPoE: Set PPP-Max-Payload to '1500'
[wan_link0] PPPoE: Connecting to ''
PPPoE: rec'd ACNAME "SNAP-08"
[wan_link0] PPPoE: rec'd PPP-Max-Payload '1500'
[wan_link0] PPPoE: connection successful
[wan_link0] Link: UP event
[wan_link0] LCP: Up event
[wan_link0] LCP: state change Starting --> Req-Sent
[wan_link0] LCP: SendConfigReq #1
[wan_link0]   PROTOCOMP
[wan_link0]   MRU 1500
[wan_link0]   MAGICNUM 842207ef


Offline David_W

  • Sr. Member
  • ****
  • Posts: 386
  • Karma: +74/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #5 on: October 04, 2015, 08:37:33 pm »
The scripts didn't quite cut-n-paste from your message (it didn't really matter, but the backup of the existing files part didn't work).
They should work, though they were minimally tested. The sh is crucial as the if... fi syntax is Korn shell, not C shell. The default shell on pfSense is tcsh, whereas my brain only works in Korn shell or bash.

I managed to get the PPPoE to negotiate a payload of 1500 with my ISP (Snap, NZ) - see log below.
Your partial log isn't conclusive over negotiating a 1500 byte MTU, as you truncated the log before the 'LCP: LayerUp' line.

The RFC 4638 PPP-Max-Payload tag was sent and received in the PPPoE discovery phase. In your system where the PPPoE goes no further than your PPPoE <-> PPPoA bridge in the DSL modem, this negotiation is between your pfSense box and the PPPoE endpoint in your modem, not pfSense and your ISP. It might be that the modem is naively including the PPP-Max-Payload tag in PADO and PADS when it has no support for RFC 4638, rather than following the stipulation in section 5 of RFC 2516 (the PPPoE RFC) to ignore unknown tags.

In the LCP phase, your end asked for a 1500 byte MRU, but the extract doesn't say whether that was ACKed or NAKed, also it doesn't show what MRU the remote end asked for and what your end did with that request.

There were a few issues with the transition but a restart of pfSense sorted that out
That's possible, I'm afraid. The code to adjust interface MTUs tried to be intelligent, but there might be some corner cases with raising the PPPoE MTU above 1492 for the first time. /etc/inc/interfaces.inc is a bit of a mess, really - I can only endorse the pfSense team's intention to rewrite pfSense 3.0 from scratch using a language other than PHP.

I also incorrectly put the MTU on the PPPoE configuration page as a first try.  I am using a modem connected to it's own NIC (no VLAN, it is a Realtek RTL8111E port on an APU board).
Raising the MTU in the Advanced part of the PPP settings page will also work so long as you haven't set an explicit MTU on the PPPoE interface of 1492. The MTU setting logic uses the MTU from the PPPoE port if that is set in the Advanced part of the PPP settings, otherwise it uses the MTU set on the PPPoE interface.

It takes fewer steps to set the MTU of the WAN interface to 1500 (Interface -> WAN, set MTU value) than the MTU of the PPP port to 1500 (Interface -> (assign), choose PPP tab, press E next to PPP interface in question, press Advanced, set MTU value).

Setting a MTU of 1500 on the NIC interface configuration seems a bit counter-intuitive (to me) when the interface MTU will be more than that.
I believe it is intuitive. You are setting the MTU of the PPPoE interface, not the MTU of the physical NIC or VLAN over which that PPPoE interface runs (which you should not configure explicitly - in the absence of explicit configuration an attempt will be made to set the parent interface's MTU to 8 bytes more than the PPPoE interface MTU, allowing for the 8 byte PPPoE overhead).

On my setup, igb0 and igb_vlan10 have an MTU of 1508, whereas pppoe0 has an MTU of 1500.

Unfortunately that is as far as I can take it with my current ISP on my current plan. The larger frames didn't make it in or out.  I confirmed that my ADSL2 plan doesn't support this with my ISP (and no other technology is available at my address).

If I could get a modem that could do PPPoA with conversion to PPPoE **and** supported PPPoE max payload I might be ok (an end-to-end PPPoE to my ISP is limited to 1492). I have both a Vigor 120v2 and a Cisco 877 as modems. Can anyone recommend workarounds/alternatives/configurations?
Assuming you have a known good NIC that supports jumbo frames on another machine, such as an Intel device, it would be worth testing that the RTL8111E works correctly with jumbo frames in pfSense or FreeBSD. Realtek chips aren't always the most reliable, though I believe they have got more reliable in recent years.

If you have a switch that supports mirroring, it would be worth capturing a packet trace of what is actually going over the wire between the NIC and the DSL model.


I suspect that the problem is that the PPPoE <-> PPPoA bridge support in your modem does not have working support for RFC 4638 / MTU > 1492 operation. Whilst RFC 4638 can be used in a part ATM part Ethernet scenario (as in the two scenarios in Figure 3 of the RFC, where the backhaul from DSLAM to BRAS is gigabit Ethernet rather than ATM), it is most commonly available to end users on pure IP networks with no legacy ATM.

The easiest solution would be if your ISP supports Ethernet framing over the DSL (which involves switching the modem from ATM to PTM - if this is supported you might need to configure a VLAN tag), though this support is not very likely on ADSL services. In the UK, PTM is used with VDSL2, but almost all ADSL remains ATM.


If you must use ATM, then I think your chances of finding an PPPoE <-> PPPoA bridge supporting RFC 4638 / MTU > 1492 operation are pretty slim. If you can't find such a bridge and your ISP requires you to use ATM / PPPoA, the only way to get MTU 1500 operation is to terminate the PPPoA session on the device with the DSL modem and link to the pfSense box using IP over Ethernet rather than PPPoE. There are various ways to do this, depending on whether you have one dynamic IP address, one static IP address or a routed IP block.

If you have one IP address, 'PPP half bridge' (Google for it) is one approach, leasing the public IP address to the pfSense box using a short DHCP leases (if you happen to have a static public IP address, you can configure pfSense to use static IP for added robustness unless the 'PPP half bridge' requires you to take up the DHCP lease). 1:1 NAT is another approach, though it can be troublesome.

Routed IP is the neatest approach, but it requires a spare public IP address to dedicate to the DSL modem device.

Offline pf3000

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +10/-0
    • View Profile
Working APU1D4
« Reply #6 on: October 05, 2015, 01:18:30 pm »
Tested this patch with apu1d (http://www.pcengines.ch/apu1d4.htm) running nanobsd 2.2.4, and seems to working. This time I set MTU 1500 in the WAN interface setting.

Before
Code: [Select]
[2.2.4-RELEASE][root@pfSense.localdomain]/root: ifconfig re0;ifconfig pppoe0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,LINKSTATE>
        ether 00:0d:b9:33:78:70
        inet6 fe80::20d:b9ff:fe33:7870%re0 prefixlen 64 scopeid 0x1
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex,master>)
        status: active
pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
        inet 208.64.38.204 --> 213.133.104.38 netmask 0xffffffff
        inet6 fe80::20d:b9ff:fe33:7870%pppoe0 prefixlen 64 scopeid 0xa
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

After
Code: [Select]
[2.2.4-RELEASE][root@pfSense.localdomain]/root: ifconfig re0 ; ifconfig pppoe0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1508
        options=82098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
        ether 00:0d:b9:33:78:70
        inet6 fe80::20d:b9ff:fe33:7870%re0 prefixlen 64 scopeid 0x1
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
        inet 208.64.38.116 --> 213.133.104.38 netmask 0xffffffff
        inet6 fe80::20d:b9ff:fe33:7870%pppoe0 prefixlen 64 scopeid 0xa
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

After ping
Code: [Select]
[2.2.4-RELEASE][root@pfSense.localdomain]/root: ping -D -s 1472 8.8.4.4
PING 8.8.4.4 (8.8.4.4): 1472 data bytes
1480 bytes from 8.8.4.4: icmp_seq=0 ttl=51 time=134.734 ms
1480 bytes from 8.8.4.4: icmp_seq=1 ttl=51 time=133.631 ms
1480 bytes from 8.8.4.4: icmp_seq=2 ttl=51 time=133.864 ms
1480 bytes from 8.8.4.4: icmp_seq=3 ttl=51 time=133.571 ms
1480 bytes from 8.8.4.4: icmp_seq=4 ttl=51 time=134.276 ms
^C
--- 8.8.4.4 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 133.571/134.015/134.734/0.436 ms
« Last Edit: October 05, 2015, 01:30:16 pm by pf3000 »

Offline David_W

  • Sr. Member
  • ****
  • Posts: 386
  • Karma: +74/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #7 on: October 06, 2015, 09:24:19 pm »
Tested this patch with apu1d (http://www.pcengines.ch/apu1d4.htm) running nanobsd 2.2.4, and seems to working.
That's good to know. My confidence in the patch is growing. So far, only gregb has failed to get this to work, and that is almost certainly down to his environment (a PPPoE <-> PPPoA bridge rather than end to end PPPoE with explicit RFC 4638 support from the ISP) rather than the patch.

It's notable how many offload features of the apu1d's re0 interface are unavailable in jumbo mode. You lose hardware checksumming and IPv4 TSO. This contrasts with the vmx interface in your other box and the igb interface in my box, both of which lose no offload features in jumbo mode.

Offline David_W

  • Sr. Member
  • ****
  • Posts: 386
  • Karma: +74/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #8 on: October 11, 2015, 10:08:17 am »
I've just submitted pull requests against pfSense 2.3:

mpd5 changes: https://github.com/pfsense/FreeBSD-ports/pull/1
pfSense support: https://github.com/pfsense/pfsense/pull/1959

I have posted pointers to those pull requests on Redmine #4542. Hopefully RFC 4638 client support will appear in a future pfSense 2.3 build.


I have also submitted the mpd5 changes as FreeBSD PR 203695.

Offline David_W

  • Sr. Member
  • ****
  • Posts: 386
  • Karma: +74/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #9 on: November 08, 2015, 06:48:21 am »
I've posted a 2.2.5-RELEASE version of the patch in a new thread (still amd64 full installs only).

Offline M_Devil

  • Jr. Member
  • **
  • Posts: 97
  • Karma: +7/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #10 on: December 15, 2015, 01:08:24 am »
Hi David,

I am looking forward to use the PPPoE MTU > 1492. Using a fiber PPPoE connection and can see the mtu=1492 on the WAN connection.

Using 2.3 snapshot for a few days now and wondering if/when your changes for using MTU > 1492 will hit the 2.3 snapshots.

Offline David_W

  • Sr. Member
  • ****
  • Posts: 386
  • Karma: +74/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #11 on: December 15, 2015, 04:00:53 pm »
All the necessary binary support is in the latest pfSense 2.3 snapshots, but the changes to pfSense itself have not been merged. There is a pull request open at https://github.com/pfsense/pfsense/pull/1959 , which I hope the pfSense team will merge to pfSense 2.3 in due course.

I've not been following pfSense 2.3 that closely in the past few weeks, but if the System Patches package is working, you should be able to install the patch using GitHub's diff feature. In System patches use URL https://patch-diff.githubusercontent.com/raw/pfsense/pfsense/pull/1959.diff with Path Strip Count 2 (not 1 as I earlier said in error) and Base Directory / . This is completely untested, but you're welcome to give it a go.
« Last Edit: December 26, 2015, 05:53:14 am by David_W »

Offline M_Devil

  • Jr. Member
  • **
  • Posts: 97
  • Karma: +7/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #12 on: December 25, 2015, 12:48:38 pm »
I use 2.3 in production environment (home) and I hasitate to go for your sugested solution.
Maybe I create an VM in my lab to test it and if succesfull, I give it a try.

Even better when pfSense team will merge your pull request into the project.

Offline M_Devil

  • Jr. Member
  • **
  • Posts: 97
  • Karma: +7/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #13 on: December 26, 2015, 05:13:29 am »
Tested on 2.3 built on Wed Dec 23 05:35:02 CST 2015 with System patches package

Fetch = ok, testing patch failed.

Patch can NOT be applied cleanly (detail)

/usr/bin/patch --directory=/ -t -p1 -i /var/patches/567e75dbd3c0c.patch --check --forward --ignore-whitespace

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/etc/inc/interfaces.inc b/src/etc/inc/interfaces.inc
|index f7e60a6..8adadc0 100644
|--- a/src/etc/inc/interfaces.inc
|+++ b/src/etc/inc/interfaces.inc
--------------------------
No file to patch.  Skipping...
Hunk #1 ignored at 1851.
Hunk #2 ignored at 1932.
Hunk #3 ignored at 3061.
Hunk #4 ignored at 3081.
Hunk #5 ignored at 3262.
Hunk #6 ignored at 3332.
Hunk #7 ignored at 4644.
7 out of 7 hunks ignored while patching src/etc/inc/interfaces.inc
done



Patch can NOT be reverted cleanly (detail)

/usr/bin/patch --directory=/ -f -p1 -i /var/patches/567e75dbd3c0c.patch --check --reverse --ignore-whitespace

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/etc/inc/interfaces.inc b/src/etc/inc/interfaces.inc
|index f7e60a6..8adadc0 100644
|--- a/src/etc/inc/interfaces.inc
|+++ b/src/etc/inc/interfaces.inc
--------------------------
No file to patch.  Skipping...
Hunk #1 ignored at 1851.
Hunk #2 ignored at 1924.
Hunk #3 ignored at 3047.
Hunk #4 ignored at 3063.
Hunk #5 ignored at 3195.
Hunk #6 ignored at 3228.
Hunk #7 ignored at 4540.
7 out of 7 hunks ignored while patching src/etc/inc/interfaces.inc
done



Offline David_W

  • Sr. Member
  • ****
  • Posts: 386
  • Karma: +74/-0
    • View Profile
Re: RFC 4638 client support (PPPoE MTU > 1492) - testing
« Reply #14 on: December 26, 2015, 05:51:49 am »
Tested on 2.3 built on Wed Dec 23 05:35:02 CST 2015 with System patches package

Fetch = ok, testing patch failed.

Patch can NOT be applied cleanly (detail)

/usr/bin/patch --directory=/ -t -p1 -i /var/patches/567e75dbd3c0c.patch --check --forward --ignore-whitespace

My mistake - path strip count needs to be 2 for 2.3. I've edited my earlier post accordingly.