openmptcprouter
openmptcprouter copied to clipboard
Ysurac
WAN DHCP not working with Intel i22x-V 2.5Gb (kernel 5.15 build)
Expected Behavior
My hardware is an x86_64 box with 4 physical network interfaces.
- eth0 (lan) is connected to the my internal switch and is working and hosting DHCP services for the lan on the 192.168.10.0/24 network with its IP set to 192.168.10.1
- eth2 (wan2) is connected to a DSL Modem in bridge mode with interface set to PPPoE and is obtaining an IP and working
- eth1 (wan1) is connected to a bridge-only cable modem. I expect that if I set DHCP as the protocol for that interface in the wizard, that openmptcprouter should get an IP and use this connection. It does not.
Current Behavior
The router is happy with the lan connection on eth0 and the wan2 connection on eth2. I have connectivity and "what is my ip" returns the VPS IP. In the OpenMPTCProuter -> Status tab, the wan1 interface reports:
No IP defined
No gateway defined
interface: eth1
multipath: master
Specifications
- OpenMPTCProuter version: openmptcprouter-v0.59.1-5.15-r0+20029-3c06a344e9-x86-64-generic-ext4-combined-efi
- OpenMPTCProuter VPS version: 0.1028 (on Ubuntu 20.04)
- OpenMPTCProuter VPS provider: EasyVPS
- OpenMPTCProuter platform: x86_64
It shows:
Protocol: DHCP client
MAC: 7C:2B:E1:13:0D:96
RX: 652.66 MB (10876260 Pkts.)
TX: 9.50 MB (28188 Pkts.)
Notably, there is no Uptime attribute like the PPPoE WAN2 or the LAN interfaces. Any other info I can provide or logging that should be turned on?
I mean check in Network->Interfaces and by editing the interface that everything is ok.
You can also try, via SSH on the router, a tcpdump -i eth1 -pvn port 67 and port 68 to check if some DHCP paquet are received.
Check also that you really don't have IP on the interface using ip a show dev eth1 (this may be a status page bug).
Thanks for your help, @Ysurac.
Everything looks same/OK in the edit UI. No IPv4 assigned. I see DHCP broadcasts every 3 seconds but no responses. I have also tried enabling the advanced setting "Use broadcast flag" but it does not help. See below. Note that if I plug my laptop ethernet into the modem with DHCP, I do get an IP and can access the internet.
root@OpenMPTCProuter:~# ip a show dev eth1
10: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 20
link/ether 7c:2b:e1:13:0d:96 brd ff:ff:ff:ff:ff:ff
inet6 fe80::7e2b:e1ff:fe13:d96/64 scope link
valid_lft forever preferred_lft forever
root@OpenMPTCProuter:~# tcpdump -i eth1 -pvn port 67 and port 68
tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:08:53.329545 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7c:2b:e1:13:0d:96, length 300, xid 0x6f79bb11, secs 611, Flags [Broadcast]
Client-Ethernet-Address 7c:2b:e1:13:0d:96
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
MSZ (57), length 2: 576
Parameter-Request (55), length 9:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
Unknown (212)
Hostname (12), length 15: "OpenMPTCProuter"
Vendor-Class (60), length 12: "udhcp 1.35.0"
I will need the result of uci show network or network section in System->OpenMPTCProuter, "Show all settings" tab.
Here you go.
root@OpenMPTCProuter:~# uci show network
network.loopback=interface
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.loopback.multipath='off'
network.loopback.device='lo'
network.loopback.metric='6'
network.globals=globals
network.globals.ula_prefix='fdff:7b1a:0a4c::/48'
network.globals.multipath='enable'
network.globals.mptcp_path_manager='fullmesh'
network.globals.congestion='cubic'
network.globals.mptcp_checksum='0'
network.globals.mptcp_debug='0'
network.globals.mptcp_syn_retries='2'
network.globals.mptcp_subflows='3'
network.globals.mptcp_add_addr_accepted='1'
network.globals.mptcp_add_addr_timeout='120'
network.globals.mptcp_fullmesh_num_subflows='1'
network.globals.mptcp_fullmesh_create_on_err='1'
network.globals.mptcp_ndiffports_num_subflows='1'
network.globals.mptcp_scheduler='default'
network.globals.mptcp_stale_loss_cnt='4'
network.lan=interface
network.lan.proto='static'
network.lan.netmask='255.255.255.0'
network.lan.device='eth0'
network.lan.ifname='eth0'
network.lan.ipv6='0'
network.lan.delegate='0'
network.lan.addlatency='0'
network.lan.multipath='off'
network.lan.ip4table='lan'
network.lan.metric='7'
network.lan.defaultroute='0'
network.lan.peerdns='0'
network.lan.label='Internal'
network.lan.ipaddr='192.168.10.1'
network.lan_rule=rule
network.lan_rule.lookup='lan'
network.lan_rule.priority='100'
network.wan1=interface
network.wan1.device='eth1'
network.wan1.ip4table='wan'
network.wan1.defaultroute='0'
network.wan1.addlatency='0'
network.wan1.ipv6='0'
network.wan1.metric='3'
network.wan1.peerdns='0'
network.wan1.proto='dhcp'
network.wan1.label='TekCable'
network.wan1.multipath='master'
network.wan1_dev=device
network.wan1_dev.name='eth1'
network.wan1_dev.txqueuelen='20'
network.wan1_dev.ipv6='0'
network.wan2=interface
network.wan2.device='eth2'
network.wan2.ip4table='wan'
network.wan2.defaultroute='0'
network.wan2.addlatency='0'
network.wan2.ipv6='0'
network.wan2.metric='4'
network.wan2.peerdns='0'
network.wan2.pppd_options='persist maxfail 0'
network.wan2.proto='pppoe'
network.wan2.username='[email protected]'
network.wan2.password='mypassword'
network.wan2.auth='both'
network.wan2.label='TekDSL'
network.wan2.multipath='on'
network.wan2_dev=device
network.wan2_dev.name='eth2'
network.wan2_dev.txqueuelen='20'
network.omrvpn=interface
network.omrvpn.device='tun0'
network.omrvpn.ip4table='vpn'
network.omrvpn.multipath='off'
network.omrvpn.leasetime='12h'
network.omrvpn.type='tunnel'
network.omrvpn.txqueuelen='100'
network.omrvpn.metric='1200'
network.omrvpn.proto='none'
network.omr6in4=interface
network.omr6in4.proto='6in4'
network.omr6in4.ip4table='vpn'
network.omr6in4.multipath='off'
network.omr6in4.ipaddr='10.255.255.2'
network.omr6in4.peeraddr='10.255.255.1'
network.omr6in4.auto='0'
network.omr6in4.metric='1201'
network.omr6in4.ip6addr='fe80::a00:2/126'
network.omr6in4.gateway='fe80::a00:1/126'
network.lan_dev=device
network.lan_dev.name='eth0'
network.wan3_dev=device
network.wan3_dev.name='eth3'
Seems to be ok.
What is the result of ifstatus wan1 ?
And when you let tcpdump run for a longer time ? (the message is only a discover, so a request for IP from eth1, no answer)
Yeah, the config looks OK but there is no DHCP response so it doesn't come up. Leaving tcpdump to run longer just repeats the same output every three seconds. Here is the additional output you asked for.
root@OpenMPTCProuter:~# ifstatus wan1
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcp",
"device": "eth1",
"data": {
}
}
Try to restart the interface in Network->Interfaces. But you should not get always same message in tcpdump, there is request from the interface, your modem DHCP server should answer.
Hi @Ysurac I have tried restarting the interface again and it did not fix it. I know I should be seeing a DHCP response with tcpdump but I don't. So either it isn't being sent or my router isn't seeing it. The modem is a bridge modem with no router built in so I don't think it is running a DHCP server itself but rather passing the requests to the ISP's DHCP services. I receive an IP when using a DHCP client on my laptop and also on my Edgerouter Lite.
Here is a capture of what it looks like when I leave tcpdump a bit longer. Just repeated DHCP client broadcasts and no responses.
root@OpenMPTCProuter:~# tcpdump -i eth1 -pvn port 67 and port 68
tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:42:30.309506 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7c:2b:e1:13:0d:96, length 300, xid 0x2086e250, secs 310, Flags [none]
Client-Ethernet-Address 7c:2b:e1:13:0d:96
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
MSZ (57), length 2: 576
Parameter-Request (55), length 9:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
Unknown (212)
Hostname (12), length 15: "OpenMPTCProuter"
Vendor-Class (60), length 12: "udhcp 1.35.0"
08:42:33.399357 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7c:2b:e1:13:0d:96, length 300, xid 0x2086e250, secs 313, Flags [none]
Client-Ethernet-Address 7c:2b:e1:13:0d:96
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
MSZ (57), length 2: 576
Parameter-Request (55), length 9:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
Unknown (212)
Hostname (12), length 15: "OpenMPTCProuter"
Vendor-Class (60), length 12: "udhcp 1.35.0"
08:42:36.509443 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7c:2b:e1:13:0d:96, length 300, xid 0x2086e250, secs 317, Flags [none]
Client-Ethernet-Address 7c:2b:e1:13:0d:96
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
MSZ (57), length 2: 576
Parameter-Request (55), length 9:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
Unknown (212)
Hostname (12), length 15: "OpenMPTCProuter"
Vendor-Class (60), length 12: "udhcp 1.35.0"
08:42:39.599407 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7c:2b:e1:13:0d:96, length 300, xid 0x2086e250, secs 320, Flags [none]
Client-Ethernet-Address 7c:2b:e1:13:0d:96
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
MSZ (57), length 2: 576
Parameter-Request (55), length 9:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
Unknown (212)
Hostname (12), length 15: "OpenMPTCProuter"
Vendor-Class (60), length 12: "udhcp 1.35.0"
08:42:42.689358 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7c:2b:e1:13:0d:96, length 300, xid 0x2086e250, secs 323, Flags [none]
Client-Ethernet-Address 7c:2b:e1:13:0d:96
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
MSZ (57), length 2: 576
Parameter-Request (55), length 9:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
Unknown (212)
Hostname (12), length 15: "OpenMPTCProuter"
Vendor-Class (60), length 12: "udhcp 1.35.0"
I thought there could maybe be some duplex issue with failed auto-negotiation but it looks like what I would expect.
root@OpenMPTCProuter:~# ethtool eth1
Settings for eth1:
Supported ports: [ ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Would it be helpful for me to test with a different router device and the non 5.15 kernel version to narrow down the problem? I have a Pi4 and a little switch I could test with.
I tested a 5.15 under virtualbox and I have no issue to get a DHCP address. Really no idea why you don't get an answer from DHCP, can you try with anything else under Linux and do same tcpdump ?
OK. Sorry for the delay @Ysurac. I finally got to this. Thanks again for all your help.
Obtaining IP address using DHCP is working when plugging my Pi4 straight into my bridging cable modem. I tossed a couple more options to tcpdump for more info.
pi@raspberrypi:~/Desktop $ uname -a
Linux raspberrypi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux
pi@raspberrypi:~ $ sudo tcpdump -i eth0 -vvv -pne port 67 and port 68
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:23:40.566350 dc:a6:32:d5:0b:d2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 36794, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from dc:a6:32:d5:0b:d2, length 300, xid 0x930af450, Flags [none] (0x0000)
Client-Ethernet-Address dc:a6:32:d5:0b:d2
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Request
Client-ID (61), length 7: ether dc:a6:32:d5:0b:d2
Requested-IP (50), length 4: 192.0.133.12
MSZ (57), length 2: 1472
Hostname (12), length 11: "raspberrypi"
Unknown (145), length 1: 1
Parameter-Request (55), length 14:
Subnet-Mask (1), Classless-Static-Route (121), Static-Route (33), Default-Gateway (3)
Domain-Name-Server (6), Hostname (12), Domain-Name (15), MTU (26)
BR (28), Lease-Time (51), Server-ID (54), RN (58)
RB (59), Unknown (119)
END (255), length 0
PAD (0), length 0, occurs 5
23:23:40.608398 00:17:10:93:ae:16 > dc:a6:32:d5:0b:d2, ethertype IPv4 (0x0800), length 374: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 360)
209.148.134.201.67 > 192.0.133.12.68: [udp sum ok] BOOTP/DHCP, Reply, length 332, xid 0x930af450, Flags [none] (0x0000)
Your-IP 192.0.133.12
Gateway-IP 7.127.2.169
Client-Ethernet-Address dc:a6:32:d5:0b:d2
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: ACK
Server-ID (54), length 4: 7.127.2.169
Lease-Time (51), length 4: 2451
Subnet-Mask (1), length 4: 255.255.255.224
Default-Gateway (3), length 4: 192.0.133.1
Domain-Name-Server (6), length 8: 206.248.154.22,206.248.154.170
MTU (26), length 2: 576
BR (28), length 4: 255.255.255.255
RN (58), length 4: 1225
RB (59), length 4: 2144
Hostname (12), length 30: "CPEdca632d50bd2-CM90aac3685b3e"
END (255), length 0
pi@raspberrypi:~ $ ip a show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:d5:0b:d2 brd ff:ff:ff:ff:ff:ff
inet 192.0.133.12/27 brd 255.255.255.255 scope global dynamic noprefixroute eth0
valid_lft 2437sec preferred_lft 2130sec
inet6 2607:f2c0:f200:1804:fd80:ac68:1436:b47f/128 scope global dynamic noprefixroute
valid_lft 3564sec preferred_lft 3564sec
inet6 fe80::2229:e81f:2672:d8f4/64 scope link
valid_lft forever preferred_lft forever
I am having the same issue on my x86_64 box. Based on the similar MAC address do you have the Intel I225-V? Mine is the supposedly fixed B3 stepping but reading about this NIC it seems to have lots of issues. Following in case there is a fix. Mine is running kernel 5.4.194
root@OpenMPTCProuter:~# uname -a Linux OpenMPTCProuter 5.4.194 #0 SMP Tue May 17 22:11:28 2022 x86_64 GNU/Linux
@kb1isz Actually, I am running the newer i226-V for which @Ysurac said I should upgrade to the kernel 5.15 testing version of OpenMPTCProuter. Someone else later mentioned something in the issue about OpenWRT needing kernel 5.15 to solve something on an i225-V as well. I don't have any other clues for you I'm afraid. See https://github.com/Ysurac/openmptcprouter/issues/2544
To top if off, I'm on a Hitron CODA-45 cable modem which has a problematic Puma chipset or so I have read. I did not experience any problems before this but am replacing it with a TC4400 to see if that makes any difference. I just have to wait for my ISP to swap the modems in my profile. I am not expecting the modem swap to make any difference since multiple systems have no problem obtaining addresses via DHCP on the Hitron, but one can hope.
Looking through that other issue thread again, I see my note that even when attempting to test the i226-V interfaces with 5.15 behind my previous stock Edgerouter running dhcpd, OpenMPTCProuter was not able to ~~grab an IP via DHCP~~[edit to clarify] stay up after grabbing an IP. So that reinforces the idea that the problem doesn't have anything to do with my cable modem or ISP. I was kicking myself a bit for buying a newer i226-V box but if you are having the same problem with the i225-V then at least I can stop doing that. I think my next workaround attempt will be to put the Edgerouter back in place between my cable modem and the OpenMPTCProuter box so I can use a static IP on it.
My new cable modem came online sometime this morning while hooked up to eth1 of my OpenMPTCProuter box. I was out all day and when I got home, my internet was down. The OpenMPTCProuter box was non-responsive to web or SSH. I physically checked on the box and it was very hot to the touch. Whatever it was looping through while trying to get an IP was making some heat and took itself down. I shut the router down with the power button and unplugged it for a bit to let it cool. I disconnected it from the cable modem and powered it up again. My internet came back via my PPPoE DSL link on eth2 and things were back to where they were.
So after that, I set about getting a spare Edgerouter Lite flashed to latest EdgeOS firmware and configured it for DHCP WAN on eth0 and static LAN on eth1 without a firewall. Then I connected Edgerouter eth0 to the cable modem and Edgerouter eth1 to eth1 on the OpenMPTCProuter box. I configured wan1 (eth1) on the OpenMPTCProuter box for static address. Then that MPTCP link came up and everything is working pretty well. The combined speeds are less than the sum of the two connections on their own by more than I expected, but I am able to disconnect one WAN or the other without my connections dropping and I present to the world from a single fixed VPS IP so that's good enough for me for now.
I'll be happy to test DHCP with my setup again in the future if you would like me to @Ysurac. Just mention me in here.
Just more data to troubleshoot. I did the following...
OpenMPTCProuter running native - DHCP WAN did not work OpenMPTCProuter running under proxmox with nics passed through. - DHCP WAN did not work OpenMPTCProuter running under proxmox with linux bridges and normal virtio - DHCP WAN did work
While not ideal this works for me. Hope this helps someone else.
Just more data to troubleshoot. I did the following...
OpenMPTCProuter running native - DHCP WAN did not work OpenMPTCProuter running under proxmox with nics passed through. - DHCP WAN did not work OpenMPTCProuter running under proxmox with linux bridges and normal virtio - DHCP WAN did work
While not ideal this works for me. Hope this helps someone else.
Hey @kb1isz could you please confirm which build of openmptcprouter you were/are running with success under ProxMox with linux bridging and virtio?
I ask because I just had cause to have to rebuild both ends (vps & my i226-V home gateway box) and decided to give your config a try and see if I could get my workaround Edgerouter out of the picture and get a DHCP address directly. I set up ProxMox 7.3 on my i226-V gateway box, set up two more Linux bridge interfaces (it installed with one for the lan) for a total of three, and then created a VM and wrote openmptcprouter-v0.59.1-5.4-r0+16594-ce92de8c8c-x86-64-generic-ext4-combined-efi.img onto its disk. I figured since I was going to be in a VM with virtio network interfaces, I didn't need the 5.15 test version of openmptcprouter. But as it turns out, my problematic cable connection is not coming up. I tried the "Forced Link" advanced option on the interface to no avail.
I ask because I just had cause to have to rebuild both ends (vps & my i226-V home gateway box) and decided to give your config a try and see if I could get my workaround Edgerouter out of the picture and get a DHCP address directly. I set up ProxMox 7.3 on my i226-V gateway box, set up two more Linux bridge interfaces (it installed with one for the lan) for a total of three, and then created a VM and wrote
openmptcprouter-v0.59.1-5.4-r0+16594-ce92de8c8c-x86-64-generic-ext4-combined-efi.imgonto its disk. I figured since I was going to be in a VM with virtio network interfaces, I didn't need the 5.15 test version of openmptcprouter. But as it turns out, my problematic cable connection is not coming up. I tried the "Forced Link" advanced option on the interface to no avail.
@ahayes I was running the default version when I had that setup root@OpenMPTCProuter:~# uname -a Linux OpenMPTCProuter 5.4.194 #0 SMP Tue May 17 22:11:28 2022 x86_64 GNU/Linux
I ended going away from OpenMPTCProuter though so I can't tell you for sure, but at least the kernel is known.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@Ysurac This is still an issue and I think more recent Linux kernels have got these interfaces working properly so can this stay open at least until there is a new build with a newer kernel to try?
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days
@Ysurac This has been auto-closed but the problem persisted in the past and nothing has changed other than people moving away from running directly on i225-V and i226-V 2.5 GbE network adapters. Any newer versions planned with a newer kernel?
Huh... I see that a new OpenWRT version with kernel 6.1 was committed to the repo an hour ago. That would be worth a testing for this issue when there is a build available.
I believe the ultimate cause of this issue is outlined in https://github.com/Ysurac/openmptcprouter/issues/3005. I found a fix/work-around for anyone interested in this. This hardware does work properly in OpenWrt 21.02.07 with Linux kernel 5.4.238 and is stable even when using dhcp there.
I have the same issue on Intel 226 with pfSense 2.7.1 and proxmox 8.1, Kernel 6.5. The DHCP on WAN loses connection and is not able to get reply to DHCP discovery packet, only reset of Proxmox helps.
