Reg AT commands to configure HUAWEI E392 dongle

[Bjørn Mork]

Dan Williams <dcbw at redhat.com> writes:
> On Wed, 2013-02-27 at 11:25 +0000, swarnalatha.subramaniya at wipro.com
> wrote:
>> 
>> Hi,
>> 
>> I am trying to use E392 dongle in an residential gateway.
>> 
>> I am trying to configure the dongle with following AT commands,
>> 
>> at^ndisdup=1,1,"myapn"
>> OK
>> at^dhcp?
>> ^DHCP:7796124d,f0ffffff,7196124d,7196124d,470d5c1,c60f4382,236800,236800
>> 
>> Converting the address to dotted quads to make them more readable:
>> 77.18.150.119,255.255.255.240,77.18.150.113,77.18.150.113,193.213.112.4,130.67.15.198

Hey, those DNS servers look familiar. Nice to see other Telenor users
here :-)

Did you get that device as a part of the internal LTE testing, or is it
a newer, commercially available, device?

>> ifconfig wwan0 77.18.146.77 netmask 255.255.255.252
>> ip route add default via 77.18.146.78
>> But i am not able to connect to the network with AT commands.
>> 
>> Please let me know if i am missing any AT commands ????????
>
> No, that looks correct.  Also make sure that your WWAN interface is set
> to "NOARP" with "ifconfig wwan0 -arp" or something like that.  Also,
> instead of doing AT^DHCP? try simply running a DHCP client on the
> interface after AT^ndisdup returns OK.  We've seen some devices that
> don't seem to work correctly with static IP from ^DHCP but do work when
> you run dhclient on the interface.

Yes, that is how my E392 works. I believe I've seen exactly the same
issue when reading the addresses using QMI (which I guess is how the
firmware implement the AT^DHCP command).  Traffic flow seems to depend
on using DHCP to configure the device.

But I have never gotten the device to work reliably at all using
AT^NDISDUP either. The connection is established, but the ethernet
header of the received packets is either missing or bogus.  Which will
prevent DHCP from working... This might be an older firmware issue which
is fixed now, though.  My firmware is from 2011.

I'd certainly recommend QMI for this device.  That is the only way I
have made it work reliably.  And I did try lots of AT command stuff on
the E392 before I ended up writing the qmi_wwan driver.  I also tried
writing a driver which fixed the messed up ethernet header, but the
exact firmware behaviour seemed to depend on device serial number, time,
IPv6 vs IPv4, moon phase etc. so I gave up trying to reliably detect the
bug. Use QMI and it just works.


Bjørn