I am using Linux kernel with ModemManager and libqmi in userspace to drive EM7565. Once the data connection is up, I see the MAC address, or the HWaddr of the wwan0 interface is all zero, for example:
-bash-5.0# ip addr show dev wwan0
20: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/none
inet 166.130.53.232/28 scope global wwan0
valid_lft forever preferred_lft forever
inet6 fe80::277c:b82b:91d3:72c5/64 scope link stable-privacy
valid_lft forever preferred_lft forever
-bash-5.0#
How is the MAC address for the wwan0 interface is determined? when and by whom? and is it possible to make the MAC address more “meaningful” or at least non all-zero?
Moreover, how is the wwan0’s MAC address used in setting up or disconnecting data connection ?
Yep, I read your post last year which was also about MAC address on SW modems
I am using ModemManager with SW plugin and libqmi, not using GobiNet driver.
From one of the reply in your post I saw a very useful clarification that the MAC address is not used by the qmi_wwan kernel driver when operating in the raw-ip mode, I will double check on this point.
The problem I am seeing is that once I setup an IPSec tunnel based on the wwan0 interface with zero MAC address, the ipsec0 interface will inherit both the IP address and the zero MAC address. Furhtermore, when such ipsec0 interface is used by the DHCP relay, it kind of gets upset about the ipsec0 without MAC address:
It is not all zero. That is just a problem with ifconfig. The address length is zero .
Drivers pretending that the modem is an ethernet device usually just invent a random address. It does not matter. It has only local meaning on the host.
Yes, some dhcp clients don’t like non-ethernet IP interfaces. That’s a bug in the dhcp client.
Many thanks for your kind reply, much appreciated!
On my EM7565, I found that:
when /sys/class/net/wwan0/qmi/raw_ip is Y, the qmi --get-expected-data-format == raw_ip, and the wwan0 will have zero MAC address (Or, as you have put it, in qmi_wwan_netdev_setup(), the net_device’s hard_header_len == 0). I can login to the wwan0 interface;
when I bring down the wwan0 interface first, then change the raw_ip to N and bring up the wwan0 interface, the expected data format will become 802-3, and the wwan0 will have an ethernet interface alike MAC address, but I can not login to the wwan0 interface anymore. (The previous bearer is preserved, I didn’t ry to re-setup it)
The problem I am running into, is that once I create an IPsec tunnel on top of the wwan0 with zero MAC address length, the MAC address of the ipsec0 interface will also be zero, and the DHCP relay daemon will get upset. In the ISC dhcp relay source code, lpf.c, get_hw_addr() (https://github.com/isc-projects/dhcp/blob/master/common/lpf.c#L567) will throw out error messages like:
Unsupported device type 65534 for “ipsec0”
Just because it can’t handle the ARPHDR_NONE in the sa_family, which has been setup in the qmi_wwan_netdev_setup()
Someone proposed to change the get_hw_addr() to deal with ARPHDR_NONE as:
case ARPHDR_NONE:
memset(hw, 0, sizeof(struct hardware));
break;
I will further discuss with ISC dhcp upstream about it
One last question though, could the qmi_wwan.c kernel driver work in the 802-3 mode? and does the current firmware on EM7565 (latest from SW) only support raw_ip mode? I am curious why I can’t login on wwan0 anynore once the raw_ip == N and the expected data format == 802-3.
This sounds like an unnecessary relationship. The configuration of the ipsec interface should be completely unrelated to the underlying hardware. It’s an IP in IP tunnel. If you want the outer pseudo-interface to look like an ethernet interface with an arbitrary mac address, then you can do that independently of the transport.
Yes, this is the same issue they have with the client. The code reinvents parts of the OS, and assume everything is ethernet. So it doesn’t work .
THe driver can do 802-3 if the modem supports it. But no modem of the MC/EM74xx generation or newer does that. And it’s not something Sierra Wireless can change in firmware. The 802-3 support is removed from the Qualcomm code. For very good reasons, I will add. It was an infinite bug source.
As for the Qualcomm code, where is it stored, when it is running? what’s the relationship between it and the SW firmware (.nvu or .cwe images). Are both Qualcomm code and SW firmware source code proprietary?
If I wanted to know a bit more about them, where could I find some useful links / resources to start with?
