RFC 4638 client support (PPPoE MTU > 1492) - testing
-
Sorry, i was incomplete.
Apply patch (both) is succesfull, put putting MTU=1500 on WAN PPPoE interface and reboot still gives MTU=1492 in status->interfaces
-
Checking ifconfig:
em2 (=NIC with 2 vlan's), MTU = 1508
pppoe1 on em2 (=WAN vlan), MTU = 1492From log:
mpd_wan.conf:32: Unknown command: 'set pppoe max-payload 1500'. Try "help". -
Checking ifconfig:
em2 (=NIC with 2 vlan's), MTU = 1508
pppoe1 on em2 (=WAN vlan), MTU = 1492From log:
mpd_wan.conf:32: Unknown command: 'set pppoe max-payload 1500'. Try "help".The RFC 4638 patch is behaving as I expect: configuring the MTU of the parent interface of the PPPoE interface to 8 more than the configured PPPoE MTU (to allow for the 8 byte PPPoE overhead) and setting 'set pppoe max-payload' in the mpd configuration.
The problem is that your mpd5 binary doesn't contain RFC 4638 support. The changes were merged back on 12 October and should have started to appear in snapshots shortly afterwards.
I checked that the necessary binary and kernel support exists in the latest builds of 2.3 by installing pfSense-LiveCD-2.3-ALPHA-amd64-20151228-0402.iso.gz (the latest at the time I tried this) and updating via the GUI. RFC 4638 worked correctly on those binaries.
What does pkg info -o net/mpd5 show (use a shell command prompt)? If the version is mpd5-5.7_4 or above, I'd expect the patch to be present. It definitely is not present in mpd5-5.7_3.
If you only have mpd5-5.7_3, when did you last update your binaries? gitsync only updates the script components, not the binaries. If your binaries are old enough not to include mpd5-5.7_4, then you may well find that an update leaves you with an installation that doesn't work correctly. Your best option in this scenario is probably to back up your config.xml, reinstall pfSense 2.3 from a recent snapshot and restore your config.xml.
-
Command: pkg info -o net/mpd5 shows:
mpd5-5.7_4 net/mpd5
So it should be present?
My last update is by GUI (so also updated binary?) and built on Wed Dec 23 05:35:02 CST 2015
I will update (by GUI) to latest snapshot now, will report back in a few minutes.
-
So, strange thing is:
After update without apply the patch, the log gives:
mpd_wan.conf:29: Error in 'set link mtu 1500': max MTU on type "pppoe" links is 1492But after apply of the patch, the log gives:
mpd_wan.conf:32: Unknown command: 'set pppoe max-payload 1500'. Try "help".What am I doing wrong?
One more test: I will skip your patch PPP IPv6, and only test the RFC 4638 patch.
Will report back in a few minutesEdit: No, same error about unknown command
Edit: I am on remote location now, so I cannot reinstall 2.3 on the moment and restore config.xml. Will try it when I am on location again
-
set pppoe max payload is the correct syntax for PPPoE MTU > 1492. The pfSense patch was working correctly before you uninstalled it - the problem was that mpd5 and/or the kernel on your system did not have working RFC 4638 support. You need the pfSense patch to ensure the parent interface MTU is set correctly and to ensure the correct mpd5 configuration syntax is used.
mpd5-5.7_4 is built using the RFC 4638 patch, but the resulting mpd5 binary will only support RFC 4638 if it was built on a machine with the RFC 4638 kernel patch installed. Unknown command: 'set pppoe max-payload 1500'. Try "help". implies that your mpd5-5.7_4 was built on a machine without the kernel patch.
If you don't want to try a total reinstall, try:
pkg upgrade -f net/mpd5and answer y when asked. This should reinstall mpd5 from the pfSense-core repository (at the time of writing, this is identical to the version I tested and confirmed to be working earlier today assuming that you are using amd64).
If that doesn't give you working RFC 4638 support, try an Upgrade from the pfSense GUI, which should install the latest kernel - though back up your config.xml first. As I said earlier, an upgrade on a system that is too old might leave you with an unusable mess that you have to reinstall.
-
pkg upgrade -f net/mpd5 did the trick. :D
Indeed the pkg upgrade ask for reinstall and then it worked!
Thank you for your support!
Will report back if this is stable.
-
It's good to know that a forced reinstall of mpd5 was sufficient to resolve your issue, as that might help others. If anyone else has a similar problem, I suggest pkg upgrade -fy net/mpd5 (the additional y means there's no confirmation required, so the command will work from the 'Execute shell command' part of Diagnostics -> Command Prompt).
The PPP log should indicate whether you successfully negotiated an MTU of 1500. To test whether MTU 1500 is working, try ping -D -s 1472 -c 10 8.8.4.4
If things are working correctly, you'll successfully send 10 1500 byte packets (1472 byte payload, 8 byte ICMP overhead and 20 byte IPv4 overhead) to Google DNS, and Google DNS will send 10 back. You can experiment with another destination instead of 8.8.4.4.
If things are not working correctly, you'll get packet loss and/or complaints about 'frag needed and DF set'.
The IPv6 test, if you have native IPv6 support, is ping6 -D -s 1452 -c 10 www.google.com
In this case, you send 1500 byte packets (1452 byte payload, 8 bytes ICMPv6 overhead and 40 byte IPv6 overhead) and the remote end sends 72 bytes back - that's the way that ICMPv6 echo request and reply works.
-
Edit: Seems IPv4 is using my VPN connection. Dont know how to initiate ping from 'normal' WAN connection. Trying to sort it outNot sure, IPv4 gives error about wrong total length, IPv6 look ok.
IPv4 ping test
ping -D -s 1472 -c 10 8.8.4.4
PING 8.8.4.4 (8.8.4.4): 1472 data bytes
72 bytes from 8.8.4.4: icmp_seq=0 ttl=50 time=9.585 ms
wrong total length 92 instead of 1500
72 bytes from 8.8.4.4: icmp_seq=1 ttl=50 time=14.571 ms
wrong total length 92 instead of 1500
72 bytes from 8.8.4.4: icmp_seq=2 ttl=50 time=11.723 ms
wrong total length 92 instead of 1500
72 bytes from 8.8.4.4: icmp_seq=3 ttl=50 time=11.371 ms
wrong total length 92 instead of 1500
72 bytes from 8.8.4.4: icmp_seq=4 ttl=50 time=12.727 ms
wrong total length 92 instead of 1500
72 bytes from 8.8.4.4: icmp_seq=5 ttl=50 time=10.302 ms
wrong total length 92 instead of 1500
72 bytes from 8.8.4.4: icmp_seq=6 ttl=50 time=10.242 ms
wrong total length 92 instead of 1500
72 bytes from 8.8.4.4: icmp_seq=7 ttl=50 time=9.858 ms
wrong total length 92 instead of 1500
72 bytes from 8.8.4.4: icmp_seq=8 ttl=50 time=13.165 ms
wrong total length 92 instead of 1500
72 bytes from 8.8.4.4: icmp_seq=9 ttl=50 time=11.564 ms
wrong total length 92 instead of 1500–- 8.8.4.4 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.585/11.511/14.571/1.522 msIPv6 ping test
ping6 -D -s 1452 -c 10 www.google.com
PING6(1500=40+8+1452 bytes) 2001:984:XXX:X:XXXX:XXXX:XXXX:XXXX–> 2a00:1450:4013:c01::6a
72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=0 hlim=56 time=7.557 ms
72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=1 hlim=56 time=7.748 ms
72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=2 hlim=56 time=7.806 ms
72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=3 hlim=56 time=7.651 ms
72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=4 hlim=56 time=7.720 ms
72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=5 hlim=56 time=7.801 ms
72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=6 hlim=56 time=7.736 ms
72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=7 hlim=56 time=7.717 ms
72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=8 hlim=56 time=7.772 ms
72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=9 hlim=56 time=7.590 ms--- www.google.com ping6 statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 7.557/7.710/7.806/0.081 msOnline MTU check on http://www.letmecheck.it/mtu-test.php gives good IPv4 en IPv6 MTU (1500)
-
Not sure, IPv4 gives error about wrong total length, IPv6 look ok.
All wrong total length 92 instead of 1500 means is that the Google server handling traffic to 8.8.4.4 in your location is configured to respond with shorter packets than 1500 bytes. Try some different destinations by IP address or DNS name. Hopefully you'll find something that responds with 1500 bytes.
The server you are reading this on:
-
responds to ping -D -s 1472 -c 10 forum.pfsense.org with 1480 bytes (1500 bytes when you add in the 20 byte IPv4 header)
-
responds to ping6 -D -s 1452 -c 10 forum.pfsense.org with 1460 bytes (1500 bytes when you add in the 40 byte IPv6 header)
Everything else you posted is as expected.
-
-
Yes, that is it!
_ping -D -s 1472 -c 10 forum.pfsense.org
PING forum.pfsense.org (208.123.73.18): 1472 data bytes 1480 bytes from 208.123.73.18: icmp_seq=0 ttl=49 time=116.153 ms 1480 bytes from 208.123.73.18: icmp_seq=1 ttl=49 time=114.547 ms 1480 bytes from 208.123.73.18: icmp_seq=2 ttl=49 time=113.842 ms 1480 bytes from 208.123.73.18: icmp_seq=3 ttl=49 time=114.175 ms 1480 bytes from 208.123.73.18: icmp_seq=4 ttl=49 time=115.382 ms 1480 bytes from 208.123.73.18: icmp_seq=5 ttl=49 time=115.378 ms 1480 bytes from 208.123.73.18: icmp_seq=6 ttl=49 time=115.167 ms 1480 bytes from 208.123.73.18: icmp_seq=7 ttl=49 time=114.280 ms 1480 bytes from 208.123.73.18: icmp_seq=8 ttl=49 time=113.387 ms 1480 bytes from 208.123.73.18: icmp_seq=9 ttl=49 time=114.075 ms–- forum.pfsense.org ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 113.387/114.639/116.153/0.809 ms_ -
Tested and working on 2.3. I used the patch in post 11 and the most recent build.
ping -D -s 1472 -c 3 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=52 time=115.295 ms 1480 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=115.393 ms 1480 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=115.577 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 115.295/115.422/115.577/0.117 ms(PPP log in reverse order)
Jan 4 10:46:33 ppp [wan] IFACE: Rename interface ng0 to pppoe0 Jan 4 10:46:33 ppp [wan] IFACE: Up event Jan 4 10:46:32 ppp [wan] 2.3.4.5 -> 1.1.1.1 Jan 4 10:46:32 ppp [wan] IPCP: LayerUp Jan 4 10:46:32 ppp [wan] IPCP: state change Ack-Sent --> Opened Jan 4 10:46:32 ppp [wan] SECDNS 2.2.2.2 Jan 4 10:46:32 ppp [wan] PRIDNS 3.3.3.3 Jan 4 10:46:32 ppp [wan] IPADDR 2.3.4.5 Jan 4 10:46:32 ppp [wan] IPCP: rec'd Configure Ack #3 (Ack-Sent) Jan 4 10:46:32 ppp [wan] SECDNS 2.2.2.2 Jan 4 10:46:32 ppp [wan] PRIDNS 3.3.3.3 Jan 4 10:46:32 ppp [wan] IPADDR 2.3.4.5 Jan 4 10:46:32 ppp [wan] IPCP: SendConfigReq #3 Jan 4 10:46:32 ppp [wan] SECDNS 2.2.2.2 Jan 4 10:46:32 ppp [wan] PRIDNS 3.3.3.3 Jan 4 10:46:32 ppp [wan] 2.3.4.5 is OK Jan 4 10:46:32 ppp [wan] IPADDR 2.3.4.5 Jan 4 10:46:32 ppp [wan] IPCP: rec'd Configure Nak #2 (Ack-Sent) Jan 4 10:46:32 ppp [wan] IPV6CP: LayerFinish Jan 4 10:46:32 ppp [wan] IPV6CP: state change Req-Sent --> Stopped Jan 4 10:46:32 ppp [wan] IPV6CP: protocol was rejected by peer Jan 4 10:46:32 ppp [wan_link0] LCP: protocol IPV6CP was rejected Jan 4 10:46:32 ppp [wan_link0] LCP: rec'd Protocol Reject #63 (Opened) Jan 4 10:46:32 ppp [wan] SECDNS 0.0.0.0 Jan 4 10:46:32 ppp [wan] PRIDNS 0.0.0.0 Jan 4 10:46:32 ppp [wan] IPADDR 0.0.0.0 Jan 4 10:46:32 ppp [wan] IPCP: SendConfigReq #2 Jan 4 10:46:32 ppp [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jan 4 10:46:32 ppp [wan] IPCP: rec'd Configure Reject #1 (Ack-Sent) Jan 4 10:46:32 ppp [wan] IPCP: state change Req-Sent --> Ack-Sent Jan 4 10:46:32 ppp [wan] IPADDR 1.1.1.1 Jan 4 10:46:32 ppp [wan] IPCP: SendConfigAck #173 Jan 4 10:46:32 ppp [wan] 1.1.1.1 is OK Jan 4 10:46:32 ppp [wan] IPADDR 1.1.1.1 Jan 4 10:46:32 ppp [wan] IPCP: rec'd Configure Request #173 (Req-Sent) Jan 4 10:46:32 ppp [wan] IPV6CP: SendConfigReq #1 Jan 4 10:46:32 ppp [wan] IPV6CP: state change Starting --> Req-Sent Jan 4 10:46:32 ppp [wan] IPV6CP: Up event Jan 4 10:46:32 ppp [wan] SECDNS 0.0.0.0 Jan 4 10:46:32 ppp [wan] PRIDNS 0.0.0.0 Jan 4 10:46:32 ppp [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jan 4 10:46:32 ppp [wan] IPADDR 0.0.0.0 Jan 4 10:46:32 ppp [wan] IPCP: SendConfigReq #1 Jan 4 10:46:32 ppp [wan] IPCP: state change Starting --> Req-Sent Jan 4 10:46:32 ppp [wan] IPCP: Up event Jan 4 10:46:32 ppp [wan] IPV6CP: LayerStart Jan 4 10:46:32 ppp [wan] IPV6CP: state change Initial --> Starting Jan 4 10:46:32 ppp [wan] IPV6CP: Open event Jan 4 10:46:32 ppp [wan] IPCP: LayerStart Jan 4 10:46:32 ppp [wan] IPCP: state change Initial --> Starting Jan 4 10:46:32 ppp [wan] IPCP: Open event Jan 4 10:46:32 ppp [wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps Jan 4 10:46:32 ppp [wan_link0] Link: Join bundle "wan" Jan 4 10:46:32 ppp [wan_link0] Link: Matched action 'bundle "wan" ""' Jan 4 10:46:32 ppp [wan_link0] LCP: authorization successful Jan 4 10:46:32 ppp [wan_link0] MESG: Login ok Jan 4 10:46:32 ppp [wan_link0] PAP: rec'd ACK #1 len: 13 Jan 4 10:46:31 ppp [wan_link0] LCP: LayerUp Jan 4 10:46:31 ppp [wan_link0] PAP: sending REQUEST #1 len: 22 Jan 4 10:46:31 ppp [wan_link0] PAP: using authname "xxxxxxx" Jan 4 10:46:31 ppp [wan_link0] LCP: auth: peer wants PAP, I want nothing Jan 4 10:46:31 ppp [wan_link0] LCP: state change Ack-Sent --> Opened Jan 4 10:46:31 ppp [wan_link0] MAGICNUM 17677400 Jan 4 10:46:31 ppp [wan_link0] MRU 1500 Jan 4 10:46:31 ppp [wan_link0] LCP: rec'd Configure Ack #2 (Ack-Sent) Jan 4 10:46:31 ppp [wan_link0] MAGICNUM 17677400 Jan 4 10:46:31 ppp [wan_link0] MRU 1500 Jan 4 10:46:31 ppp [wan_link0] LCP: SendConfigReq #2 Jan 4 10:46:31 ppp [wan_link0] PROTOCOMP Jan 4 10:46:31 ppp [wan_link0] LCP: rec'd Configure Reject #1 (Ack-Sent) Jan 4 10:46:31 ppp [wan_link0] LCP: state change Req-Sent --> Ack-Sent Jan 4 10:46:31 ppp [wan_link0] MAGICNUM 4413e422 Jan 4 10:46:31 ppp [wan_link0] AUTHPROTO PAP Jan 4 10:46:31 ppp [wan_link0] MRU 1500 Jan 4 10:46:31 ppp [wan_link0] LCP: SendConfigAck #62 Jan 4 10:46:31 ppp [wan_link0] MAGICNUM 4413e422 Jan 4 10:46:31 ppp [wan_link0] AUTHPROTO PAP Jan 4 10:46:31 ppp [wan_link0] MRU 1500 Jan 4 10:46:31 ppp [wan_link0] LCP: rec'd Configure Request #62 (Req-Sent) Jan 4 10:46:31 ppp [wan_link0] MAGICNUM 17677400 Jan 4 10:46:31 ppp [wan_link0] MRU 1500 Jan 4 10:46:31 ppp [wan_link0] PROTOCOMP Jan 4 10:46:31 ppp [wan_link0] LCP: SendConfigReq #1 Jan 4 10:46:31 ppp [wan_link0] LCP: state change Starting --> Req-Sent Jan 4 10:46:31 ppp [wan_link0] LCP: Up event Jan 4 10:46:31 ppp [wan_link0] Link: UP event Jan 4 10:46:31 ppp [wan_link0] PPPoE: connection successful Jan 4 10:46:31 ppp [wan_link0] PPPoE: rec'd PPP-Max-Payload '1500' Jan 4 10:46:31 ppp PPPoE: rec'd ACNAME "AL301" Jan 4 10:46:31 ppp [wan_link0] PPPoE: Connecting to 'any' Jan 4 10:46:31 ppp [wan_link0] PPPoE: Set PPP-Max-Payload to '1500' Jan 4 10:46:31 ppp [wan_link0] LCP: LayerStart Jan 4 10:46:31 ppp [wan_link0] LCP: state change Initial --> Starting Jan 4 10:46:31 ppp [wan_link0] LCP: Open event Jan 4 10:46:31 ppp [wan_link0] Link: OPEN event Jan 4 10:46:31 ppp [wan] Bundle: Interface ng0 created Jan 4 10:46:31 ppp web: web is not running Jan 4 10:46:31 ppp process 4843 started, version 5.7 (root@pfSense_master_amd64_amd64-pfSense_master-job-01 19:14 31-Dec-2015) Jan 4 10:46:31 ppp Multi-link PPP daemon for FreeBSD -
RFC 4638 support has now been merged into pfSense 2.3 and should show up in snapshots shortly.
-
Great, so if it is available in snapshot, I can delete your RFC 4638 patch.
But I guess we still need your PPP IPv6 fix to get an initial IPv6 connection, right?
-
You'll need to wait a few more hours before the RFC 4638 patch is in the latest snapshot and upgrades - there is a time lag between code being committed and that code being built and offered for download.
I've just reworked the PPP IPv6 patch into what I hope is a final version - I'll post more about that in the IPv6 forum thread shortly. If the latest version of that patch behaves correctly, I'll submit a pull request in the hope that that, too, will be merged into pfSense.
-
I just updated my amd64 pfSense 2.3 virtual machine to 2.3.a.20160105.0522, which includes the RFC 4638 functionality. I would expect i386 to catch up shortly if it has not already done so.
I've just posted a proper 2.3 version of the PPP IPv6 patch - I'd appreciate if you can test that and feed back in the other thread.
-
Will test this evening (in about 5 hours).
You mention version: 2.3.a.20160105.0522, but I see 2.3.a.20160105.0524, I assume this is the same version
Will report back about result of test
-
You mention version: 2.3.a.20160105.0522, but I see 2.3.a.20160105.0524, I assume this is the same version
That's strange - I copied and pasted that string from somewhere, but when I went back to check it, I also saw 2.3.a.20160105.0524.
There is already a later build - 2.3 is rebuilt around every three hours at the moment.
-
2.3 is now BETA!
Removed RFC 4638 patch.
Updated to pfSense from 2.3.a to
2.3-BETA (amd64)
built on Tue Jan 05 13:19:26 CST 2016
FreeBSD 10.2-STABLERefetched and applied PPP IPv6 fix and rebooted.
MTU=1500 en instant IPv6 access. Looking good, have to wait if stable.
edit: Please go ahead for pull request!
Your effort paid off, thank you so much David_W!