PPPOE wan will not connect -
-
@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.
-
@biggsy yes it is just an unmanaged switch used to split the nbn signal is all. has the usg and the edgerouter connected to it
