I finally found the time to register and join the party here. I'm Dairyman from the WP forum and the programmer behind the custom OpenWRT firmware. I live in Canada so I'm in a totally different time zone than everyone else here and my replies may be a bit slow.

The problem you are experiencing with the E398 stem from the fact that there is no support in ModemGUI for a 4G Huawei modem. Didn't have an example to work with at the time and never added it.

The program checks the modem for the mode and band it currently is set for and adjusts the dropboxes accordingly. It is being confused by a 4G setting when it doesn't know what that is. So what the dropboxes show is what the modem reports it is using.

Using Auto should allow it to use 4G as the modems seem to connect to the fastest mode available.

I will fix this problem in ModemGUI in the next release, as I get time.

A new version of the firmware is being created right now and will be available very soon. It adds a feature that will allow you to add a modem that is currently not supported and have it remain supported even after upgrading the firmware again. Simple to do and it is all through the web interface.

That is a good way to do it until I fix the program. You can set mode and band in one command. I just have to find out what the values in the command are for 4G.

Glad to be here. We have found the TP-Link routers to be cheap and reliable and, with the new firmware, a great piece of hardware for 3G/4G usage.

I have found the AT Command to set a Huawei modem into 4G mode. It is :

AT^SYSCFGEX=03,3FFFFFFF,2,4,7fffffffffffffff,,

This will set it to 4G mode with band selection automatic.

Use ModemGUI in the Custom Command dialog to execute this command.

One thing you have to make sure of is that the modem has finished connecting before you use ModemGUI. Don't attempt to use it while the modem is still working on the connection or really strange things can happen.

This is caused by several AT Commands being sent to the modem from different sources (connection script and ModemGUI) and they conflict with each other. Guaranteed to cause a program crash.

I have found that for some things, like SMS, you have to stop all other AT Commands from being sent to the modem or the program crashes. Actually it sits waiting for a response that got funneled off to another process and gets locked in a waiting loop.

FYI, Automatic is just ttyUSB1. Long boring story as to why this so I won't relate it.

One other thing that may be happening here. WF was probably using the PPP protocol when his image was taken. That was the original setting for the E353. You are using QMI since the firmware was changed to support this for the E353.

What can happen (it does for ZTE modems) is that using QMI changes the command port from that used in PPP. For the MF668 the command port in PPP is ttyUSB2 and using QMI it is ttyUSB1.

You sometimes have to experiment to find the correct port.

This post has been edited by DairymanCanada: Feb 27 2013, 09:11 AM

You are probably getting DC-HSPA+ but ModemGUI is not reporting it correctly. If it finds HSPA+ in the network type it assumes it is HSAP+ and not DC-HSPA+.

I'll correct this problem in the code.

Other modems will also have this problem and will need to have it fixed.

Thanks for the bug report.

If you have the Signal Log activated (box is checked) in ModemGUI you can look in the Signal.log file (a text file) and see exactly what was returned by the modem. I just seen another log from a 320U that shows a DC-HSPA+ network in the log file.

-------Time-------------RSSI-----RSCP------ECIO------LAC---CELLID---Network-------

Mon Mar 04 20:45:12 : -099 -096:-097 0000:-006 3450 01410298 DC-HSPA+
Mon Mar 04 20:45:24 : -099 -097:0000 0000:0003 3450 01410298 UMTS
Mon Mar 04 20:45:36 : -099 -097:0000 0000:-001 3450 01410298 DC-HSPA+
Mon Mar 04 20:45:48 : -099 -098:0000 0000:0000 3450 01410298 UMTS

Just report any thing that doesn't look right to you and I'll see if it is a bug and will attempt to fix it. I have fixed this for ZTE and Sierra modems and am currently finding a fix for Huawei modems.

This post has been edited by DairymanCanada: Mar 5 2013, 02:02 AM

This is the Network Type that you are connected to. It is something like HSPA, WCDMA, EDGE or the like.

The program gets this information from an AT Command and then converts it into a set of standard network types. Different modems give the information in different formats so this conversion is necessary. Some give it in text and some as a number.

The program checks through a list to convert this information and, if the network type isn't in it, returns NA.

The network type that you receive is one I've never see before and the program just rejects it. I'll fix the program so it passes the information on to the display part untouched if it can't recognize it. That will fix this problem.

Thanks for the bug report.

What modem are you using in the router?

Am I correct in assuming you are using the router/modem as a wifi hotspot and connecting the iPod Touch to it?

And from this connection the Touch can determine its location?

There are ways that location can be determined by using the cell tower ID and this appears to be one of them. The Touch gets the ID of the cell tower that the router/modem is connected to and sends it off to a database that returns the tower location.

Exactly why the OpenWRT firmware would block the Touch from getting the tower ID is unknown to me, as this is a first for us. I'll try to see what I can find out about this and report back.

I've never heard of Turbo 3G+ before so what it actually is is anyone's guess.

Huawei modems return a number rather than a name for the Network Type so one of their modems would tell exactly what this actually is.

Other than that only a good speed test can tell if it is HSPA+ (21Mbs) or DC-HSPA+ (42Mbs).

This is confirmed by my findings as well. The Touch can only get location from an already recorded wifi location.

Did you try the factory TP-Link in different locations to see if it gave the proper location? Or was it only at one location?

It is possible that the Touch is getting its location from a different wifi in the area, not one you are connected to but one the Touch can see. It doesn't need to connect to a wifi in order to use it for location and it will use multiple wifis if they are available to triangulate your position.

I honestly can't see how the factory TP-Link could know its location to give to the database. It has no GPS and it could only find the tower ID from the modem, something I doubt it does. Something else is at work here.

I'm just getting into programming the buttons now. I've enabled the reset button so it deletes the password so you can get access if you have forgotten the password.

When you switch between the Lan and the modem (WAN) does the modem disconnect?

This is all new to me as I am not a router expert, more of a modem interface man.

It is easy to program a button to run a script and do quite a few things, as long as I have a clear understanding of what I'm doing.

If you could give me a detailed description of what you are doing and what is supposed to happen I may be able to make something work.

This should be possible using a script attached to a button.

I'll look and see what is out there.

My system is very similar as I have Internet coming into the router from another router and the USB modem as well. This makes it possible for me to test this before release.

Since we don't have a firmware for the MR3420V2 yet you can't use ModemGUI. It doesn't work with the stock TP-Link firmware, only our special OpenWRT version.

We will have a V2 firmware out in, at most, a couple of days since the patch finally came through. And the E392u-12 will be supported using QMI all full speed.

The connection delay is deliberate in our firmware. When using a protocol other than PPP it needs a fair amount of time for everything to get setup and running. It normally takes 1.5 to 2 minutes for the modem to connect.

Using PPP is slightly faster and other versions of OpenWRT don't have our scripts in them so they bang ahead with the connection. This can cause big problems in many situations and is one of the reasons we developed our version.

This modem uses a completely different driver than anything that we support. It is a "HSO" device and needs an HSO driver (which is available for OpenWRT) and a new method of connecting.

Without a similar device to test with, it is almost impossible to create the scripts needed to make this work.

Sorry about that.

That router is currently unsupported by OpenWRT so we can't make firmware for it.

I can be done but I haven't added all the pieces for this at this time.

It seemed a low priority item since no one had ever mentioned it before.

This can be a feature in the next version, which will be called Huntsman.

BlackWidow is now feature locked and will be the stable release from this time on.

I will add the DDNS package to Huntsman as long as it does turn out to be a memory hog. Doesn't look like it should be but you never know.