<div dir="ltr"><div><div><div><div>Hi Bjorn Thanks for the reply.<br><br></div>Can i know which are equivalent drivers can load for ndis interface in huawei E3121 device?<br></div>The network interface is qmi + ncm based. <br>
<br></div>will cdc_ncm for data plane and cdc_wdm for control interface will work? Which driver handling qmi and ncm protocol.<br><br></div><div>Thanks in advance<br></div><div>david<br></div><div><div><div><div><br></div>
</div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 12, 2013 at 2:18 PM, Bjørn Mork <span dir="ltr"><<a href="mailto:bjorn@mork.no" target="_blank">bjorn@mork.no</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">david preetham <<a href="mailto:preetham.david@gmail.com">preetham.david@gmail.com</a>> writes:<br>
<br>
> Starting network with 'qmicli -d /dev/cdc-wdm0 --wds-start- network=<br>
</div>> <a href="http://airtelgprs.com" target="_blank">airtelgprs.com</a> --client-no-release-cid'...<br>
<div class="im">> error: couldn't start network: QMI protocol error (10): 'InvalidProfile'<br>
<br>
</div>That's an error generated by the modem. Which is a half success, because<br>
it demostrates that you are successful attempting to configure and<br>
connect using QMI.<br>
<br>
Unfortunately, we have no idea when and why such protocol error messages<br>
are generated. We can only guess based on the translated error code. I<br>
assume the 'InvalidProfile' means that the modem expects more<br>
configuration than qmicli/qmi-network currently sends. But what? We do<br>
configure IPv4 by default, don't we? Maybe this modem insists on<br>
(dummy) authentication settings? You could try if something like<br>
<br>
qmicli -d /dev/cdc-wdm0 --wds-start-network=<a href="http://airtelgprs.com" target="_blank">airtelgprs.com</a>,PAP,"","" --client-no-release-cid<br>
<br>
makes any difference.<br>
<br>
> *I loaded qmi_wwan for control and data interface.*<br>
<div class="im">><br>
> 2) sending At commands through /dev/ttyUSB0(option)<br>
> a) AT^NDISDUP=1,1,"<a href="http://airtelgprs.com" target="_blank">airtelgprs.com</a>"<br>
> ok.<br>
> b) AT^DHCP?<br>
> CME ERROR:2<br>
<br>
</div>Well, that sort of demstrates that the Huawei firmware is unable to<br>
connect as well. Most likely due to the same issue. You could try<br>
configuring a context before using AT^NDISDUP using something like<br>
<br>
AT+CGDCONT=1,"IP","<a href="http://airtelgprs.com" target="_blank">airtelgprs.com</a>"<br>
<br>
and see if either (or both) method works better then.<br>
<div class="im"><br>
<br>
> I thought of configuring wwan0 interface with above dhcp response(ip and<br>
</div>> netwmask) and run dhcp but not successful*. I loaded cdc_ether for network<br>
> interface.*<br>
<br>
Yes, those addressess won't work. They are IPv4 link local addresses<br>
generated by the dhcp client when it can't get any response from a dhcp<br>
server. The idea is that you can use such addresses to peer with other<br>
clients on a LAN with no DHCP server. This won't work on a wwan<br>
interface... It requires a network connection to work. The issue here<br>
is that the driver is unaware of the link status and therefore always<br>
reports the link as up. This is a consequence of the design where all<br>
QMI knowledge is delegated to userspace.<br>
<br>
Maybe we should implement the (relatively new) .ndo_change_carrier<br>
operation in the qmi_wwan driver so that userspace can set the carrier<br>
state? That will avoid this dhcp client issue, since qmicli could tell<br>
the driver that the connection failed. It's sort of back and forth, but<br>
that's the result of the userspace connection management.<br>
<br>
What do you think, Dan and Aleksander?<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Bjørn<br>
</font></span></blockquote></div><br></div>