Attn GL.Inet - sick and tired of GL-X750

On receiving the DL-X750 (from Amazon store, on the 20% promotion) I put an Optus LTE SIM in (which works fine in a borrowed Netgear AC800S under the APN “yesinternet”), and connected it to my Intel NUC on its internal LAN port (statically configured to 192.168.8.2 normally, or 192.168.1.2 for Uboot mode or ROOter).

I have so far experienced the following:

  1. The unit seemed to have been repacked (a little sloppily in fact).

  2. On first power up, there was already a Wifi network called “Raspberry Pi” listed under previously used SSIDs. I have no such network.

  3. It occasionally hangs (twice so far). LEDs are still on, but stops replying to ping on the physical LAN. It’s not the PCs fault. Works again after repowering.

  4. It initially seemed to work fine on the Optus network, but it became completely unusable after selecting LTE Band 1 from the built-in AT commands list. As noted in the bug report (Urgent - how to completely reset a DL-X750 to shipped config) nothing I could then do, and I tried everything, would make it connect to Optus again.

  5. After then, on advice, issuing the (undocumented) “AT+QPRTPARA=3” command to restore the modem to factory settings, it seemed to work again. The status info showed it was successfully connected to the Optus network on Bands 3 and 28. But it seems it won’t actually communicate, and fails all the built in diagnostic tools (even DNS lookup). Note: I didn’t know that when I marked the bug report as resolved.

  6. The LAN port sometimes doesn’t work in UBoot mode (PC set at 192.168.1.2). To get it working again I had to boot it normally, connect by WiFi, SCP the factory firmware file to it, use the sysupgrade (?) command to flash it over SSH, and reset.

  7. I’ve tried it with ROOter. According to this forum and Whirlpool, it should work with ROOter as a no-brainer, inc. on the Optus network. However I can’t get it to work. Again, it seems to connect to the Optus network but won’t communicate on it. All I did was to reset the config and set the APN to “yesinternet”. That should work. Optus requires no extra config. I’ll chase this up with the ROOter people, but I suspect it’s going to be related to the above.

  8. When booting it into UBoot, it is sometimes impossible to use the simple web UI to upload a firmware file. It fails, time after time with “connection reset”. Happened from two different PCs and cables, both known to be good. I’ve seen others mention this problem.

  9. If you use the stock firmware to flash (official) ROOter firmware, it looks like it works but it doesn’t. You’re told that the file checks out OK, and a progress bar counts (slowly) from 0% to 100%, while the X750 LEDs cycle over and over from left to right. Then, at 100%, all LEDs except the WAN one go off, and you’re told that communication with the X750 has been lost (which is kinda expected at that point). It’s no longer serving HTTP but you can still ping it and SSH to it. If you restart it (power cycle or SSH-ed “reboot” command) it then…wait for it…boots back into the stock firmware. This is 100% repeatable. And if your answer is “we don’t support 3rd party firmwares” then my answer is “then don’t make it look like you do”.

I’m already sick of the product. It took 2 weeks to receive it from Amazon in the first place, and I’ve now wasted a (highly frustrating) further week on it.

I don’t want to risk having no “proper” internet as we near xmas.

So I’d now like to know:

  1. Have I been sold something faulty, that has already been returned as faulty? I strongly suspect this is the case. Can you check this from serial no., MAC, IMEA, whatever?

  2. If not, has (briefly) setting it to LTE Band 1 somehow rendered it useless on the Optus (or any) network. If so, is there anything else I can try to fix this? Or did the “AT+QPRTPARA=3” have even done that?

  3. Are there extra ways of resetting the unit that might make it work again?

  4. Sorry but I have to ask - is this a problem product (or firmware release) generally? Would I be better off with another product? I bought this because someone, apparently linked to GL.iNet, talked me out of buying the MiFi on the basis that the X750 was better.

  5. If the appropriate way forward is to exchange it, what can you do to get another unit here (Perth, Australia) as quickly as possible?

Thanks.

  1. All devices should be new and not used. If you receive the product and you are asked to set up a password, it should be new. There should not be saved SSIDs inside. Otherwise this seems impossible thing. When you get a used device you will not be able to login the device and need to reset for the first time use.
  2. Do not change the band if you are not sure. I thought that fixed your problem.
  3. and 4. The firmware should be OK. If you have any problem when using in Australia you may ask @limbot
  4. If you bought on Amazon AU, you change change it via Amazon AU. That is the easily way.
  1. That’s just not true. If you factory reset it, you’ll be asked to enter a new password after it boots. I know this because I’ve done it a million times in the last week. I know there shouldn’t be SSIDs already defined. That’s my point. Someone has used this unit before, and somehow they’ve reset it such that it asks for an initial password but doesn’t clear previous SSIDs (unless the latter is hardcoded in the firmware for some reason).
  2. If it isn’t safe to set a valid band without risk of completely breaking the unit, even across reflashing and resetting the config, then remove this feature from its web UI. It’s a built in command. As I said, the modem reset command worked in that it seemed to be able to connect to the Optus network again. But what I didn’t know then, is that it still won’t communicate across it.
  3. Is he “official” support?
  4. Is this your store? https://www.amazon.com.au/gp/product/B07NPGGD1B/ It doesn’t have any product left.

I added 8) to the OP. I forgot that problem when I wrote it, and no doubt some others too.

  1. The raspberry Pi problem, do you mean that there is a Raspberry Pi client? This may be caused by factory testing. We used Raspberry Pi to test wifi throughput. We will fix the testing process and reset the device after testing.
  2. The AT should be fairly safe. Also this is a killer feature of our device. We will not remove it.
  3. Limbot is not official support but he is in AU and he has tested our device quite a bit, including X750. He is also active in the forum.
  4. Yes this is our store. It is out of stock and I am checking with logistics what to do.

About uboot: we had problem in uboot especially in AR300M and B1300. But seldom happen in other devices.

I have a question: can you check if you SIM is working now in smartphone or other 4G devices? I understood that you said it was working well but if you can check again that would be helpful. Ensure it has pretty of data and credit.

During our production, we will use Raspberry Pi to connect to the x750 WIFI for testing. After the test, the factory Settings are not restored. Therefore, x750 will record a Raspberry Pi offline client.

Have you checked the SIM card charges?
In my experience, it could be your SIM card

The problem has to do with your computer’s network card. You can try another computer, or use a switch between your computer and your router.

Thanks for your reply.

  1. Apparently there should be a “Rasperry Pi” SSID as it’s part of your manufacturing process (see other answer on this). I wondered if it might be something like that and it’s been confirmed, so that’s fine.

  2. Well you can’t really say, one minute, that it’s a feature I shouldn’t use, and then say, the next, that it’s “safe” and a “killer feature” which you won’t remove. If there’s any chance that using the Band 1 (2,3,4…) feature breaks the modem configuration in a nasty, hidden, hard to fix way then it should be investigated (and I’m happy to help).

  3. Ok. I know him from another forum.

  4. Ok. I’d appreciate anything you can do to help.

The uboot issue is intermittent. Sometimes I get it over and over, sometimes I don’t get it for a while. I’ve been doing an awful lot of flashing in the last week, probably more than most people do, while investigating other problems. Maybe that’s why I see it where others haven’t (or maybe my unit has an intermittent LAN port problem).

OK, that’s good to know.

There’s nothing wrong with the SIM card. It works fine on a Huawei 4g router and an AC800S, it initially worked on the GL-X750, and it worked again on the latter just now (on stock fw).

All I have to do now is work out what changed to make it work again (if it’s not some random intermittent problem). At least I know it’s not some permanent config problem following use of the Class 1 command.

However it still doesn’t work under ROOter, which fails in exactly the same way.

Oh come on. The para you originally quoted ended with “Happened from two different PCs and cables, both known to be good. I’ve seen others mention this problem.”.

All things considered, I think there’s an intermittent problem with the device (most likely hardware but possibly firmware), leading to things like intermittent LAN port failure, and maybe intermittent modem card failure. Might even be the PSU. Or thermals (it gets uncomfortably warm and I’ve seen it hit 58C ).

This hasn’t been mentioned in this thread, but there is a chance that you got an older stock device. There was a recall not long ago related to a capacitor that would cause overheating. Seems almost like the issue you might be having.

It would explain the bad experience you are having, as other users don’t have your issues at all.

1 Like

Wow I didn’t know that at all - thanks!. And it certainly gets hot. And excessive heat would explain most everything (except ROOter not working). I live in a hot climate (Perth, Australia) and it’s just ramped up to summer heat in the last few days. Coincidentally about when I started experiencing problems.

I might try opening the case and putting a powerful fan on it. Though it’s probably not a good time to void my warranty.

OTOH I just bought mine and it’s revision GL-X7506. So probably doesn’t have the cap?

What do you say, GL-iNet?

Problem 9) added to OP.

Why and where?? Are there any place we state it support ROOter firmware?

The bit where it explicitly validated a ROOter firmware file, dowmloaded it, and appeared to be flashing it.

BTW, note that the converse isn’t true. ROOter rejects your firmware files as invalid.

Could you send a link to where you see that?
GL only supports their own firmware, even for “vanilla” OpenWRT support is forwarded to their forums.

I really think I explained it clearly in 9) in the OP.

The point is that your device happily accepts a ROOter firmware, says it’s ok, appears to download it, and appears to flash it. But then it hasn’t worked. Which is bad.

Conversely, if you ask ROOter to flash one of your firmware files, it says “nope that’s not allowed”. Which is good (it would of course be better if it actually did it).

I really don’t know what I’m supposed to provide a link to.

Well you can drive your car down to the gas station and pour diesel into a gasoline car.
I don’t see why GL must block all other firmwares?

You should only download from the official GL download page, or use the upgrade system already on the router.

GL can also not guarantee that the firmware has not been tampered with and is exposing your data unless you download the official firmware from the official site, and not other places.

I guess GL maybe needs to add a warning message in the upgrade page, to make it more clear.

That ROOter apparently uses a format based on OpenWrt’s that allows it to pass the “right file format” test is neither a GL.iNet nor an OpenWrt problem. While loosely based on OpenWrt, ROOter is definitely not OpenWrt.

That it doesn’t corrupt your router is half good software design from OpenWrt and GL.iNet and half good luck on your part.

You should consult any third-party firmware’s instructions for flashing. This includes flashing “vanilla” OpenWrt on a GL.iNet device.

Edit: I’d be happy to explain why once an image passes “sanity” checks, no further information can be passed to the user. I can go into technical details, but basically it needs to stop all services (including the GUI and SSH), unmount the root file system, and run from memory. I can also say that it is impossible to “fully validate” any firmware on an embedded device in the all-in-one class without booting it on the device.

Of course it does. They’re all based on OpenWrt.

Firstly, I cut my teeth on embedded systems development 35 years ago. I like to think I understand the issues.

Let’s remember that ROOter and GL stock are, in practice, the only two firmwares for this unit.

Given that ROOTer spots that GL firmware is “wrong” and reports it, there’s no reason for the converse not to be true.

Or, given that UBoot can flash both, there’s no reason why GL stock couldn’t either.

What isn’t acceptable is for GL stock to look like it’s working, all the way through, when in fact it isn’t. No error message (except for one caused by the HTTP server having been shut down ready to be overwritten)

To claim that is “good design” is simply ridiculous.

Put that on top of everything else mentioned here, and “ingrained sloppiness” screams out.

And it is just sloppy implementation. I’d respect a developer more if they admitted that and corrected it, one way or the other, than spend time arguing the toss.

It’s also sloppiness to leave a history of WiFi connections in a shipping product (making the user think they haven’t got a new product) which they then say is impossible, not to mention leaving in a “development” capacitor that causes overheating and prompts a product recall. I note they still haven’t responded to whether my unit might be affected.

Putting an operation in the main UI that breaks the product such that there’s nothing an end user can do to restore it (until a magic, undocumented, AT command is provided)? Sloppy.

And speaking of arguing the toss, I reported intermittently bad communication on the LAN port, between the device and multiple PCs using multiple cables. Their answer? You must have a bad cable. The actual answer was that there is a problem with the unit, as has been the case with other models, and it can be mitigated by changing the MTU (suggested to me on another forum by a 3rd party, not here by GL).

If you can’t see a pattern, you’re blind.

Anyhow, I’m not wasting any further time on this. The unit is going back and I’ll not be buying a GL product again.

Ummm…have you noticed they make diesel nozzles too big to fit into petrol tank holes? I wonder why that is.

All other firmwares?? You mean the one other one (in practice)?

Where have I said otherwise? And I am using the upgrade system already on the router - that’s the point.

Ever heard of digital signing? And you’re saying that ROOter shouldn’t exist, or that GL should distribute it, which is clearly ridiculous and contrary to their commercial interests.

Exactly. A warning if you select a non-GL firmware file. We got there in the end!! :smiley:

Maybe you know which capacitor is causing the problem and if it can be fixed by replacing the component?
And I’m wondering where exactly the temperature sensor is located?