41

No joy here with any of the two settings after /etc/init.d/network restart :frowning:

Jan-Willem. Are you able to call the modem?

42

Well I have given up on trying to talk to the ttyUSB* ports directly. It also shouldnt be necessary.

So instead I went for the web panel and made sure the settings are set as Alfie has suggested.

I get a lot further now and the chatscript makes a connection with my carrier/provider. Then the PPP handshake process starts and I have lots of problems there.

First CHAP authentication didn’t work, but I think I have that sort of under control now.

Now I get IPCP timeouts in the PPP handshake phase that is trying to get the ip address and other config data for the connection.

I have done tons of googling but nothing is working yet.

I will post more details and logs at a later stage, I am going to have to take a break from it for a little bit as duty calls.

You might want to study the output of logread very very closely as that holds a lot of info on what is going on.

You can get more detailed info on what PPPD is doing by uncommenting the #debug line in /etc/pppd/options (i.e. remove the hash in front of the “debug” option)

I get the feeling I am almost there but cannot get the last PPP handshake with my provider going.

That’s why I mentioned before I seem to recall I had it working for a bit last week taking the QMI interface approach which is a totally different path.

I remember giving up on PPP before as it was giving me the same hard time. I have a strong feeling it has to do with our local telecom providers. I get the feeling you are in The Netherlands too and for some reason European providers are a pain.

So to get you going a little. QMI is a Quallcomm specific interface (a bit like CDC I think) where talking to the modem is abstracted a bit more and you get a driver that acts like an ethernet interface, which is way less fiddly.

As mentioned before, there is some info on that on this page https://wiki.openwrt.org/doc/recipes/ltedongle but despite the fact that I got it going somewhere last week it felt a bit buggy and unstable to me if I recall correctly.

I will be getting back to it in the coming days.

EDIT: I now remember why I upgraded to Chaos Calmer. I needed it to get QMI going, so it might not be so easy to move to that strategy with the current firmware. So it’s a choice. Stay with the PPP approach and chatscripts or move to QMI. I am going to try to get PPP going again as soon as I have more time, if that doesn’t work for me I think I might have to start compiling…

 

 

43
I remember giving up on PPP before as it was giving me the same hard time. I have a strong feeling it has to do with our local telecom providers.
True, but does this also count for simple 3G ?
I get the feeling you are in The Netherlands too and for some reason European providers are a pain.
Yes.. I'm Dutch like you!

Who is your provider? I’m using Choozze (www.choozze.nu). They make use of the 3G T-Mobile network.

44
  1. Yeah it holds true for 3G as well. I read that you had several 3G dongles hooked up to AR-150’s with no problem whatsoever. My experiences haven’t been so lucky with getting 3G dongles to work. Nothing bad about the AR-150 by the way, I was actually doing that on MR-3020’s but it seems unrelated to the host platform and more to what type of 3G dongle hardware is being used. You have to get lucky I guess.

But yeah “simple 3G” doesn’t exist in my book :slight_smile: 3G is just the data connection and it is tough enough already to get that going in some cases, and then you still need your transport layer set up which is where PPP comes in.

  1. I’m trying to get my KPN sim working at the moment. But I have one from Ziggo too…
45

Maybe @alzhao can shed some light on our troublesome PPP paths. Judging from the configuration information he sent it must be working in his setup.

Also, there are configuration pages in the webpanel and if all is well and filled out correctly it should theoretically work.

Alfie, could you post an output of logread with the output of what happens when the ppp connection is established. Chatscript and pppd output etc?

I will post my log when I have a moment, I am stuck at errors in the last part where PPP is negotiating the ip address in the IPCP phase and I cannot get it to work. 2 days of googling hasn’t helped yet either as I cannot find that many people with the same problem. Which usually means the cause lies somewhere else. In many cases as simple as specifying the wrong APN or incorrect username and password. (Yes most providers need blank username and pass but I have seen cases where you have to specify the *blank" password. I.e. leaving out the parameters doesn’t work but specifying username “” password “” in empty quotes did work. It get’s this crazy…)

@Guest Did you get a chance to look at your logread when you have everything specified correctly in your webpanel (APN, correct ttyUSB2/3 etc.) I would be curious to see your log to see where it fails compared to mine. Please post one if you can.

PS: We could take this discussion elsewhere if anybody feels we are spamming the forum. But I think it might be helpful to others to see what we are trying to get going here.

46

Jan-Willem,

Here is my logread when /dev/ttyUSB3 was used.
All settings used in /etc/config/network are the same (except ttyUSB3) as used in my working AR-150 with a Huawei mobile broadband E1750 stick.

47

Thanks for the log.

Mmm, your connection process is already failing at the dial chatscript. Even before we get to the PPP handshake phase.

the AT+CGDCONT=1,“IP”,“<apn>” command is supposed to register the APN with the modem. The next command after this is the ATDT or actual dial command but it is never reached in your case as CGDCONT gives an error.

I remember having this too at one stage last week but managed to overcome it. I don’t remember exactly how anymore but it either had to do with talking to the wrong ttyUSB* port for the AT interface OR it was the fact that in desperation I actually entered some nonsense into the username and password fields.

I have a feeling we might be a while before we get this working. I have to drop it a bit for now but we will be back at it soon surely…

48

Could be my SIM slot.
I can access my other modem (the Huawei) without a SIM in it.
Makes things easer to test.

@alzhao. How about me giving you root access to the GL-MiFi and having a look at it?

49

Well for what it’s worth. When I inserted my sim card I could still not access the ttyUSB* devs with either screen or minicom but I have a feeling that might have a different cause that is not related. So I don’t think your sim slot is the problem.

The driver is clearly talking to your /dev/ttyUSB3 as the AT commands reach the modem just fine as you can see from your logread.

As mentioned before. The only way I got it working was installing Chaos Calmer and go with the QMI approach. I actually established a working connection that way but I have since after our experiments flashed that whole arrangement to kingdom come of course. :wink:

Before I start explaining what I did to make it work with the QMI driver, I think it is best maybe Alfie can tell us how it is working with this firmware in his setup and we can compare connection logs to see where things are going haywire in our setups.

 

50

Good thinking. Lets wait for Alfie.

51

@jw and @guest,

I am not an expert on this. Our engineers are preparing a set of AT command for you to debug. He is in China so I am not sure if he can access your SSH, just because the Internet speed maybe very low.

52

Thank you!

I know it is hard to cater to every configuration, especially with LTE involved and 3rd party boards and openwrt patches.

You guys are building awesome stuff, much appreciated, keep it up!

 

 

53

Thank you.

54

Jan-Willem,

What model of UC20 are you using?
The one I have is a UC20EB.

55

Yes Quectel UC20EB 3G.

We have the very same. That’s nice for testing :slight_smile:

 

56

should you not hide the IMEI?

57

Yeah you’re right. My bad. Anyway too late now I cannot remove the image anymore.

It’s a board for testing purposes anyway so I don’t worry too much. Full IMEIs are listeed on the ones on the sales page as well…

58

Hi @jw and @guest,

Here we have an instruction but in Chinese. We are translating to English. But you can check it first, as most content are easy understandable.

http://www.gl-inet.com/download/mifi/MiFi%20dev%20manual%20chinese.doc

59

Hi @Guest

From your sentence,I’m sure your mifi’s OS have recognized the UC20 module.I will give some AT command to make sure that UC20 and SIM-card is connect to mifi.

First,you should set right service,apn,username,password at /etc/config/network.You can get them from telecom operators.

Second,log in mifi’OS with UART or telnet or ssh.

Third,sent AT command to UC20

You can use echo -e “AT+xxx \r\n” > /dev/ttyUSB2 command to send AT command to UC20 module,and you can use cat /dev/ttyUSB2 to see result.

 

For example，

1.Request International Mobile Equipment Identity

Execution command：echo -e “AT+GSN \r\n” > /dev/ttyUSB2

Look for response：cat /dev/ttyUSB2

Correct result：

AT+GSN

861075021617089

OK

Incorrect result：

AT+GSN

ERROR

If you get the a similar number,it means that the UC20’s connection is OK.

  1. Show SIM‘S ICCID

Execution command：echo -e “AT+QCCID \r\n” > /dev/ttyUSB2

Look for response：cat /dev/ttyUSB2

Correct result：

AT+QCCID

+QCCID: 89860115851079757018

OK

Incorrect result：

AT+CCIDI

ERROR

If you get the a similar number,it means that the connection of SIM-card is OK.

3.Check Network Registration

Execution command：echo -e “AT+ CREG? \r\n” > /dev/ttyUSB2

Look for response：cat /dev/ttyUSB2

Correct result：

AT+CREG?

+CREG: 0,1

OK

Incorrect result：

AT+CREG?

ERROR

If you get the a similar <span style=“line-height: 1.5;”>result</span><span style=“line-height: 1.5;”>,it means that your SIM-card have registered to telecom operators.</span>

4.Signal Quality Report

<span style=“line-height: 1.5;”> Execution command</span>：echo -e “AT+CSQ \r\n” > /dev/ttyUSB2

<span style=“line-height: 1.5;”> Look for response</span>：cat /dev/ttyUSB2

Correct result：

+CSQ: 21,99

OK

Incorrect result：

AT+CSQ

ERROR

This first number is our want to get.I sorry to how <span style=“line-height: 1.5;”>value</span><span style=“line-height: 1.5;”> is OK,but I know the absolute value is </span>the more little the more better.I usual get value is 18~23.

Others AT command,please refer to Quectel_UC20_AT_Commands_Manual_V1.5.pdf. I think you can usr other <span style=“line-height: 1.5;”>AT command</span><span style=“line-height: 1.5;”> correct.</span>

 

60

Hi @Guest

From your sentence,I’m sure your mifi’s OS have recognized the UC20 module.I will give some AT command to make sure that UC20 and SIM-card is connect to mifi.

First,you should set right service,apn,username,password at /etc/config/network.You can get them from telecom operators.

Second,log in mifi’OS with UART or telnet or ssh.

Third,sent AT command to UC20

You can use echo -e “AT+xxx \r\n” > /dev/ttyUSB2 command to send AT command to UC20 module,and you can use cat /dev/ttyUSB2 to see result.

For example，

1.Request International Mobile Equipment Identity

Execution command:echo -e “AT+GSN \r\n” > /dev/ttyUSB2

Look for response:cat /dev/ttyUSB2

Correct result：

AT+GSN

861075021617089

OK

Incorrect result:

AT+GSN

ERROR

If you get the a similar number,it means that the UC20’s connection is OK.

 

  1. Show SIM‘S ICCID

Execution command:echo -e “AT+QCCID \r\n” > /dev/ttyUSB2

Look for response:cat /dev/ttyUSB2

Correct result:

AT+QCCID

+QCCID: 89860115851079757018

OK

Incorrect result:

AT+CCIDI

ERROR

If you get the a similar number,it means that the connection of SIM-card is OK.

 

3.Check Network Registration

Execution command：echo -e “AT+ CREG? \r\n” > /dev/ttyUSB2

Look for response：cat /dev/ttyUSB2

Correct result:

AT+CREG?

+CREG: 0,1

OK

Incorrect result:

AT+CREG?

ERROR

If you get the a similar result,it means that your SIM-card have registered to telecom operators.

 

4.Signal Quality Report

Execution command:echo -e “AT+CSQ \r\n” > /dev/ttyUSB2

Look for response:cat /dev/ttyUSB2

Correct result:

+CSQ: 21,99

OK

Incorrect result:

AT+CSQ

ERROR

This first number is our want to get.I sorry to how value is OK,but I know the absolute value is the more little the more better.I usual get value is 18~23.

Others AT command,please refer to Quectel_UC20_AT_Commands_Manual_V1.5.pdf. I think you can usr other AT command correct.