Hi Erich,thank you for your reply and your patience with my issue.I added the static ARP entry as you suggested but the device is still not pingableAlso when flooding the interface with broadcasts the modem doesn’t respond in any way (0.0B received). It’s really strangeThe Update Software is not working for me either because on all three PCs I tested the modem, the Software does not recognise the modem and stays idleit also doesn’t appear anywhere in device managerThanks in advance,ChrisLike. OK, I’m running out of ideas let’s get back to what happened in the first place.When did the stick cease to operate normally?

1. Zte Driver

In what setup did you use it, when it was still working?For the ARP method: it does not always work – the device has to work normally and mustn’t filter for spoofed addresses. Some ancient alcatel dsl modems had a method called “ping-to-life”, that would trigger a reset, when special mac address was associatied with a certain ip and that ip got pinged on boot. But that was very specific procedure of those devices.That the Update SW does not work is strange under the aspect, that linux would correctly discover the device for what it is. Perhaps we need an additional driver on Windows? Usually, if you follow the updater’s instructions from the manual and on screen step by step, it should always work.Another idea would be to get the device into adb mode somehow – but in order to trigger that mode switch, we’d need IP connectivity in the first place, what makes it a cat hunting it’s own tailAny ideas, community?Like.

Hi Erich,thanks again for your answer.When i bought the stick it was working in Ethernet Mode of course, but I switched to Serial Mode according to this tutorial some months ago. It was working just as expected until i switched it back to Ethernet Mode last week (also according to this tutorial). Since then, it’s not working any moreOk, sorry, but the ARP method didn’t workI will try again with the Update SW on Windows. Do you know if there’s an Update SW for Linux available?Thanks in advance,ChrisLike. Was there any black box device involved, that would send AT-commands or modeswitching commands?As reported, I had one case, where a MF831 with a TP-Link router with OEM firmware had unrecoverable problems with the GUI.

That was before the FWUpdate was released to the public and Hofer exchanged the defective device. Afair the TP-Link executed a modeswitch by itself.The modeswitch must have completed – otherwise the device id wouldn’t be 1405. I know of no way to turn dhcp off or changing IPs through AT commands.If you are sure, you didn’t mangle anything else than just switching the mode, and flashing still won’t work, it’s likely a hardware defect (bad flash cells or something like that) you should return the device. That case should still be covered by the warranty. If they refuse write back.It could also be, that you plugged out the stick a second too soon after the modeswitch.

But then again recovery flashing should work.No, there is no Linux FW loader I’d know of. Still it’s android you are uploading.

If you are more into experiments, then please turn to XDA developers forum. They may have the answers you are looking for.Like. Hi Erich,I used sagis3g in combination with “umtskeeper”, which is responsible for keeping the Internet Connection with sakis3g alive (the name may be a bit confusing, it also works with 4g).

The only thing I had to do was installing the package “ppp”, downloading umtskeeper and sakis3g and start umtskeeper with the following command on startup:sudo /opt/umtskeeper –sakisoperators “USBINTERFACE=’2′ OTHER=’USBMODEM’ USBMODEM=’19d2:0016′ APN=’.’ SIMPIN=’.' ” –sakisswitches “–sudo –console” –devicename ‘ZTE’ –log –silent –monthstart 8 –nat ‘no’ &This created a Network Interface called “ppp0” which had the WAN IP-Address and connected my device to the Internet.Thanks,ChrisLike. In modem mode, pppd uses chat to control the modem via AT commands. Chat usually initializes a modem with at&f ate1 and at&v1 or similar. In rare cases even registers are set. On the stick the AT command set, as far as I’ve noticed, is provided by a daemon on top of android. It’s not completely unlikely, that an AT command could switch profiles that way.

It’s strange nevertheless. It shouldn’t happen anyway.What are you going to do now? Will you return the stick or will you keep experimenting? Let me know, please.Like. Hi Erich,thanks for your reply.I already tried to get back to serial mode with usbmodeswitch but I wasn’t able to find the correct “MessageContent” which is necessary to switch the modemall the messages I tried so far (also the one for the mf823) wouldn’t work for me, because it seems that the MessageContent also has something to do with the mode you want to achieve (to be honest, I’m not concern with what it does anyway), but the error message says that the modem is already in the mode I want to have it to. Of course I tried to switch it from 1405 to 0016, but usbmodeswitch would always say that it’s already in the mode that I wantI will try again and post the output as soon as possible.Thanks in advance,ChrisLike. Hi Erich,now I’ve tried to switch the modem with usbmodeswitch.

What I tried so far:1. Edit /etc/usbmodeswitch.conf and add the following lines:DefaultVendor=0x19d2DefaultProduct=0x1225TargetVendor=0x19d2TargetProduct=0x1403MessageContent=”000000000000″2. Plug the modem in and wait until it comes into mode 1225 (you need to be fast before it switches to 1405 automatically)3. Run “usbmodeswitch -c /etc/usbmodeswitch.conf”4. “lsusb” now shows mode 1403, but I don’t notice any difference, device still doesn’t give me an ip or works when assigning a static ip.This was the only other configuration that was “working”. Of course I also tried to switch to mode 0016, but if I write 0x0016 as TargetProduct, it switches to 1403 anywaythat’s why I think that the MessageContent has something to do with the mode you want to achieveI’ve also tried multiple MessageContents, but the only one that made a difference (1405 to 1403) was the one that I found on used for the MF190.

Any other MessageContents found didn’t make a difference at all or threw an error message that the code isn’t working like so (device already connected and in 1405 mode):cmd: sudo usbmodeswitch -v 19d2 -p 1405 -V 19d2 -P 0016 -W -M “000000000000” -m 0x01 -r 0x81Output (last lines): Error: can’t use storage command in MessageContent with interface 0;interface class is 2, expected 8. AbortThe MessageContent used here is the same as above, but the error message was the same with others used.I know it’s getting more and more complicated but I hope you understand the lines above.Thanks in advance,ChrisLike.

Thanks for your reply and all the infos.1. Please keep in mind, that usb-modeswitch may in some cases already provide a different configuration and get’s triggered automatically by udev, hotplug and alike. If so, your command line and scripts will interfere.2. AFAIR/AFAIK you can always send two switching commands at once. See -2 from the command’s built-in help.3. Switching should alway happen from 19d2:1225 to any of the other modes e.g.

0016,1404,1405, I don’t think that it makes sense to switch from 1405 to any of the others directly – why it would the command would throw an error in this state.4. See on mode 1403.5. Will the stick stay in mode 1403 after a replugging procedure, or will it fall back to 1405?If it does not keep a mode setting state, this could indicate a faulty flash chip – usually the device ‘remembers’ modem mode and cdc mode. I don’t know if that applies to RDNIS+MSD, as well.

If the flash chip really was faulty, you should return your MF831. Switching alone won’t harm the device, usually.

At least the flash recovery should work.I’ll be offline for a few days from now. Good luck in the meanwhile.Like. Hello Erich,Thanks for the howto, it was very useful.I would just like to give some feedback which may be useful for others. I’m using a RouterStation Pro with OpenWRT 15.05.1, more precisely:root@voyager:# cat /etc/openwrtreleaseDISTRIBID=’OpenWrt’DISTRIBRELEASE=’15.05.1′DISTRIBREVISION=’r48532′DISTRIBCODENAME=’chaoscalmer’DISTRIBTARGET=’ar71xx/generic’DISTRIBDESCRIPTION=’OpenWrt Chaos Calmer 15.05.1′DISTRIBTAINTS=”root@voyager:#After switching the MF831 to modem mode it was detected automatically, so this version of OpenWRT definitely has a suitable usb-modeswitch JSON file.

I had to modify the device to /dev/ttyUSB1 though, but that was the only manual change.For the record: I’m a customer of Drei and using one of their Hui Flat packages. You can indeed tick a checkmark on their web portal which gives the router a publicly visible IPv4 address.Cheers,GaborLike. All the same codebase. But I’d give LEDE 17.01.2 a try – now, that LEDE and OpenWRT rejoined forces, it’s the newest available codebase of OpenWRT.The speed issues could have different reasons:First, the MF831 is an android device that is actually doing tethering on the CDC Ethernet. Let’s call that its native mode of operation.If we are using the android device in serial mode, it seems, that mode is an emulated one, providing the three interfaces described. At this point performance issues are already likely to happen.Second, since mobile networks are radio networks, external distortion, reflection etc may always appear.You can measure only the incoming signal levels, but you will never know, if the sent (outgoing) signals of your modem arrive just the same way at the base station.

In AT/serial mode the commands for querying the signal strength is AT+ZRSSI and for determining the mode of operation (as also indicated by the led’s colour) with AT+ZPAS?Third, regarding NAT: You cannot really escape carrier grade NAT, unless your tariff allows you to pay for an optional external IP. So in CDC mode you will have at least a three level NAT (CGN,Android,Router), in serial mode at least a two level NAT (CGN, Router), where CGN could itself hold some more layers in theory.Your speed tradeoff will consist of various problems:1. Serial speed itself.2.

MTU sizes (Lowered in mobile Network to at least 1492 (because of PPP).3. Masquerading on Linux, MSS Clamping, ad 1: I just tested a few things on my laptop, with the MF831 directly connected to it. I am using Yesss (A1 Telekom Austria in this setup).+ZRSSI: -108,-13,-74,2.4AT+ZPAS?+ZPAS: “LTE”,”CSPS”As you can see, I don’t have optimal radio conditions. An RSSI of -108 dB isn’t amazingly good, so I cannot expect high data rates anyhow.Speedtest.net and speedof.me vary. The peak was about 30Mbit/s DL, 12 Mbit/s UL. The median was around 15 DL 10 UL.

When setting the serial speed to 38400 manually, throughputs attain a non representative peak of 20 DL, 9 UL and a median of 17 DL 9 UL. Did you notice, that UL values are rather steady?ad 2) a lowered MTU will always mean, that the same amount of data is more likely to get split up in smaller packets, of which we need more In case of VPNs this is a relevant factor, if fragments should be 1500, while the layer below only transmits packet sizes of 1492. The payload of 1460 in case of IPv4 would decrease to 1452 likewise. Instead of one packet, you suddenly transmit 2. Factor 50%.ad 3) You could lower the MTU of the devices behind your NAT gateway or optimize the MTU (see 2). Clamping will help, but affects only TCP, not UDP or ICMP. I’dont know, if mobile network operators support baby jumbo frames already, if so, that could be a solution to the problem.

Please report back on that, if you find out more.NAT – Connection tracking is useful, but on elderly pieces of hardware, if may have impacts on performance – especially when using zram as a swap on low memory devices.For the moment, I don’t see problems caused by the emulator on android, but that’s just a single opinion.Like. I just tried some thing on my TL-WR1043NDv1 running lede 17.01.2:I modified /etc/chatscript/3g.chat:ABORT BUSYABORT ‘NO CARRIER’ABORT ERRORREPORT CONNECTTIMEOUT 10“” “AT&F”OK “ATE1”OK“AT+ZSNT=6,0,0”OK“AT+CREG?”OK“AT+ZRSSI?”OK ‘AT+CGDCONT=1,”IP”,”$USEAPN”‘SAY “Calling UMTS/GPRS”TIMEOUT 30OK “ATD$DIALNUMBER”CONNECT ‘ ‘AT+ZSNT=6,0,0 should lock the stick to the LTE bearer.AT+ZSNT=0,0,6 should prefer the LTE bearer.We’ll log signal strength on connection, too (ZRSSI)Could you test, if that helps with the speed issues?Like.

Did you configure the port forward on the MF831, like the russian forum suggests? Then you would have modified the CDC profile on the modem?

That change is stored to the modem’s flash and would remain persistent – as it happend with the modifications regarding the menu. What you call factory settings simply means to switch these profiles in normal operation. In order to restore really everything, use the manufacturer’s flashing tool.As mentioned before, on my own specimen the green light represents the bearer WCDMA/UMTS. Blue indicates LTE access in my case. I’ve double checked this. So I am wondering, if you use a different model or revision.My suggestion was for serial mode, not CDC mode – and of course the MTU is lowered eight Bytes in a PPP session running on the router, unless this is handled somehow you can always try to find out by pinging your next neighbour in the routing table with bigger packets.

If I am right, ping -M do -c1 -s 1452 nexthop would work, while ping -M do -c1 -s 1453 nexthop would fail: ping: local error: Message too long, mtu=1492Remember, that the ping command of OpenWRT/LEDE does not understand the switch “-M” which set Fragment/Don’t fragment bits – so do that from your linux pc.Like. Issues: usbmode seems to auto-reset the stick to CDC mode on each reboot in 17.01.2. I didn’t recognize other major issues in that test setup.You can disable usbmode: /etc/init.d/usbmode stop; /etc/init.d/usbmode disable.I wonder, if the modeswitch from 1225 to 0016 would be affected that way. If so, we ‘d have to replace the file /etc/usbmode.json with an appropriate one.Sometimes only one port is detected instead of three ports. Bind driver option to 19d2:0016 by setting this in /etc/rc.local before “ exit 0“:grep -i '19d2 0016' /sys/bus/usb-serial/drivers/option1/newid /dev/null echo '19d2 0016 ff' tee /sys/bus/usb-serial/drivers/option1/newidI have to admit, that rarely use serial mode any longer in my own setups now, since my tunnel server and various scripts can overcome most of the problems. CDC is now also some kind of advantage for me: I can exchange the stick including the prepaid SIM and don’t have to care about setups. I even save a little RAM on the LEDE box this way.

Zte Driver

Since I don’t have a public IP with cheap prepaid SIM I’d have to deal with CGN issues anyways. The only drawbacks are, that miredo is missing for LEDE and 6to4 and tunnel brokers don’t work that way but I can tunnel IPv6 through the encrypted main tunnel, too. (Here in Austria there is still no widely used IPv6 mobile setup).

Nevertheless miredo came in handy as a second tunnel for maintenance. The other thing is a deadlock of the mf831 sometimes.

It switches to real download mode (0076), and I can only stop that by unplugging/replugging– but I guess, that’s a programming bug in one of my older reconnect scripts.Pragmatism has won.Like. Hej!I read this post and its’ comments with great interest, not because I need to change the mode of my modem, but because I’d like to try a factory reset.

I have two similar MF831 modems. They both have the same settings as far as I can see from the web interface. They both work nicely with my Mac, but one of them has suddenly stopped working on my Raspberry Pi 3 (Raspian Stretch).The green light blinks, it shows up as 19d2:1408, and if I do ifconfig it shows up as usb0 just as the health one does.

But the inet address is different: The healthy one sows 192.168.0.XXX and the bad one 169.254.113.XXX.And the bad one is “all but” unusable: I cannot, for example, ping outside adresses, neither by name (i.e. Google.com) nor by adress (i.e.

8.8.8.8).What does work is outbound udp: I run Ardupilot on the pi which outputs its’ data to a fixed outside ip on port 14550.I tried, among other things, to do: Call– which did its’ thing, and then I reverted via AT commands which also worked well, in the hope that this would reset something back to factory settings, but no luck there.Any Ideas of what might be going on?Like. Hello Fredrik!On the model I have, a steadily lit green LED would indicate a 2G or 3G connection, while blue means LTE. The LED would only blink in red on a reboot, blink in green or blue for a short time, while the connection attemps -i.e. Registration with the network- are in progress.Mode 19d2:1408 is currently unknown to me – you may find an answer to that question at. It could also be, that you have another hardware revision of the modem. Another idea would be the usbmodeswitch package – it sends an initialization/modeswitch command,to the modem, shortly after it has been plugged in.

The base mode would be 1225. W/o usb-modeswitch it would automatically turn itself to 1405 after a while, afaik. Check if usb-modeswitch is present on your device.

If so try to deactivate the modeswitch by uncommenting/removing the section for 19d2:1225 or it’s decimal equivalent (make a backup of that configuration files before altering these).169.254.113.XXX is an APIPA address. That is an autoconfiguration or „Zero config“ mechanism that will choose a quasi-random address out of 169.254.0.0/16 in the abscence of a dhcp server. That address does not stem from the MF831! It’s your PC’s self-assigned address.

You may try to give your PC a static IP for usb0 – such as 192.168.0.5/24. The modem is listening at 192.168.0.1 per defaults and will provide a DHCP server (unless altered as described by the russian forum posts mentioned earlier). If all works well, you can ping the modem at 192.168.0.1. Routing outside still wouldn’t work unless you define 192.168.0.1 as the default router and dns server statically. But you would rather prefer to reset to factory defaults. The „goform“-link you reposted, does not do that.

It’s a modeswitch command only. I wonder how that link could work, when you can’t reach the modem on it’s IP address in the first place?! You didn’t try that on the faulty modem, did you?!The mf831 is a native android device. Look into lsusb when plugging the faulty modem in again.

It won’t start as 19d2:1408, but 19d2:1225 rather.If you manage to get it into android mode without CDC or modem emulation, you can connect through adb and try to debug from there, but I would not recommend that. Better try a full factory reset:A full factory reset would require to reflash the original zte modem firmware for your specific device. Go ask ZTE or your distributor for that file (only works on the Windows platform). Real download mode has the usb id 19d2:0076, afair.I hope, that info helps you to recover. Since this is not the first reply regarding a faulty modem, please share any information on how it may have happened to become faulty.

Perhaps the commentors here will find a common solution alltogether.Like.

I think you just made my day!!But i don't want to celebrate yet.Let me describe what happened.Everything worked fine with the config files and the firmware update tool worked perfect. Hey man that's a trick not to get scared to brick it:) maybe my english is not so good but the general idea is to disconnect it in NV restore moment and than to falsh it again.Well yes.

This firmware sets 12345 default password and so on. The only one problem i have is that my modem doesn't connect automatically to 3G i need to enter to Web interface and to push Connect:)But i think i found a solution. Tehre's in /etc/copy a config file, i think if you play with that file you'll find an option to make it Auto connecting to your APN:)Really cool that it works for you! Hehe great day.