hhf/pfatt
1
0
Fork 0
Code Issues 26 Pull requests Projects Releases Packages Wiki Activity Actions

Struggling after 2.5 upgrade #51

New issue
Open
opened 2021-03-10 01:38:39 +05:30 by Frick · 10 comments
Frick commented 2021-03-10 01:38:39 +05:30 (Migrated from github.com)
Copy link

I had this working in bypass mode for more than a year previously, but after upgrading to 2.5 I've been unable to get it working again on a couple occasions. There's only so much time I can spend debugging with the internet down. 😬 Hoping someone here can help since everything seems set up correctly, but EAP simply fails to authenticate. I'm currently running in IP passthrough on the gateway (BGW210).

Setup:

  • em0 is ONT
  • em1 is LAN
  • em2 is unused
  • em3 is RG

netgraph
image

tcpdump

I should have opened multiple terminals to dump the interfaces simultaneously for a clearer picture, but I think this gets the point across. The behavior seen below is exactly what happens in a ~30s loop. Of note - I don't know where this Thompson Telecom MAC address (00:90:d0:<snip>) is coming from since all of the NICs are Intel and there's nothing with that MAC in the path that I can tell (though I don't know the ONT's MAC).

RG

[2.5.0-RELEASE][admin@pfsense]/root: tcpdump -ei em3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em3, link-type EN10MB (Ethernet), capture size 262144 bytes
01:00:50.415180 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
01:01:04.566238 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL logoff (2) v2, len 0
01:01:04.566361 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
01:01:04.568231 00:90:d0:<snip> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 4
01:01:04.568238 00:90:d0:<snip> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
01:01:04.568478 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15

01:01:34.808218 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
01:01:34.810234 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15

01:02:04.138763 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
01:02:06.033682 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
01:02:06.035428 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
^C
11 packets captured

ONT

[2.5.0-RELEASE][admin@pfsense]/root: tcpdump -ei em0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:52:31.390323 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
00:52:33.151561 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
00:52:33.153567 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
00:52:40.001315 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:52:42.044655 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:52:45.011275 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:52:50.002502 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

ngeth0

[2.5.0-RELEASE][admin@pfsense]/root: tcpdump -ei ngeth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ngeth0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:56:02.021988 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:56:10.610531 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15
00:56:11.735256 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15
00:56:28.126180 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:56:30.101038 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:56:33.006751 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:56:37.002348 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:56:41.917670 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15
00:56:42.959443 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15
00:56:45.043872 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

pfatt.sh logs
(prefix removed for brevity)

pfSense + AT&T U-verse Residential Gateway for true bridge mode
Configuration: 
       ONT_IF: em0
        RG_IF: em3
RG_ETHER_ADDR: <RG MAC>
attaching interfaces to ng_ether... OK!
building netgraph nodes...
  creating ng_one2many... OK!
  creating vlan node and interface... OK!
  defining etf for em0 (ONT)... OK!
  defining etf for em3 (RG)... OK!
  bridging etf for em0 <-> em3... OK!  
  defining filters for EAP traffic... OK!
  enabling one2many links... OK!
  removing waneapfilter:nomatch hook... OK!
enabling em3 interface... OK!
enabling em0 interface... OK!
enabling promiscuous mode on em3... OK!
enabling promiscuous mode on em0... OK!
ngeth0 should now be available to configure as your pfSense WAN
done!

Any help or similar experiences would be greatly appreciated! I'm kind of at a loss as to why it's not working, but also not 100% sure on exactly what traffic should or should not be tagged vlan 0 (primarily in regards to EAP).

I had this working in bypass mode for more than a year previously, but after upgrading to 2.5 I've been unable to get it working again on a couple occasions. There's only so much time I can spend debugging with the internet down. :grimacing: Hoping someone here can help since everything _seems_ set up correctly, but EAP simply fails to authenticate. I'm currently running in IP passthrough on the gateway (BGW210). **Setup:** - `em0` is ONT - `em1` is LAN - `em2` is unused - `em3` is RG **netgraph** ![image](https://user-images.githubusercontent.com/504360/110528511-38e07680-80e6-11eb-9364-86fff0ff27fd.png) **tcpdump** I should have opened multiple terminals to dump the interfaces simultaneously for a clearer picture, but I think this gets the point across. The behavior seen below is exactly what happens in a ~30s loop. Of note - I don't know where this Thompson Telecom MAC address (`00:90:d0:<snip>`) is coming from since all of the NICs are Intel and there's nothing with that MAC in the path that I can tell (though I don't know the ONT's MAC). **RG** ``` [2.5.0-RELEASE][admin@pfsense]/root: tcpdump -ei em3 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em3, link-type EN10MB (Ethernet), capture size 262144 bytes 01:00:50.415180 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15 01:01:04.566238 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL logoff (2) v2, len 0 01:01:04.566361 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0 01:01:04.568231 00:90:d0:<snip> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 4 01:01:04.568238 00:90:d0:<snip> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15 01:01:04.568478 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15 01:01:34.808218 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0 01:01:34.810234 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15 01:02:04.138763 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15 01:02:06.033682 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0 01:02:06.035428 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15 ^C 11 packets captured ``` **ONT** ``` [2.5.0-RELEASE][admin@pfsense]/root: tcpdump -ei em0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes 00:52:31.390323 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15 00:52:33.151561 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0 00:52:33.153567 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15 00:52:40.001315 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300 00:52:42.044655 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300 00:52:45.011275 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300 00:52:50.002502 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300 ^C 7 packets captured 7 packets received by filter 0 packets dropped by kernel ``` **ngeth0** ``` [2.5.0-RELEASE][admin@pfsense]/root: tcpdump -ei ngeth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ngeth0, link-type EN10MB (Ethernet), capture size 262144 bytes 00:56:02.021988 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300 00:56:10.610531 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15 00:56:11.735256 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15 00:56:28.126180 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300 00:56:30.101038 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300 00:56:33.006751 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300 00:56:37.002348 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300 00:56:41.917670 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15 00:56:42.959443 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15 00:56:45.043872 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel ``` **pfatt.sh logs** (prefix removed for brevity) ``` pfSense + AT&T U-verse Residential Gateway for true bridge mode Configuration: ONT_IF: em0 RG_IF: em3 RG_ETHER_ADDR: <RG MAC> attaching interfaces to ng_ether... OK! building netgraph nodes... creating ng_one2many... OK! creating vlan node and interface... OK! defining etf for em0 (ONT)... OK! defining etf for em3 (RG)... OK! bridging etf for em0 <-> em3... OK! defining filters for EAP traffic... OK! enabling one2many links... OK! removing waneapfilter:nomatch hook... OK! enabling em3 interface... OK! enabling em0 interface... OK! enabling promiscuous mode on em3... OK! enabling promiscuous mode on em0... OK! ngeth0 should now be available to configure as your pfSense WAN done! ``` Any help or similar experiences would be greatly appreciated! I'm kind of at a loss as to why it's not working, but also not 100% sure on exactly what traffic should or should not be tagged `vlan 0` (primarily in regards to EAP).
septer012 commented 2021-03-11 10:34:27 +05:30 (Migrated from github.com)
Copy link

I think because you have eapol start to the RG you actually authenticated and are failing to get a dhcp address. There is a similar reddit post, unless this is your post. https://www.reddit.com/r/PFSENSE/comments/lw9uhl/att_fiber_pfatt_pfsense_25_dhcp_not_getting_ip_on

I think because you have eapol start to the RG you actually authenticated and are failing to get a dhcp address. There is a similar reddit post, unless this is your post. https://www.reddit.com/r/PFSENSE/comments/lw9uhl/att_fiber_pfatt_pfsense_25_dhcp_not_getting_ip_on
darkwhispering commented 2021-03-23 02:59:16 +05:30 (Migrated from github.com)
Copy link

@Frick I'm the author of the reddit post @septer012 linked above. As per my post, I had issues for weeks that I could not resolve. The eapol is successful, looks like yours is as well, but the router never gets the DHCP IP for some reason. I have no clue why.

I could only resolve the issue by going to pfSense 2.4.5. Since then my system have been running stable for more than 2 weeks.

@Frick I'm the author of the reddit post @septer012 linked above. As per my post, I had issues for weeks that I could not resolve. The eapol is successful, looks like yours is as well, but the router never gets the DHCP IP for some reason. I have no clue why. I could only resolve the issue by going to pfSense 2.4.5. Since then my system have been running stable for more than 2 weeks.
Frick commented 2021-03-28 08:46:43 +05:30 (Migrated from github.com)
Copy link

Sorry for the radio silence. I've been incredibly busy with some other things. I'll give this a shot again in a couple of weeks. I'm traveling a bit right now and really love the Wireguard integration with pfSense 2.5 and so unwilling to downgrade to 2.4.5 for now. Really hoping to figure this out since I'm otherwise very happy with 2.5!

Sorry for the radio silence. I've been incredibly busy with some other things. I'll give this a shot again in a couple of weeks. I'm traveling a bit right now and really love the Wireguard integration with pfSense 2.5 and so unwilling to downgrade to 2.4.5 for now. Really hoping to figure this out since I'm otherwise very happy with 2.5!
A-vesalius commented 2021-03-28 18:53:37 +05:30 (Migrated from github.com)
Copy link

Sorry for the radio silence. I've been incredibly busy with some other things. I'll give this a shot again in a couple of weeks. I'm traveling a bit right now and really love the Wireguard integration with pfSense 2.5 and so unwilling to downgrade to 2.4.5 for now. Really hoping to figure this out since I'm otherwise very happy with 2.5!

You must have been busy to miss the post-release pfSense 2.5/wireguard back and forth. Long story - short version is that there are critical bugs in the pfSense wireguard version and it will be removed in 2.5.1.

https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/

> Sorry for the radio silence. I've been incredibly busy with some other things. I'll give this a shot again in a couple of weeks. I'm traveling a bit right now and really love the Wireguard integration with pfSense 2.5 and so unwilling to downgrade to 2.4.5 for now. Really hoping to figure this out since I'm otherwise very happy with 2.5! You must have been busy to miss the post-release pfSense 2.5/wireguard back and forth. Long story - short version is that there are critical bugs in the pfSense wireguard version and it will be removed in 2.5.1. https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/
Frick commented 2021-03-28 20:39:31 +05:30 (Migrated from github.com)
Copy link

I really was. That is awful news, but thank you for bringing it to my attention. I'll spend my next opportunity downgrading to 2.4.5 and also looking for something else to get my Wireguard fix, whether just a Pi behind pfSense or replacing pfSense all together. 😞

I really was. That is awful news, but thank you for bringing it to my attention. I'll spend my next opportunity downgrading to 2.4.5 and also looking for something else to get my Wireguard fix, whether just a Pi behind pfSense or replacing pfSense all together. :disappointed:
A-vesalius commented 2021-03-28 23:17:45 +05:30 (Migrated from github.com)
Copy link

I really was. That is awful news, but thank you for bringing it to my attention. I'll spend my next opportunity downgrading to 2.4.5 and also looking for something else to get my Wireguard fix, whether just a Pi behind pfSense or replacing pfSense all together. 😞

You can Try OPNsense. Similar setup to pfSense, but better GUI, IMO. Running it in a VM now. Works with this AT&T bypass script and has a safe wireguard implementation, not quite as fast as a kernel implementation, but still faster than openVPN and the same setup.

> I really was. That is awful news, but thank you for bringing it to my attention. I'll spend my next opportunity downgrading to 2.4.5 and also looking for something else to get my Wireguard fix, whether just a Pi behind pfSense or replacing pfSense all together. 😞 You can Try OPNsense. Similar setup to pfSense, but better GUI, IMO. Running it in a VM now. Works with this AT&T bypass script and has a safe wireguard implementation, not quite as fast as a kernel implementation, but still faster than openVPN and the same setup.
4pack commented 2021-04-02 22:13:20 +05:30 (Migrated from github.com)
Copy link

Can confirm, having this exact same issue. Cannot get a DHCP lease to save my life. This worked perfectly in 2.4.5.

Can confirm, having this exact same issue. Cannot get a DHCP lease to save my life. This worked perfectly in 2.4.5.
Archerious commented 2021-04-15 11:56:44 +05:30 (Migrated from github.com)
Copy link

Same issue here.

Same issue here.
septer012 commented 2021-04-23 23:26:44 +05:30 (Migrated from github.com)
Copy link

Apparently working on 2.5.1. https://www.reddit.com/r/PFSENSE/comments/mrnuno/pfsense_ce_251_and_pfatt

Apparently working on 2.5.1. https://www.reddit.com/r/PFSENSE/comments/mrnuno/pfsense_ce_251_and_pfatt
septer012 commented 2021-04-25 04:22:21 +05:30 (Migrated from github.com)
Copy link

I rolled the dice. It took a long time after upgrade to boot up, but its working and I got an IP address.

  21.02.2-RELEASE (amd64)

I rolled the dice. It took a long time after upgrade to boot up, but its working and I got an IP address.   21.02.2-RELEASE (amd64)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
supplicant
supplicant_OPNsense_testing
No results found.
Labels
Clear labels   
bug

Something isn't working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
invalid

This doesn't seem right

  
question

Further information is requested

  
wontfix

This will not be worked on

No labels
bug
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: hhf/pfatt#51
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?