DHCP client and MC7304

[Alexander Kappner]

Fair points. I think this functionality should go into qmicli then, so 
that qmi-network script can be adjusted as needed by the user. So I'll 
submit a patch for a --wds-ifconfig=[ip,gw,dns,all] command in qmicli, 
where the user can specify flags for all parameters he wants 
autoconfigured. These flags can then be specified in qmi-network.

> 2) DNS: you didn't mention DNS either, and to set up a complete
> connection along with the default route, you need to update DNS too.
> This gets tricky, since there are quite a few DNS services these days
> (resolvconf/openresolv, systemd-resolved, NetowrkManager, etc) that are
> require more than just writing to /etc/resolv.conf.  But I guess
> writing to /etc/resolv.conf is at least a start.

Most DHCP clients do the same thing, so why not just stick with that 
until there's complaints that this actually breaks something else.

 > 3) IIRC devices required DHCP before they'd start working, though these
 > were from a couple years ago before widespread raw-ip support.  See
 > ModemManager commit 0c6f1ae6c4bae4b4d82d015f6940e0448749aee3:
The new command doesn't have to be the default, so as not to break 
legacy modems. Or we can set it as the default only for modems that are 
connected in Raw IP mode.So if "qmicli -e" returns raw-ip, it should be 
safe to assume that DHCP is not required for this modem. Even if it 
would run as default, I don't think it would break legacy modems since 
the DHCP client would still run and overwrite the
static configuration. If it turns out that it works well, maybe make it 
the default at some point and keep a list of legacy devices that it breaks.


 > On Wed, 2017-04-12 at 15:06 -0700, Alexander Kappner wrote:
 >> Is there any reason why qmi-network does not (at least offer to)
 >> automatically configure the network interface with the data from --
 >> wds-get-current-settings (e.g. through ifconfig/ip), without the need
 >> to get a DHCP client involved?
 >>
 >> I recently came across a similar problem on an EM7455 where the
 >> interface would not successfully DHCP, and I solved it by
 >> screenscraping the --wds-get-current-settings output and calling
 >> ifconfig to manually set ip/netmask/getway. Any good reasons why this
 >> might be a bad idea? If not,  I'll submit a patch for qmicli and qmi-
 >> network to provide automatic setup of ip, netmask and routes.
 >
 > This is probably a good idea, with three caveats:
 >
 > 1) default route: how do you determine whether to overwrite the default
 > route or not?  qmi-network can be run in a number of different places,
 > and some may want a default route set and others might not.  So perhaps
 > you need an option here.

 > 2) DNS: you didn't mention DNS either, and to set up a complete
 > connection along with the default route, you need to update DNS too.
 > This gets tricky, since there are quite a few DNS services these days
 > (resolvconf/openresolv, systemd-resolved, NetowrkManager, etc) that are
 > require more than just writing to /etc/resolv.conf. But I guess
 > writing to /etc/resolv.conf is at least a start.

 > 3) IIRC devices required DHCP before they'd start working, though these
 > were from a couple years ago before widespread raw-ip support.  See
 > ModemManager commit 0c6f1ae6c4bae4b4d82d015f6940e0448749aee3:

 > ---
 >    qmi: always use DHCP for IPv4 configuration instead of STATIC
 >
 >    Some newer modems (Huawei E1750, Sierra 73xx) provide what looks like
 >    legitimate static IPv4 configuration through the WDSGetCurrentSettings
 >    call, but when configured the interface does not pass traffic.  
Running
 >    DHCP on the same interface provides a slightly different IPv4
 >    configuration but does allow traffic to pass.
 >
 >    Since QMI was switched to static originally for consistency with IPv6
 >    and for speed of IP configuration (since DHCP takes a bit of 
time), but
 >    not for any known problems with modems, let's switch back to DHCP 
until
 >    we have time to figure out what's actually going on.
 > ---
 >
 > I'm not sure we ever figured out what was going on... But the point
 > being that we can't always assume that static IP configuration actually
 > works on all devices.

 > Dan

 >> Thanks
 >>
 >> --Alexander