<div dir="ltr"><div><div>>>I must admit that I see this excercise as somewhat pointless.<br></div>Ya , I was just giving a try . Was in eager to know how it happens . <br><br>>> Just select one of the available QMI libraries<br>

>>and forget that this modem has any AT commands.<br></div>Ya , it work . Thanks for your support . Thanks for qmi_wwan <br><br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 1:19 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">Madhan <<a href="mailto:madhan.mepco@gmail.com">madhan.mepco@gmail.com</a>> writes:<br>
<br>
> hi alex , bjorn ,<br>
> Can you just tell me is there something to be done after setting the IP and<br>
> gw manually (using AT^DHCP?) ?<br>
<br>
</div>No, there shouldn't be.<br>
<div class="im"><br>
> I update my resolv.conf too .But still i was not able to connect to network<br>
> . ping fails .<br>
<br>
</div>You could try disabling arp on the interface.  And use usbmon to monitor<br>
the USB traffic.   Maybe there are packets with so messed up headers<br>
that they are dropped before you see them on the network interface?<br>
That's pretty normal for this firmware...<br>
<br>
Unless you can prove that there is a problem when using QMI only, I am<br>
going to claim this is a firmware bug.  We have discovered a number of<br>
bugs related to the implementation of AT connect, based only on<br>
observing the firmware behaviour.  There is absolutely no reason to<br>
believe that we ever will discover them all, given that the testing is<br>
very spurious and we don't have access to the firmware source.<br>
<br>
I must admit that I see this excercise as somewhat pointless.  I started<br>
out trying to use AT^NDISDUP on an E392, but gave up. Adding firmware<br>
features for Linux is a nice move by Huawei, but unfortunately *every*<br>
USB device firmware out there depends on the testing provided by<br>
thousands or millions of Windows users.  Any firmware application<br>
intended only for Linux will be so buggy that it is useless. This is not<br>
Huawei specific.  It is a generic problem with firmware.  I don't know<br>
what it is about firmware developers, but I have begun to understand why<br>
so little firmware source code is available. But I believe increased<br>
device complexity will force this to change.  Take a look at the current<br>
embedded platform trends.  More and more SoC vendors understand that<br>
they have to not just publish drivers, but actually work *with* the<br>
community to make their devices work.  The same is bound to happen to<br>
modems and other USB gizmos as well.  Some code will probably remain<br>
blobs forever, like DSP code, but most of the firmware stuff will end up<br>
as open source.  Or fail.<br>
<br>
Anyway, back to subject... For me it was easier to write the qmi_wwan<br>
driver and the necessary perl scripts to connect using QMI.  You don't<br>
even have to do that.  Just select one of the available QMI libraries<br>
and forget that this modem has any AT commands.<br>
<br>
<br>
<br>
Bjørn<br>
<div class="im"><br>
> On Fri, Aug 16, 2013 at 7:11 PM, Madhan <<a href="mailto:madhan.mepco@gmail.com">madhan.mepco@gmail.com</a>> wrote:<br>
><br>
>> hi bjorn ,<br>
>><br>
>> >Which kernel (i.e. driver) version do you use?<br>
</div>>> *I tried in 3.5 and also in 3.10 *, in both cases i was not successful<br>
<div class="im">>> using AT<br>
>><br>
>> >Why don't you want to use it?<br>
</div>>> *I am trying to just sort out , what qmi connection is doing in addition<br>
<div class="im">>> after getting the AT .<br>
>><br>
</div>>> *<br>
>> Cause when I was *sniffing usb* i was able to find the same even when i<br>
>> am using *qmicli , this also<br>
>> uses AT^DHCP? command  *<br>
<div class="HOEnZb"><div class="h5">>><br>
>> +aleksander : Can you please give us some suggestions<br>
>><br>
>><br>
>> On Fri, Aug 16, 2013 at 6:19 PM, Bjørn Mork <<a href="mailto:bjorn@mork.no">bjorn@mork.no</a>> wrote:<br>
>><br>
>>> Madhan <<a href="mailto:madhan.mepco@gmail.com">madhan.mepco@gmail.com</a>> writes:<br>
>>><br>
>>> > hi ,<br>
>>> > I have used qmi_wwan and cdc_wdm for my device<br>
>>> ><br>
>>> > Sending At commands through /dev/ttyUSB0(option)<br>
>>> >      a) *AT^NDISDUP*=1,1,"my_apn"<br>
>>> >         ok.<br>
>>> >      b)* AT^DHCP?*<br>
>>> >         gives me IP also<br>
>>> ><br>
>>> > But when I set the IP with the provided netmask , dns and gw<br>
>>> > I am *not able to connec*t to internet .<br>
>>> ><br>
>>> ><br>
>>> > But when I use the "libqmi"<br>
>>> > *qmicli -*d /dev/cdc-wdm0 --wds-start-network=<a href="http://airtelgprs.com" target="_blank">airtelgprs.com</a>,PAP,"",""<br>
>>> >  --client-no-release-cid<br>
>>> ><br>
>>> > I am able to *successfully connect *to network using my network<br>
>>> interface .<br>
>>> ><br>
>>> > Cant I do the same without using qmicli ?<br>
>>> > Is there anything in specific which establishes connection after<br>
>>> getting IP<br>
>>><br>
>>> Which kernel (i.e. driver) version do you use? A few fixes for known<br>
>>> firmware bugs went into v3.9 and the still maintained stable kernels<br>
>>> where they could be applied without changes.  I could not make my E392<br>
>>> work using AT^NDISDUP without some of these fixes.<br>
>>><br>
>>> But I do believe the QMI connection method is more stable on these<br>
>>> modems.   The Windows driver/application use it, so that's the mode<br>
>>> getting any testing.  The AT command method might work, but I recommend<br>
>>> using QMI.  As you have already found out, it is more reliable.  Why<br>
>>> don't you want to use it?<br>
>>><br>
>>><br>
>>> Bjørn<br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Madhan<br>
>><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Madhan<input type="hidden"><input type="hidden"><div></div>
</div>