Problem with E392 connection using wwan0

[Bjørn Mork]

Madhan <madhan.mepco at gmail.com> writes:

> hi alex , bjorn ,
> Can you just tell me is there something to be done after setting the IP and
> gw manually (using AT^DHCP?) ?

No, there shouldn't be.

> I update my resolv.conf too .But still i was not able to connect to network
> . ping fails .

You could try disabling arp on the interface.  And use usbmon to monitor
the USB traffic.   Maybe there are packets with so messed up headers
that they are dropped before you see them on the network interface?
That's pretty normal for this firmware...

Unless you can prove that there is a problem when using QMI only, I am
going to claim this is a firmware bug.  We have discovered a number of
bugs related to the implementation of AT connect, based only on
observing the firmware behaviour.  There is absolutely no reason to
believe that we ever will discover them all, given that the testing is
very spurious and we don't have access to the firmware source.

I must admit that I see this excercise as somewhat pointless.  I started
out trying to use AT^NDISDUP on an E392, but gave up. Adding firmware
features for Linux is a nice move by Huawei, but unfortunately *every*
USB device firmware out there depends on the testing provided by
thousands or millions of Windows users.  Any firmware application
intended only for Linux will be so buggy that it is useless. This is not
Huawei specific.  It is a generic problem with firmware.  I don't know
what it is about firmware developers, but I have begun to understand why
so little firmware source code is available. But I believe increased
device complexity will force this to change.  Take a look at the current
embedded platform trends.  More and more SoC vendors understand that
they have to not just publish drivers, but actually work *with* the
community to make their devices work.  The same is bound to happen to
modems and other USB gizmos as well.  Some code will probably remain
blobs forever, like DSP code, but most of the firmware stuff will end up
as open source.  Or fail.

Anyway, back to subject... For me it was easier to write the qmi_wwan
driver and the necessary perl scripts to connect using QMI.  You don't
even have to do that.  Just select one of the available QMI libraries
and forget that this modem has any AT commands.



Bjørn

> On Fri, Aug 16, 2013 at 7:11 PM, Madhan <madhan.mepco at gmail.com> wrote:
>
>> hi bjorn ,
>>
>> >Which kernel (i.e. driver) version do you use?
>> *I tried in 3.5 and also in 3.10 *, in both cases i was not successful
>> using AT
>>
>> >Why don't you want to use it?
>> *I am trying to just sort out , what qmi connection is doing in addition
>> after getting the AT .
>>
>> *
>> Cause when I was *sniffing usb* i was able to find the same even when i
>> am using *qmicli , this also
>> uses AT^DHCP? command  *
>>
>> +aleksander : Can you please give us some suggestions
>>
>>
>> On Fri, Aug 16, 2013 at 6:19 PM, Bjørn Mork <bjorn at mork.no> wrote:
>>
>>> Madhan <madhan.mepco at gmail.com> writes:
>>>
>>> > hi ,
>>> > I have used qmi_wwan and cdc_wdm for my device
>>> >
>>> > Sending At commands through /dev/ttyUSB0(option)
>>> >      a) *AT^NDISDUP*=1,1,"my_apn"
>>> >         ok.
>>> >      b)* AT^DHCP?*
>>> >         gives me IP also
>>> >
>>> > But when I set the IP with the provided netmask , dns and gw
>>> > I am *not able to connec*t to internet .
>>> >
>>> >
>>> > But when I use the "libqmi"
>>> > *qmicli -*d /dev/cdc-wdm0 --wds-start-network=airtelgprs.com,PAP,"",""
>>> >  --client-no-release-cid
>>> >
>>> > I am able to *successfully connect *to network using my network
>>> interface .
>>> >
>>> > Cant I do the same without using qmicli ?
>>> > Is there anything in specific which establishes connection after
>>> getting IP
>>>
>>> Which kernel (i.e. driver) version do you use? A few fixes for known
>>> firmware bugs went into v3.9 and the still maintained stable kernels
>>> where they could be applied without changes.  I could not make my E392
>>> work using AT^NDISDUP without some of these fixes.
>>>
>>> But I do believe the QMI connection method is more stable on these
>>> modems.   The Windows driver/application use it, so that's the mode
>>> getting any testing.  The AT command method might work, but I recommend
>>> using QMI.  As you have already found out, it is more reliable.  Why
>>> don't you want to use it?
>>>
>>>
>>> Bjørn
>>>
>>
>>
>>
>> --
>> Madhan
>>