qmicli working for EM7455

[Brandon Lee]

Thanks everyone for writing back.
Alex, I am running the Raspbian Buster version, but basically plain debian.
I am able to get dhcp through systemd-networkd
I did end up finding out that the modem was set to mbim, comp 8. I am new
to qmicli and clearly overlooked the command to change it.
After changing the comp settings using qmicli, it is booting with qmi_wwan
driver for data.

there seems to be a strange instance that the MC7455 shows 2 WWAN
interfaces while the EM7455 shows 1 wwan.
Can anyone tell me why this may be?

also Bjorn, you are obviously highly more skilled in all this than I am. I
did not even think to dig into the code, and i probably wouldnt understand
most of it.  I am curious, what you would recommend over systemd to
acquire an IP from the wwan interfaces using dhcp?

One final question for Bjorn, as i am taken back by his detail in coding.
I am having issues with the port being assigned to the proper cdc-wdm*.
Most of the time it boots with the same assignment but maybe 1 in 10 it
switches them. I tried a symlink rule but it didnt help. Can you give
proper advice on how to assign the device to a cdc-wdm on reboot/startup?
what i tried and it didnt work:

# assign module1 to cdc-wdm0
KERNEL=="cdc-wdm0", \
ATTR{idProduct}=="9071", \
SYMLINK+="cdc-wdm0"

Looking to try this but it would be a port assignment not device to udev
assignment
KERNEL=="cdc-wdm0*", KERNELS=="1-4:1.0", SYMLINK+="cdc-wdm0"

Thank you

On Tue, Mar 31, 2020 at 1:10 AM Bjørn Mork <bjorn at mork.no> wrote:

> Aleksander Morgado <aleksander at aleksander.es> writes:
>
> > I'm a bit surprised that you can have DHCP running on the MC7455 while
> > in QMI raw-ip mode on a standard Debian. Is that really so? which DHCP
> > client are you using?
>
> I assume that must be the internal one in systemd-networkd?  It's not
> like systemd allows you to configure any external one.
>
> Anyway, I was also surprised, but thought that the systemd developers
> actually might have learned something from others for once, instead of
> repeating every mistake throught history.
>
> Looking at
>
> https://github.com/systemd/systemd/blob/master/src/network/networkd-link.c#L2833
> they call
>
>         dhcp4_configure(link);
>
> if dhcp is enabled on a link.  And looking further at
>
> https://github.com/systemd/systemd/blob/master/src/network/networkd-dhcp4.c#L1324
> we see stuff like
>
>         r = sd_dhcp_client_set_mac(link->dhcp_client,
>                                    (const uint8_t *) &link->mac,
>                                    sizeof (link->mac), ARPHRD_ETHER);
>         if (r < 0)
>                 return log_link_error_errno(link, r, "DHCP4 CLIENT: Failed
> to set MAC address: %m");
>
>
> which shows that ARPHRD_ETHER is hardcoded, making it appear to be the
> only supported interface type.
>
> But i wonder if this hardcoding might (accidentally?) make the dhcp
> client work anyway.  Since they force the type to ethernet, and pick up
> the "mac address" from somewhere else (config or port-name-guessorama),
> then this could still work for raw-ip.
>
> I also noticed a few "raw_socket" calls in networkd-dhcp4.c but looking
> at
>
> https://github.com/systemd/systemd/blob/master/src/libsystemd-network/dhcp-network.c
> they document support for 0 byte addresses in the BPF filter they use:
>
>                 BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, dhcp_hlen, 1, 0),
>             /* address length == dhcp_hlen ? */
>                 BPF_STMT(BPF_RET + BPF_K, 0),
>             /* ignore */
>
>                 /* We only support MAC address length to be either 0 or 6
> (ETH_ALEN). Optionally
>                  * compare chaddr for ETH_ALEN bytes. */
>                 BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ETH_ALEN, 0, 12),
>                             /* A (the MAC address length) == ETH_ALEN ? */
>
>
> I stopped reading there.  Following this magic around is too complicated
> for me.  The "ARPHRD_ETHER" faking all the way didn't make it any
> simpler.. It was actually easier to add raw-ip support in the ISC client
> than making any sense out of this.
>
> I'd be interested to know if it actually does work.  I don't see any
> obvious way to test this dhcp client without losing all networking to
> systemd.
>
>
>
> Bjørn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200401/2d312ba3/attachment.htm>