Getting private/local IP on WAN
-
Ah sorry missed your second post. Try either turning up the view mode to show more detail or download the pcap and open in wireshark. The replies from the PPPoE server might be telling you what's happening.
-
I tried exporting it into wireshark and looks very consistently trying but does get anything
-
Check the Ethernet properties on the replies. Is it tagged in some way?
-
I dont see any tags as far as I know, it's driving me crazy not knowing why it doesn't send back a PADR back after PADO
This is from the PADO coming back
Frame 223: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 21, 2023 01:48:21.525784000 EEST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1695250101.525784000 seconds
[Time delta from previous captured frame: 1.948162000 seconds]
[Time delta from previous displayed frame: 1.948162000 seconds]
[Time since reference or first frame: 278.132417000 seconds]
Frame Number: 223
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:pppoed]
Ethernet II, Src: HuaweiTe_92:75:21 (8c:68:3a:92:75:21), Dst: IntelCor_48:da:98 (00:1b:21:48:da:98)
Destination: IntelCor_48:da:98 (00:1b:21:48:da:98)
Address: IntelCor_48:da:98 (00:1b:21:48:da:98)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: HuaweiTe_92:75:21 (8c:68:3a:92:75:21)
Address: HuaweiTe_92:75:21 (8c:68:3a:92:75:21)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: PPPoE Discovery (0x8863)
PPP-over-Ethernet Discovery
0001 .... = Version: 1
.... 0001 = Type: 1
Code: Active Discovery Offer (PADO) (0x07)
Session ID: 0x0000
Payload Length: 38
PPPoE Tags
Host-Uniq: c0b86a0100f8ffff
AC-Name: RMS-BNG-NE40X8A-04And this is the PADI that I send
Frame 226: 36 bytes on wire (288 bits), 36 bytes captured (288 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 21, 2023 01:48:23.579340000 EEST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1695250103.579340000 seconds
[Time delta from previous captured frame: 0.132140000 seconds]
[Time delta from previous displayed frame: 2.053556000 seconds]
[Time since reference or first frame: 280.185973000 seconds]
Frame Number: 226
Frame Length: 36 bytes (288 bits)
Capture Length: 36 bytes (288 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:pppoed]
[Coloring Rule Name: Broadcast]
[Coloring Rule String: eth[0] & 1]
Ethernet II, Src: IntelCor_48:da:98 (00:1b:21:48:da:98), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: IntelCor_48:da:98 (00:1b:21:48:da:98)
Address: IntelCor_48:da:98 (00:1b:21:48:da:98)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: PPPoE Discovery (0x8863)
PPP-over-Ethernet Discovery
0001 .... = Version: 1
.... 0001 = Type: 1
Code: Active Discovery Initiation (PADI) (0x09)
Session ID: 0x0000
Payload Length: 16
PPPoE Tags
Host-Uniq: 00a8dd0100f8ffff -
@stephenw10 is there any way to override the timeout for waiting for PADO? It seems to timeout every 9 seconds and resend the PADI again & again and the PADO literally arrives 10-11 seconds after the first PADI
️ ️ -
Hmm, that timing seems very odd. I'd expect the server to respond far quicker than that.
There's no config option for that in the gui but you probably can set that via an mpd config option directly. Look in: /var/etc/mpd_wan.conf
If you can find an option that works you can create a custom file for that in /conf.
Steve
-
@stephenw10 said in Getting private/local IP on WAN:
/var/etc/mpd_wan.conf
Yea, I guess my ISP is too slow with its response (kinda expected).
I found a line in the /var/etc/mpd_wan.conf "set link keep-alive 10 60" it's under "create link static wan_link0 pppoe" I think this is the link we're looking for? should edit it to like "30 60"?
should I edit this one? Or there is something I should do to create a new file that overrides this?
-
I tried editing it directly and rebooting so it takes effect but it reverts back to it's default. Any idea how I can workaround this, please? almost there
(tried without reboot and just disconnecting and reconnecting WAN interface in status page but same result)
-
If you copy the file to /conf it will be used in preference to the system generated file.
Also check other config options: https://mpd.sourceforge.net/doc5/mpd.html
-
@stephenw10 ok so I should copy mpd_wan.conf to /conf and edit it there leaving only the line that needs to be overridden in the file correct? just making sure because I tried a couple of things but nothing is enforcing the edit we want. Thank you for all your help Steve.
-
Nope it uses the complete conf file from there so it has to contain everything it did in /var/etc
-
@stephenw10 oh ok thank you, i'll try it out
-
@stephenw10 copied the whole config file and edited it and it is overriding correctly but it's still retrying every 9 seconds after timing out. Might this line be useless for this? if so, what can I edit in it that could override this?
I think this should be available in the GUI as other people might have the same issue too, there are a lot of slow and stupid ISPs.
-
Can anyone help?
-
Yeah, the keep-alive setting probably isn't what you want there, I expect that to apply once the link is up:
This command enables the sending of LCP echo packets on the link. The first echo packet is sent after seconds seconds of quiet time (i.e., no frames received from the peer on that link). After seconds more seconds, another echo request is sent. If after max seconds of doing this no echo reply has been received yet, the link is brought down. -
@stephenw10 what can I do then? there is no way to get PPPoE to work on pfsense then?
-
Well there may be other mpd options there that would help here. I've never tried because I've never seen a PPPoE link that took that long responding.
-
@stephenw10 do you know any other mpd options that might help? it's literally a 3-second difference
-
@aelakkad it connects fine on windows and on the router itself so why does pfsense force 9 seconds when it could be more than that?
-
Without seeing the actual pcap data it's hard to see exactly what the timing is. It look to me like pfSense is sending requests with increasing delays; 2s then 4 s etc. The server sends a response after ~4s nd that restarts pfSense's sequence. So pfSense could be rejecting the response, without logging that for some reason. That could be because it's a response to the first request not the current one.
Try adding:
set debug Xwhere X is 0 by default but can be higher.
