Todays (14/6) build broke PPPOE-internet connection (FATAL !!)
-
Sorry,
I do not know exactly. build from 3 june was OK, but I think I was runnig the 10 june version.
The actual version I am running is that version "to a certain extend"
By the way I swiched back to PCLAN as Prefix interface, since it was not working, during a test. But not sure that was related.
Perhaps I will try to update ones again. I do not like this "mixed" install. I did download some USB-packages, just to be able to recover, if things go terrible wrong.
Louis
-
Puff,
I did some tests:
- I did a clean install (disk formatted) from the today version pfSense-CE-memstick-2.5.0-DEVELOPMENT-amd64-20200615-0050.img.gz
==> FAILED NO PPPOE - Then I did a clean install (disk formatted) of pfSense-CE-memstick-2.5.0-DEVELOPMENT-amd64-20200611-1250.img.gz
==> That one was still working
So something whent wrong between 20200611 and 20200614 release and it is not fixed in the 20200615 release
As said, FATAL if you are using PPPOE
Louis
- I did a clean install (disk formatted) from the today version pfSense-CE-memstick-2.5.0-DEVELOPMENT-amd64-20200615-0050.img.gz
-
https://redmine.pfsense.org/issues/10597#change-46684 the only thing I see during this period.
Do you have some errors in PPP (Status/System Logs/PPP) connection log when pf can not connect to the internet? It would be good if you can provide both logs for working and non working snapshots. -
Oeps!
I did not realize that there was a separate log for that
Sorry!Hereby the actual log (working connection).
Redoing the test with the not working connection, is significant work ...
Problem is that as far as I know, there is no option for a "A-side" and a "B-side" both having a config (system-version + config) in pfSense
Neither there is a good option to do a fresh install including an existing config. I did a post about that an hour ago triggered by the tests I did today (and same work/issues I had in the past)
https://forum.netgate.com/category/38/general-pfsense-questionsLouis
20200615 pfSensePPPOE_Log_WorkingConnection_SW20200611.txt -
Puff,
I did decide to go back again to todays version in order to fetch the PPPOE log from the not working system. Attached.
At the bottum of the log there is a message "Jun 15 19:27:58 pfSense ppp[27687]: web: web is not running" !!??
20200615 pfSensePPPOE_Log_NotWorkingConnection_SW20200615.txt
Louis
PS I tryed to do an install with a config conform https://docs.netgate.com/pfsense/en/latest/backup/automatically-restore-during-install.html ..... but that did not work
(the usbstick did have a gpt table perhaps was that the problem, whatever stupid) -
I just saw the link to the bug report .... and that the solution was merged 5 days ago ......
so that must be a coincidence
Louis
-
Hmm... I see you have configured service name as
<provider>INTERNET</provider>
Do your ISP really need that? What if you just remove this? I mean in GUI, leave it empty in WAN config or go to Interfaces/Interface Assignments select PPPs tab, remove exciting service name "internet" and tick "Configure NULL service name". Not sure if it helps, most of ISPs just ignores everything in this field, but... -
Hum,
I am not going to do that test,
Because it is noncense, you can easely try it your self and it is very very likely that the problem is caused by the patch installed a couple of days ago.
Louis
-
@louis2
You can then revert this patch manually and test again, if we are talking about "Setting host-uniq for PPPoE" feature patch.
I’m not sure that this patch is the cause of the error, quite possibly some other changes in the kernel. As I said it does not broke PPPoE connection on my firewall and I have very similar connection log, nothing unusual.
Or... just wait for Netgate guys to answer, I hope somebody looking into this thread. -
To be sure that the developer is informed, I did ad a comment to the patch (Feature #10597 Setting host-uniq for PPPoE)
Louis
-
Are you using the host-uniq setting?
There should be no change to the PPPoE config if you are not using that.
I have a couple 2.5.0 systems using PPPoE and they all work, even on current snapshots, and one of them is PPPoE on a VLAN like yours.
What is in
/var/etc/mpd_wan.conf? (you can redact private info, but don't erase it)From the look of your log it's just a timeout, so it could possibly not actually be a PPPoE problem at all but something with the underlying interface.
-
Jim,
Hereby the requested file, as uploaded from my actual system. So the 11/6 version. No reason to assume it differs from the not working kernel.
For info all my physical interfaces (or the lagg) are carrying vlan's (12 in total). Internet itself is also arriving via a vlan (via em0 vlan6).
Note that the PPPOE interface settings did not change during years.
The FW is implemented on a relative fast intel-pentium-pc, having plenty of ram and starting from a small SSD.
The config I am running now is exactly the config I using for the not working instance.
I added the upper-part of my config files (up to where the rule definitions start).
config-pfSense.lan-20200616181031_PW-removed_UpperPart.xml
The config I am running now is exactly the config I using for the not working instance.
Note, that the logs are allready uploaded, but from your reaction I conclude that You allready noticed.
Louis
-
I forgot to explicitly answer your first question.
Are you using the host-uniq setting? The answer is NO.
This is also not possible unless you install the gui patch or have been editing the xml. Could it be that the problem is that there is no entry for that in the config file!!??
Louis
-
Nothing stands out there, either. But it's definitely not related to the host-uniq change since there is no trace of it in your config or the generated MPD config.
There were a lot of other PRs merged on the 10th, all those changes should have been in the snapshot from the 11th. Nothing substantial changed after that in the base system, just syntax fixes.
-
After lots of test and trys I found the problem, I think.
In the WAN interface there is a field MTU, that field was in my case always empty ..... that does not work any longer, at least not in my case!
Setting MTU to 1508 did the job for me. So simple ..... if you know what the problem is ....
Question is why is suddenly required to fill that field.... !!??
However, I am glad I found the problem!
Louis
-
@louis2
That's very strange. Can you provide PPPoE log output again? -
Yep,
It is very strange and so unexpected. Thats the reason it took so long and so much effort to find the problem.
Attached the actual log. Note that I
- did set the MTU to the more common 1500;
- cleared the log;
- disabled the wan;
- enabled the the wan again.
Louis
-
Hmm, I don't know is it ISP related or not, but for me it does not work.
Setting any value into MTU field does not change anything. PPPoE log shows MRU 1492 always. What if you put 1492 manually?
Re-tested. Accidentally put MTU into PPPoE settings, not WAN. Looks like with 1500 it just refuses to connect. -
For info,
At this moment I am running a build from a few hours ago. As soon as I clear the MTU field, I lose connection.
Related to the MTU value, I really do not know what is the best value because:
- the ISP is using / can use VLAN's (adding extra length to the MTU)
- the maximum MTU payload conform spec advise is 1500
- my switches are by default using 1500 (I really do not know if I should read that as 1500 with or without vlan tags!)
- 1500 is more or less the standard / the value supported every where
- however 1500 + vlan headers = 1522
So normally I tend to set the value to "1522" .... however that is probably not optimal for my own switches / not even there ...
I do not even now if the gui field is related to the MTU-pay-load or tot the bruto MTU-size
So, since I did not deep dive in this, for the moment, it go for 1500, however 1492 works as well.
Louis
-
Small addition:
- I just updated to the very latest snapshot, same behavoir
- If I clear the MTU-field when connected, maybe sometimes, the interface seems to stay available for a while,
- when I reboot with an empty MTU-field, I will not have a connection
- as soon as I fill a value in the MTU-field (e.g. 1500) the connection will establisch within a few seconds
Louis
