Huawei E1732 qmilib supported?

[Bjørn Mork]

david preetham <preetham.david at gmail.com> writes:

>     Starting network with 'qmicli -d /dev/cdc-wdm0  --wds-start-   network=
> airtelgprs.com  --client-no-release-cid'...
>     error: couldn't start network: QMI protocol error (10): 'InvalidProfile'

That's an error generated by the modem. Which is a half success, because
it demostrates that you are successful attempting to configure and
connect using QMI.

Unfortunately, we have no idea when and why such protocol error messages
are generated.  We can only guess based on the translated error code. I
assume the 'InvalidProfile' means that the modem expects more
configuration than qmicli/qmi-network currently sends.  But what?  We do
configure IPv4 by default, don't we?  Maybe this modem insists on
(dummy) authentication settings?  You could try if something like

 qmicli -d /dev/cdc-wdm0 --wds-start-network=airtelgprs.com,PAP,"",""  --client-no-release-cid

makes any difference.

> *I loaded qmi_wwan for control and data interface.*
>
> 2) sending At commands through /dev/ttyUSB0(option)
>     a) AT^NDISDUP=1,1,"airtelgprs.com"
>        ok.
>     b) AT^DHCP?
>        CME ERROR:2

Well, that sort of demstrates that the Huawei firmware is unable to
connect as well.  Most likely due to the same issue.  You could try
configuring a context before using AT^NDISDUP using something like

 AT+CGDCONT=1,"IP","airtelgprs.com"

and see if either (or both) method works better then.


> I thought of configuring wwan0 interface with above dhcp response(ip and
> netwmask) and run dhcp but not successful*. I loaded cdc_ether for network
> interface.*

Yes, those addressess won't work.  They are IPv4 link local addresses
generated by the dhcp client when it can't get any response from a dhcp
server.  The idea is that you can use such addresses to peer with other
clients on a LAN with no DHCP server.  This won't work on a wwan
interface... It requires a network connection to work.  The issue here
is that the driver is unaware of the link status and therefore always
reports the link as up.  This is a consequence of the design where all
QMI knowledge is delegated to userspace.

Maybe we should implement the (relatively new) .ndo_change_carrier
operation in the qmi_wwan driver so that userspace can set the carrier
state? That will avoid this dhcp client issue, since qmicli could tell
the driver that the connection failed.  It's sort of back and forth, but
that's the result of the userspace connection management.

What do you think, Dan and Aleksander?



Bjørn