MR600 V1 Firmware inadequacies.

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

MR600 V1 Firmware inadequacies.

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
MR600 V1 Firmware inadequacies.
MR600 V1 Firmware inadequacies.
2021-02-14 14:53:37 - last edited 2021-02-14 14:54:48
Model: Archer MR600  
Hardware Version: V1
Firmware Version:

I've been setting up customers with LTE systems as an alternative to ADSL for a few years here in France with great success. For the first couple of years I was using the B525 from Huawei with great results, but when Free started using 700MHZ, the B525 was unable to tap into this so I had to look for an alternative. 

I came across the MR600 v1 and was initially very impressed, but I'm now in the position of having recommended the MR600 to about 30customers and I'm starting to bitterly regret it. 

For the last few months, I have been receiving phone calls about drop outs in connection on the Free network in France Drop outs are usually about once or twice a day across the board and are only resolved by a reboot. I've had more success with your beta firmware which allows me to force band 28 selction, that you've been sitting on for many months without advancing, but the cutouts still happen. This happens on a variety of masts in a variety of situations.

Why is the firmware so poor that it is unable to reestablish a connection on its own without a reboot? When are you going to introduce the band selection features properly into a stable release? You have not released a new stable release in over seven months in spite of shortcomings. You have my email address so if you're interested in me helping you get the specifics of the issues then get in touch. 

Please do something about it ASAP.
 

  4      
  4      
#1
Options
4 Reply
Re:MR600 V1 Firmware inadequacies.
2021-03-12 00:13:01

@Denarius Further to this, someone else on the forum kindly pointed me to some information on a 4G router forum in France indicating that free wants to change the WAN IP address every 12 hours and this is causing the connection to break and not reconnect, presumably because the DHCPC is stuck on simply renewing the lease rather than refreshing the IP? I also note that there has been commentary about similar problems on other networks on this since about October 2020 with no action yet taken. 

Aside from this, I noted that the V2 version of the MR600 does have band selection in its stable firmware. Why is this still not incorporated into the latest stable release of V1 firmware in spite of the fact that every recent order of MR600s from Amazon I've been associated with has been of the V1 and I've yet to see a V2?! Surely you must agree that a 4G router that is unable to maintain a connection without two reboots a day is a product that needs some attention from the manufacturers, particularly when that product is still on sale on the new market?!

  0  
  0  
#2
Options
Re:MR600 V1 Firmware inadequacies.
2021-03-15 03:07:29

@Denarius 

Hi, thank you very much for your feedback.

Have you tried to change the DNS server on the Archer MR600 to have a look: Advanced>Network>LAN settings>primary DHCP server/secondary DHCP server;

 

If still the same, could you please help me do the following test:

1.When the internet disconnected again, please log into the web interface:

Advanced>network>internet> turn off and on the mobile data and click the save button and check whether the internet connection could be recovered;

 

Thanks a lot and wait for your reply.

 

 

  1  
  1  
#3
Options
Re:MR600 V1 Firmware inadequacies.
2021-03-21 20:44:32

@TP-Link 

 

Hi there. Thanks for the reply. 

 

I've done the following tests as requested. 
 

Test: Added DNS servers into the router of 8.8.8.8 and 8.8.4.4.

Result: No change in behaviour (disconnecting minimum of twice a day.)

 

Test: Turn off and on mobile data and click save.

Result: Connection isn't reestablished. 

Can't attach log so I've copy and pasted some of it from dijust before the first logged timeout. This includes the disabling and reenabling of mobile data. 

 

2021-03-21 18:37:41 [7] DHCPC: Send REQUEST to server 10.158.139.14 with request ip 10.158.139.13
2021-03-21 18:37:41 [7] DHCPC: Recv ACK from server 10.158.139.14 with ip 10.158.139.13 lease time 7200
2021-03-21 18:38:34 [6] System: Device(28:B2:BD:56:2D:68) joins in 5G Wlan
2021-03-21 18:38:34 [5] DHCPD: Recv DISCOVER from 28:B2:BD:56:2D:68
2021-03-21 18:38:34 [5] DHCPD: Send OFFER with ip 192.168.1.110
2021-03-21 18:38:35 [5] DHCPD: Recv REQUEST from 28:B2:BD:56:2D:68
2021-03-21 18:38:35 [5] DHCPD: Send ACK to 192.168.1.110
2021-03-21 18:38:53 [6] System: Device(28:B2:BD:56:2D:68) leaves 5G Wlan
2021-03-21 18:38:56 [6] System: Device(28:B2:BD:56:2D:68) joins in 2.4G Wlan
2021-03-21 18:38:56 [5] DHCPD: Recv REQUEST from 28:B2:BD:56:2D:68
2021-03-21 18:38:56 [5] DHCPD: Send ACK to 192.168.1.110
2021-03-21 18:39:29 [5] DHCPD: Recv REQUEST from C8:2A:14:42:4B:A2
2021-03-21 18:39:29 [5] DHCPD: Send ACK to 192.168.1.106
2021-03-21 18:40:00 [6] System: Device(28:B2:BD:56:2D:68) leaves 2.4G Wlan
2021-03-21 18:40:01 [5] DHCPD: Recv DISCOVER from 28:D2:44:F0:A0:ED
2021-03-21 18:40:01 [5] DHCPD: Send OFFER with ip 192.168.1.112
2021-03-21 18:40:01 [5] DHCPD: Recv REQUEST from 28:D2:44:F0:A0:ED
2021-03-21 18:40:02 [5] DHCPD: Send ACK to 192.168.1.112
2021-03-21 18:40:46 [6] System: User(28:D2:44:F0:A0:ED) logs in.
2021-03-21 18:40:56 [5] DHCPD: Recv REQUEST from 28:D2:44:F0:A0:ED
2021-03-21 18:40:56 [5] DHCPD: Send ACK to 192.168.1.112
2021-03-21 18:41:12 [6] Httpd: DNS 212.27.40.241 resolve timeout for dns.msftncsi.com
2021-03-21 18:41:14 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
2021-03-21 18:41:27 [6] Httpd: DNS 212.27.40.241 resolve timeout for dns.msftncsi.com
2021-03-21 18:41:29 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
2021-03-21 18:41:31 [6] 4G: USER: Start disconnecting from the network!

2021-03-21 18:41:31 [5] 4G: dataSwitch: 0
2021-03-21 18:41:32 [6] Httpd: DNS 212.27.40.241 resolve timeout for dns.msftncsi.com
2021-03-21 18:41:32 [6] 4G: USER: Disconnected from the network!

2021-03-21 18:41:33 [5] 4G: lte internet disconnected.
2021-03-21 18:41:33 [6] 4G: LTE connection down
2021-03-21 18:41:34 [5] 4G: Send a RS on wwan0
2021-03-21 18:41:34 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
2021-03-21 18:42:03 [5] DHCPD: Recv REQUEST from 28:D2:44:F0:A0:ED
2021-03-21 18:42:03 [5] DHCPD: Send ACK to 192.168.1.112
2021-03-21 18:42:29 [5] DHCPD: Recv REQUEST from 28:D2:44:F0:A0:ED
2021-03-21 18:42:29 [5] DHCPD: Send ACK to 192.168.1.112
2021-03-21 18:44:36 [6] 4G: USER: Get user's profile now.

2021-03-21 18:44:36 [6] 4G: USER: GetCurrProf result is:  ipver:2  staticApn:0  authType:0  pkgName:free_mobile  profname:free_mobile  apn:free  usr:  psw:  

2021-03-21 18:44:36 [6] 4G: USER: Start connecting to the network!

2021-03-21 18:44:36 [6] 4G: ERROR: Bind mux port session 0 failed (0).

2021-03-21 18:44:36 [6] 4G: ERROR: Bind mux port session 1 failed (0).

2021-03-21 18:44:36 [5] 4G: dataSwitch: 1
2021-03-21 18:44:38 [6] 4G: USER: Connected to the network!

2021-03-21 18:44:38 [6] 4G: ERROR: 0x0000004A QMI_ERR_INFO_UNAVAILABLE

2021-03-21 18:44:38 [6] 4G: ERROR: result=1, error=74

2021-03-21 18:44:38 [6] 4G: ERROR: QMI NAS Get PHY CA Info failed, ret = 0.

2021-03-21 18:44:38 [6] 4G: ERROR: 0x0000000E QMI_ERR_CALL_FAILED

2021-03-21 18:44:38 [6] 4G: ERROR: Call end reason = 1.

2021-03-21 18:44:38 [6] 4G: ERROR: Verbose Call end reason = 210, type = 2.

2021-03-21 18:44:41 [6] 4G: USER: Get user's profile now.

2021-03-21 18:44:41 [6] 4G: USER: GetCurrProf result is:  ipver:2  staticApn:0  authType:0  pkgName:free_mobile  profname:free_mobile  apn:free  usr:  psw:  

2021-03-21 18:44:41 [5] 4G: set LTE static IP connection, needSetDefaultGw:1
2021-03-21 18:44:42 [6] 4G: LTE connection up
2021-03-21 18:44:42 [5] 4G: LTE internet connected.
2021-03-21 18:44:42 [5] 4G: Send a RS on wwan0
2021-03-21 18:44:46 [6] Httpd: DNS 212.27.40.240 resolve timeout for dns.msftncsi.com
2021-03-21 18:44:48 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
2021-03-21 18:44:51 [6] Httpd: DNS 212.27.40.240 resolve timeout for dns.msftncsi.com
2021-03-21 18:44:53 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
2021-03-21 18:44:56 [6] Httpd: DNS 212.27.40.241 resolve timeout for dns.msftncsi.com
2021-03-21 18:44:58 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
2021-03-21 18:45:02 [6] Httpd: DNS 212.27.40.241 resolve timeout for dns.msftncsi.com
2021-03-21 18:45:04 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
2021-03-21 18:45:19 [6] Httpd: DNS 212.27.40.241 resolve timeout for dns.msftncsi.com
2021-03-21 18:45:21 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
2021-03-21 18:45:24 [6] Httpd: DNS 212.27.40.241 resolve timeout for dns.msftncsi.com
2021-03-21 18:45:26 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
2021-03-21 18:45:30 [6] Httpd: DNS 212.27.40.241 resolve timeout for dns.msftncsi.com
2021-03-21 18:45:32 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
2021-03-21 18:45:35 [6] Httpd: DNS 212.27.40.241 resolve timeout for dns.msftncsi.com
2021-03-21 18:45:37 [6] Httpd: DNS 8.8.8.8 resolve timeout for dns.msftncsi.com
 

 

 

  0  
  0  
#4
Options
Re:MR600 V1 Firmware inadequacies.
2021-03-23 09:43:23

@Denarius 

Thank you very much and I would like to follow up on your case by email.

Please have a check of your email box later.

 

  1  
  1  
#5
Options

Information

Helpful: 4

Views: 1200

Replies: 4

Related Articles