Huawei E1732 qmilib supported?

[david preetham]

Hi Bjorn Thanks for the reply.

Can i know which are equivalent drivers can load for ndis interface in
huawei E3121 device?
The network interface is qmi + ncm based.

will cdc_ncm for data plane and cdc_wdm for control interface will work?
Which driver handling qmi and ncm protocol.

Thanks in advance
david



On Mon, Aug 12, 2013 at 2:18 PM, Bjørn Mork <bjorn at mork.no> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20130902/0b62e8ea/attachment.html>