Hi misc@,
I am currently testing OpenBSD 6.8 (GENERIC.MP) #98 on an APU2c4 together with
a u-blox mPCIe LTE modem (MPCI-L210-03S-00) which can be configured to present
itself to the system either as a cdce(4) device or as a urndis(4) device. In
both modes, the modem is attached by the kernel and the corresponding entry
shows up in the ifconfig(8) output. The modem can work both in the bridge mode
and in the router mode. During the tests, I activated the router mode and
configured the cdce0 network interface as follows (for the entire time, the
urndis0 interface remained disabled and did not appear in the ifconfig(8)
output; the modem also registered properly with the LTE network):
# cat /etc/hostname.cdce0
up
dhcp
The problem manifested itself in such a way that, while I was able to
send and receive ICMP echo-request/reply messages to external IPv4 addresses
via the LTE network, traffic involving other network protocols (DNS/NTP/TLS,
for example) was interrupted frequently -- in that case, an in-depth analysis
revealed that the corresponding reply messages forwarded by the modem towards
the OpenBSD system had an unexpected destination MAC address set in the
Ethernet header, and so they were dropped by the kernel in the ether_input()
function defined in the /usr/src/sys/net/if_ethersubr.c file. In particular, I
noticed that the destination MAC address stored in the message header (not
matching the MAC address of the cdce0 interface on the receiving end) was equal
to the MAC address of the inactive urndis0 interface, which also explains why
the MAC address validation check failed and why most of the incoming messages
were dropped. At the same time, while quickly analyzing the ether_output() code
path, I noticed that the ether_resolve() function used the MAC address of the
cdce0 interface as the source address, and the MAC address of the internal
gateway interface of the modem as the destination address.
Based on my current understanding of the problem, it is not caused by
the APU2 machine, as I was able to reproduce this issue also on a Dell laptop
having a WWAN slot and running the same version of OpenBSD (I could not
reproduce it on Linux, though -- forwarding worked fine in this case).
I wonder what would be the most effective way to investigate this issue
further? I would appreciate any comments and suggestions.
Best wishes,
Andrzej
