Problem with E392 connection using wwan0

[Madhan]

>>I must admit that I see this excercise as somewhat pointless.
Ya , I was just giving a try . Was in eager to know how it happens .

>> Just select one of the available QMI libraries
>>and forget that this modem has any AT commands.
Ya , it work . Thanks for your support . Thanks for qmi_wwan




On Thu, Aug 22, 2013 at 1:19 PM, Bjørn Mork <bjorn at mork.no> wrote:

> 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
> >>
>



-- 
Madhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20130822/b9525c0b/attachment-0001.html>