How is the MAC address determined for EM7565 once data connection is established?


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# ifconfig wwan0
wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr: P-t-P: Mask:
inet6 addr: fe80::277c:b82b:91d3:72c5/64 Scope:Link
RX packets:2116540 errors:0 dropped:0 overruns:0 frame:0
TX packets:2129113 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000

-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
inet 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

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 ?

Thanks a lot in advance!


Moreover, is it possible to use command like “ifconfig wwan0 hw ether” to manually specify/change the MAC address for the wwan0 interface?

If yes, then how could I figure out a valid one?

Thanks again!


Are you using GobiNet driver?
You can check if this driver assigned the MAC address:

Hi jyijyi,

Many thanks for your information!

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:

Unsupported device type 65534 for “ipsec0” this article has some discussion regarding this.

Given that qmi_wwan is not passing any MAC address to the USB link, I guess it is time for me to try to resolve the issue from the DHCP relay side :slight_smile:

All the best!


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.

Hi Bjorn,

Many thanks for your kind reply, much appreciated!

On my EM7565, I found that:

  1. 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;
  2. 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() ( 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:

	memset(hw, 0, sizeof(struct hardware));

I will further discuss with ISC dhcp upstream about it :slight_smile:

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.

Thanks again!


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.

1 Like

Hi Bjorn,

Many thanks again for your generous reply!

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?