[Fork] 374.43 LTS Beta including new rev AC68U routers (V27BI)

[jrmwvu04]

Flashed the refresh a couple hours ago, no issues.

It might be in my head but many network functions seem smoother with the improvement in CPU of the 1900P over the AC68 units I used before.

I don't think it's sensational to say that your work on this fork, John (along with of course Eric and probably others), makes the 1900P the best consumer grade router you can buy.

 

[Uncle_Gadget]

I don't think it's sensational to say that your work on this fork, John (along with of course Eric and probably others), makes the 1900P the best consumer grade router you can buy.

If you don't mind the extra work involved with replacing the bootloader, etc., the T-Mobile AC-1900 is 100% the same hardware as the AC-68U and with a little time and effort can be converted to a 100% working AC-68U. You should also be able to buy them for around $70. I've bought and converted almost a dozen for friends and family. I also bought most of them for $59.95 on promotion.



Sent from my Nexus 7 using Tapatalk

 

[jrmwvu04]

So a wrinkle I've been wrestling with - when I cut the power to the router and it boots from cold, pixelserv doesn't start properly, and it's reproducible. Issuing a reboot from the terminal and warm booting, it comes up normally. There's a line in the syslog when it fails:

Dec 31 19:00:33 pixelserv[694]: Abort: Cannot assign requested address - :10.1.1.5:80

There are a number of differences in the syslogs between a cold boot and warm, and I'm not sure if there's a setup problem on my end or it's something else.

I am using a setup quite similar to the one @kvic suggests in the wiki, on a virtual interface set to 10.1.1.5 on a handful of ports.

 

[thelonelycoder]

So a wrinkle I've been wrestling with - when I cut the power to the router and it boots from cold, pixelserv doesn't start properly, and it's reproducible. Issuing a reboot from the terminal and warm booting, it comes up normally. There's a line in the syslog when it fails:

Dec 31 19:00:33 pixelserv[694]: Abort: Cannot assign requested address - :10.1.1.5:80

There are a number of differences in the syslogs between a cold boot and warm, and I'm not sure if there's a setup problem on my end or it's something else.

I am using a setup quite similar to the one @kvic suggests in the wiki, on a virtual interface set to 10.1.1.5 on a handful of ports.

Cold boot (pixelserv fails): https://www.dropbox.com/s/nyptcy8nm3r4loo/syslog-coldboot.log

Warm boot (normal): https://www.dropbox.com/s/38fdgevgz7zv1eu/syslog-reboot.log

You're not using AB-Solution where I prevent pixelserv-tls from starting before the virtual IP is up.

This is what AB-Solution adds before the pixelserv parameters in /opt/etc/init.d/S80pixelserv-tls:

# Delay starting pixelserv-tls if virtual IP is not up, set by wan-start user script.
# This might be the case if WAN is slow to restore during bootup.
# Timeout of 15 secs ensures ps will try to start anyway.

TIMEOUT=15
while [ $TIMEOUT -ne 0 ];do
   ping -c 1 -W 1 <YOUR PIXELSERV IP> >/dev/null

   if [ $? -eq 0 ];then
       TIMEOUT=0
   else
       TIMEOUT=$(($TIMEOUT - 1))
       logger "pixelserv-tls (AB-Solution) virtual IP not up, waiting 1 second until timeout in $TIMEOUT seconds"
       sleep 1
   fi
done

It would also make sense to move the adblock.lst to the USB device as this is mounted before the list is copied frome wherever to the /tmp/ location:
failed to load names from /tmp/adblock.lst: No such file or directory

 

[john9527]

So a wrinkle I've been wrestling with - when I cut the power to the router and it boots from cold, pixelserv doesn't start properly, and it's reproducible.

That is indeed interesting....and goes along with @thelonelycoder 's comment above. The only difference that jumps out is that it is taking about 4 sec longer for the WAN to fully come up during a cold boot (not entirely surprising as there may be some additional time spent negotiating with the modem on a cold start).

One easy way to check would just be to insert a sleep before the pixelserv start (but the code snip above is better as it's event driven).

 

[thelonelycoder]

That is indeed interesting....and goes along with @thelonelycoder 's comment above. The only difference that jumps out is that it is taking about 4 sec longer for the WAN to fully come up during a cold boot (not entirely surprising as there may be some additional time spent negotiating with the modem on a cold start).

One easy way to check would just be to insert a sleep before the pixelserv start (but the code snip above is better as it's event driven).

Users reported this lately so I added the delay to the file.
No more problems since.

 

[thelonelycoder]

BTW, are you going to run two separate LTS forks or is the code for your beta compatible with all the models you support with the original fork?
Your wording in the beta post leaves that kind of unanswered.

 

[john9527]

BTW, are you going to run two separate LTS forks or is the code for your beta compatible with all the models you support with the original fork?
Your wording in the beta post leaves that kind of unanswered.

Sorry if it wasn't clear. My intent is to converge to a single LTS fork with the final release V27. The current V27beta folder contains builds for all the supported models out of my SDK branch as a double check.

 

[jrmwvu04]

This is what AB-Solution adds before the pixelserv parameters in /opt/etc/init.d/S80pixelserv-tls:

One easy way to check would just be to insert a sleep before the pixelserv start (but the code snip above is better as it's event driven).

Thanks for the insight, I'll tinker with that and see what happens.

It would also make sense to move the adblock.lst to the USB device as this is mounted before the list is copied frome wherever to the /tmp/ location:

That's intentional so that the rules don't survive reboot, but I appreciate the heads up.

That is indeed interesting....and goes along with @thelonelycoder 's comment above. The only difference that jumps out is that it is taking about 4 sec longer for the WAN to fully come up during a cold boot (not entirely surprising as there may be some additional time spent negotiating with the modem on a cold start).

That's more or less what I wanted to know. I will cook up something to get around it, it's no big deal. It's quite rare that the router is cold booting. Just something I didn't run into before on the AC68 to my recollection.

 

[jrmwvu04]

Well, to wrap up the prior issue of pixelserv not starting, a simple
"/opt/etc/init.d/S80pixelserv-tls restart" tucked at the end of wan-start takes care of it. It is probably related to my modem which Comcast hasn't added to my account (but that's a whole other story).

While I have everyone's attention..

Dec 31 19:00:28 WAN_Connection: ISP's DHCP did not function properly.

I don't think I've ever not seen this, it seems like it's always there. Meaningful? Worrisome?

 

[john9527]

I don't think I've ever not seen this, it seems like it's always there. Meaningful? Worrisome?

Always been there.....pretty much a generic message that says it couldn't talk to the WAN yet. No worries unless it happens after boot and the WAN has already come up.

 

[WRobertE]

Just loaded 3.0.0.4.374.43_27BIj9527 onto my RT-N66U and I see these messages in the system log after the load:

Dec 31 19:00:08 syslog: module cdc_wdm not found in modules.dep
Dec 31 19:00:08 syslog: module qmi_wwan not found in modules.dep
Dec 31 19:00:08 syslog: module cdc_mbim not found in modules.dep

Maybe it's entirely normal ... don't know. Just wanted to mention it.

 

[john9527]

Just loaded 3.0.0.4.374.43_27BIj9527 onto my RT-N66U and I see these messages in the system log after the load:

Dec 31 19:00:08 syslog: module cdc_wdm not found in modules.dep
Dec 31 19:00:08 syslog: module qmi_wwan not found in modules.dep
Dec 31 19:00:08 syslog: module cdc_mbim not found in modules.dep

Maybe it's entirely normal ... don't know. Just wanted to mention it.

Expected (and I think always there)....those are some drivers for additional USB Modems that were added on the ARM based routers.

Thanks for taking the time to load on your N66 and checking things.

 

[Builder71]

Just loaded 3.0.0.4.374.43_27BIj9527 onto my RT-N66U and I see these messages in the system log after the load:

Dec 31 19:00:08 syslog: module cdc_wdm not found in modules.dep
Dec 31 19:00:08 syslog: module qmi_wwan not found in modules.dep
Dec 31 19:00:08 syslog: module cdc_mbim not found in modules.dep

Maybe it's entirely normal ... don't know. Just wanted to mention it.

On 26E4 they are also there on my RT-N66U.

 

[john9527]

On 26E4 they are also there on my RT-N66U.

Thanks for confirming it's nothing new on the beta. Appreciate it.

 

[WRobertE]

This is completely subjective but wireless seems a bit more responsive.
I greatly appreciate your ongoing work with this fork.

 

[fink.nottle]

Does this affect the wireless on older (regular) AC68U ? This makes the wifi performance worse for my client (Intel 6300N on linux). This is a terrible wifi card with all sorts of performance problems, but the fork manages to make it hit 100 Mbps on linux, whereas the main merlin version doesn't. With this beta, it performs similar to the main merlin version I think. Is this going to become the default going forward ?

Edit: By worse, I mean like half. I can't even cross 50 Mbps with this version.

 

[ColinTaylor]

Edit: By worse, I mean like half. I can't even cross 50 Mbps with this version.

Did you do the mandatory factory reset and manual reconfigure after loading the firmware?

I monitored the router's signal strength on 2.4GHz and 5GHZ before and after loading this firmware on my RT-AC68U and couldn't detect any difference. Throughput was as expected on Windows 8.1.

 

[fink.nottle]

Did you do the mandatory factory reset and manual reconfigure after loading the firmware?

I monitored the router's signal strength on 2.4GHz and 5GHZ before and after loading this firmware on my RT-AC68U and couldn't detect any difference. Throughput was as expected on Windows 8.1.

I'm pretty sure that range will be fine, and even windows will perform alright. Android did in my case. The issue is more about the client's peculiarities on linux. I didn't try the firmware reset, but I can try it. If anyone has a sandybride/ivybridge era thinkpad, you could confirm my observations on linux. They all used the same family of intel cards. Note that I need to enable AMPDU aggregation explicitly for this card with options iwlwifi 11n_disable=8 to get any sort of performance. Without this also, I can't cross 50 Mbps. Just mentioning it in case the newer firmware (either this, or main merlin) affect this setting in any way.

 

[john9527]

Does this affect the wireless on older (regular) AC68U ? This makes the wifi performance worse for my client (Intel 6300N on linux). This is a terrible wifi card with all sorts of performance problems, but the fork manages to make it hit 100 Mbps on linux, whereas the main merlin version doesn't. With this beta, it performs similar to the main merlin version I think. Is this going to become the default going forward ?

Edit: By worse, I mean like half. I can't even cross 50 Mbps with this version.

Yes, the plan is that there will be one AC68U version going forward that supports all versions and with a newer wireless driver (the wireless driver is tied to the SDK). And unfortunately, this is going to require a factory default reset.

But, there is one thing you may want to check. Most linux distros ship with a very outdated regulation db that can kill throughput. I had problems with my Intel 7260AC card on Mint, and others had problems with various Centrino N cards. See this thread...
https://www.snbforums.com/threads/rt-ac66w-slow-linuxmint-ubuntu-wireless-n-connection-solved.32760/