PPPOE wan will not connect -
-
@gerryatric said in PPPOE wan will not connect -:
see attached syslog pfsense.txt
In your log, here :
192.168.200.3 Sep 14 12:01:20 ntp info ntpd[99177] Listen normally on 36 pppoe0 118.208.207.22:123 192.168.200.3 Sep 14 12:01:20 ntp info ntpd[99177] Listen normally on 37 pppoe0 [fe80::215:17ff:febf:f4cc%8]:123Just before these two lines there is the perfect sequence of a goed pppoe connection.
You have your IP, gateway, DNS assigned. All look fine.Right after that, 'dpinger' is set up with the new WANPPPOE parameters.
And then : not one single ping test goes well. ping or ICMP just doesn't pas.
It might as well be that dpinger is pulling the plug, as by default, it restarts the connection if 'ping' because bad or none of them are returning.What have you set up here : show this page : System > Routing > Gateways ? Is there a default IPv4 and IPv6 gateway ? (bottom of the page)
-
@gertjan Hi here is the snapshot of the gateways page
-
Ok, that corresponds.
The logs say that 'non' is available, and that WAN_PPPOE is chosen.
You might as well remove the automatic choice, and select WAN_PPPOE right away.Like this :
( Mine is WAN_DHCP, I don't have WAN_PPPOE).
These lines shouldn't show up any more :
192.168.200.3 Sep 14 12:01:22 daemon err php-fpm[24661] /rc.newwanip: Gateway, none 'available' for inet, use the first one configured. 'WAN_PPPOE' 192.168.200.3 Sep 14 12:01:22 daemon err php-fpm[24661] /rc.newwanip: Default gateway setting Interface WAN_PPPOE Gateway as default. 192.168.200.3 Sep 14 12:01:22 daemon err php-fpm[24661] /rc.newwanip: Gateway, none 'available' for inet6, use the first one configured. '' 192.168.200.3 Sep 14 12:01:22 daemon err php-fpm[24661] /rc.newwanip: IP Address has changed, killing states on former IP Address 124.171.220.193. 192.168.200.3 Sep 14 12:01:24 daemon err php-fpm[33476] /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_PPPOE' 192.168.200.3 Sep 14 12:01:24 daemon err php-fpm[33476] /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''( these are not errors, though )
What I presume :
The PPPOE connection works and negotiates all the needed parameters.
The issue now is : 'nothing' passes over the connection - that is ping or ICMP packets don't come back. That's not a good sign.
Try this : Go here and make settings look like :
Now dpinger won't test your connection any more, neither have interaction with it.
When the connection fails, there is probably a "5 minutes time out" on the ISP side, and this explains the many retries of a connection as pfSense tries to re establish to fast - doesn't wait for "5 minutes". Not a real issue, the "5 minutes" is there to protect the ISP authentication servers.
-
@gerryatric ok yes I followed those details.
now the logs are fairly cleanSep 14 19:29:14 syslogd sendto: Host is down
Sep 14 19:29:13 syslogd sendto: Host is down
Sep 14 19:29:13 ppp 98339 [wan_link0] PPPoE: Connecting to 'IINET'
Sep 14 19:29:13 syslogd sendto: Host is down
Sep 14 19:29:13 syslogd sendto: Host is down
Sep 14 19:29:13 ppp 98339 [wan_link0] Link: reconnection attempt 105
Sep 14 19:29:13 syslogd sendto: Host is down
Sep 14 19:29:11 syslogd sendto: Host is down
Sep 14 19:29:10 syslogd sendto: Host is down
Sep 14 19:29:10 ppp 98339 [wan_link0] Link: reconnection attempt 105 in 3 seconds
Sep 14 19:29:10 syslogd sendto: Host is down
Sep 14 19:29:10 syslogd sendto: Host is down
Sep 14 19:29:10 ppp 98339 [wan_link0] LCP: Down event
Sep 14 19:29:10 syslogd sendto: Host is down
Sep 14 19:29:10 syslogd sendto: Host is down
Sep 14 19:29:10 ppp 98339 [wan_link0] Link: DOWN event
Sep 14 19:29:10 syslogd sendto: Host is down
Sep 14 19:29:10 syslogd sendto: Host is down
Sep 14 19:29:10 ppp 98339 [wan_link0] PPPoE connection timeout after 9 seconds -
Try removing the Service name "IINET".
-
@biggsy did that before. no luck
-
@biggsy said in PPPOE wan will not connect -:
Try removing the Service name "IINET".
See the log file above.
Search for that one moment where everything goes well : "bri-apt-wic-bras207".
pfSense sends always the same data, but the connection doesn't come up often.
And if it comes up, and 'identification' works out well (so : all local settings are ok !!) then connection is dropped right after tat moment.Way back, their was the hard core PPPOE connect method :
Shut down everything.
Start the modem - and wait for at least 5 minutes.
Now start pfSense.
If that doesn't work.
Shut down everything.
Wait for 24 houres (I know ... it's just a test)
Now start modem and wait at least 5 minutes.
Start pfSense.The thing that bothers that : why some other device can connect ?
And did you test this : your PC can also do 'PPPoE' : select that type of connection, connect the PC to the modem, and check if it connects. -
Were you able to get a connection log from either of the other devices that can connect?
-
@gertjan Hi Steve. Sorry for delay.
Was trying to get a fresh perspective on all of the issues.
I have done what you suggested above. no change except the log files shrank to up and down mostly :) over and over again.
I even tried spoofing the mac address on the Wan interface and no luck
If I change it from PPPOE to DHCP, I get a green Wan interface immediately with 0.0.0.0 as an IP. obviously because there is no authentication happening there.
I am not sure what else to try here.
Fresh installs, changes, guides, forums, I am stumped.
Why is it so difficult., When the USG PRO just works -
@gerryatric said in PPPOE wan will not connect -:
When the USG PRO just works
Can you get by any chance from the USG a connect log that shows how the USG makes the connection? That might be helpful.
-
@gerryatric said in PPPOE wan will not connect -:
When the USG PRO just works
Then I repeat :
@stephenw10 said in PPPOE wan will not connect -:
Were you able to get a connection log from either of the other devices that can connect?
Or this one :
@stephenw10 said in PPPOE wan will not connect -:
Check the ppp logs in the ER or any other router that does connect.
For example :
-
I just found something over on Whirlpool that suggests setting an MTU of 1500 and disabling VJ compression (Interfaces > PPPs > Edit, Advanced Options).
The poster then edited to say an MTU of 1500 was enough.
-
Mmm, easy test at least.
-
@biggsy Hi
Same issue. that didn't do anything either sadly -
@gerryatric The MTU setting on my Wan port on the USG is 1440
Apparently it needed to be lower to get the speed up.
When I first connected I had 1492 in .
I couldn't get above 200mbps.
So I rang IINEt and to get Ultrafast speed on fibre, you need to lower the MTU. They gave me a couple numbers and 1440 worked the best. -
The MTU when using pppoe, in the inside, can never be 1500.
Classic pppoe is 1472 or something close to that.
Yours is encapsed in a VLAN, so even less ?
Dono what an MRU is.Btw : you can determine what the best value is :
ping with a given packet size (the default is 60 bytes so it always passes) - and check the answers for 'fragmentation'.
Repeat the test, start at 1400, and add 4 on every next test.
As soon as 'fragmented comes back, you found your MTU value.
There are many how-to available on the net.This test needs a working connection, of course.
-
@gertjan yep I did that with IINEt when setting up the USG, we deduced that 1440 was the best settings with the ping.
That still doesn't explain why it won't connect though. -
In your earlier logs, just after the ntp lines @Gertjan referenced, there is this sequence:
192.168.200.3 Sep 14 12:01:18 daemon info ppp[52996] [wan] 118.208.207.22 -> 10.20.26.62 192.168.200.3 Sep 14 12:01:18 daemon info ppp[52996] [wan] 118.208.207.22 -> 10.20.26.62 192.168.200.3 Sep 14 12:01:19 user notice check_reload_status[374] rc.newwanip starting pppoe0 192.168.200.3 Sep 14 12:01:19 daemon info ppp[52996] [wan] IFACE: Up event 192.168.200.3 Sep 14 12:01:19 daemon info ppp[52996] [wan] IFACE: Up event 192.168.200.3 Sep 14 12:01:19 daemon info ppp[52996] [wan] IFACE: Rename interface ng0 to pppoe0 192.168.200.3 Sep 14 12:01:19 daemon info ppp[52996] [wan] IFACE: Rename interface ng0 to pppoe0 192.168.200.3 Sep 14 12:01:20 ntp info ntpd[99177] Listen normally on 36 pppoe0 118.208.207.22:123 192.168.200.3 Sep 14 12:01:20 ntp info ntpd[99177] Listen normally on 37 pppoe0 [fe80::215:17ff:febf:f4cc%8]:123 192.168.200.3 Sep 14 12:01:20 daemon err php-fpm[24661] /rc.newwanip: rc.newwanip: Info: starting on pppoe0. 192.168.200.3 Sep 14 12:01:20 daemon err php-fpm[24661] /rc.newwanip: rc.newwanip: on (IP address: 118.208.207.22) (interface: WAN[wan]) (real interface: pppoe0). 192.168.200.3 Sep 14 12:01:20 user warning dpinger[93646] send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 10.20.26.62 bind_addr 118.208.207.22 identifier "WAN_PPPOE " 192.168.200.3 Sep 14 12:01:22 user warning dpinger[93646] WAN_PPPOE 10.20.26.62: Alarm latency 0us stddev 0us loss 100% 192.168.200.3 Sep 14 12:01:22 daemon info rc.gateway_alarm[95871] >>> Gateway alarm: WAN_PPPOE (Addr:10.20.26.62 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%) 192.168.200.3 Sep 14 12:01:22 user notice check_reload_status[374] updating dyndns WAN_PPPOEI'm just wondering where that 10.20.26.62 might have come from. Not something I'd expect iiNet to set.
Could that be one of your home subnets?
Edit: Or are you perhaps running a PPPoE server on your USG or ER?
-
@biggsy Hi Phil
I have no idea where that is coming from. It isn't there immediately.
I have no gear on the local lan producing a 10.20.26.0 range at all
I am running ZeroTier SD Wan software on some of my nodes but that is machine dependent. must have a client installed. and it is not in that range anyway.
I do not know where that is coming from -
I think we need to find what's handing out that RFC1918 address. That looks like it's totally confusing PPPoE on your WAN.
Maybe a port mirror on the SR2024 and packet capture would tell us. I can't help with the Cisco stuff, unfortunately.Maybe not. Seems the SR2024 is unmanaged.
