Netgear 340u

[Markus Gothe]

I am not sure but you might be able to reset the NVRAM using fdt.exe under Windows.

Generally I would say AT!UDPID is to prefer over AT! 
UDUSBCOMP when trying to switch the modem.

//Markus - The panama-hat hacker

On 05 May 2014, at 08:43 , Bjørn Mork <bjorn at mork.no> wrote:

> AT commands over MBIM is a vendor specific service, if implemented. I don't think that is likely on the 340u because we haven't seen it on any other Qualcomm based sierra device. But you never know.
> 
> Exploring MBIM is interesting in itself. And building libmbim shouldn't be more complicated than building libqmi.
> 
> 
> Bjørn
> 
> On 5 May 2014 07:59:06 CEST, Noah Taber <noahtaber at gmail.com> wrote:
>> Yes, the 340u is detected using mbim.  I don't think there's a native
>> mbim
>> package for the raspberry pi.  I'll work on compiling that later this
>> week.
>> 
>> Does anyone know how to send AT commands with mbim on any system
>> (linux,
>> osx, windows 7/8, etc.)?
>> 
>> Thanks.
>> 
>> Noah
>> 
>> 
>> On Sun, May 4, 2014 at 1:08 PM, Bjørn Mork <bjorn at mork.no> wrote:
>> 
>>> That's comp14. Not the same as 9, I'm afraid.
>>> 
>>> But the modem is of course not useless even if it is locked to MBIM
>> only.
>>> Install libmbim and take it from there.
>>> 
>>> 
>>> Bjørn
>>> 
>>> On 5 May 2014 01:00:34 CEST, David McCullough <
>>> david.mccullough at accelecon.com> wrote:
>>>> 
>>>> Bjørn Mork wrote the following:
>>>>> Noah Taber <noahtaber at gmail.com> writes:
>>>>> 
>>>>>> Well, I think I'm done with the 340u.  I'm pretty sure I broke
>> it
>>>> tonight.
>>>>>> I ran the following AT command:
>>>>>> 
>>>>>> AT!UDUSBCOMP=9
>>>>>> 
>>>>>> I only have a MBIM interface to the device.  I cannot connect to
>> it
>>>> through
>>>>>> serial to issue anymore AT commands.
>>>>>> 
>>>>>> Do any of you have any hints?  Otherwise, I'll get a different
>>>> device.
>>>>> 
>>>>> Shit.  I was just writing you an email where I tried to warn about
>>>>> exactly that.  Sorry.
>>>>> 
>>>>> I am pretty sure there is some way to fix it, but we just don't
>> know
>>>>> how.  These settings are most likely stored in some NVRAM
>> variable.
>>>>> One nice thing about that MBIM function is that it implements a
>> QMI
>>>> pass
>>>>> through, so you still have all the power of QMI available.  So if
>> we
>>>>> knew how to fix this by using QMI, then it could be fixed.  It is
>>>>> probably possible to force the modem into boot loader mode, where
>> you
>>>>> should be able to rewrite most of the flash contents including the
>>>>> NVRAM.
>>>>> 
>>>>> In theory.  I wouldn't know how to do that.
>>>> 
>>>> It should be ok,  all the 340u I have dealt with are in mode '9' and
>>>> only
>>>> present the MBIM interface.
>>>> 
>>>> Under linux they present two configurations, and the MBIM interface
>> is
>>>> configration '2'.
>>>> 
>>>> All i even do to get these modems operating is change them to
>>>> configuration '1'.
>>>> 
>>>> Find the correct /sys/bus/usb/devices/.../bNumConfigurations for
>> your
>>>> 340u (the idProduct and idVendor files in the same directory will
>>>> help).
>>>> 
>>>> If this is working like I usually see, bNumConfigurations will be 2
>> and
>>>> bConfigurationValue will be 2, fix this with:
>>>> 
>>>>      echo 1 > bConfigurationValue
>>>> 
>>>> Which should get you back to the QMI/tty interfaces (option number
>> 6).
>>>> 
>>>> Cheers,
>>>> Davidm
>>> 
>>> 
> 
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20140505/c698b730/attachment.sig>