[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[john9527]

Hello could you please give me an idea of the wifi signal over 2,4 between this built and Merlin 378 v 2? I like the latter and love it but I live in a very saturated 2,4 ghz area and I don't get the signal I would like in some spots of the house ..

Unfortunately, there is no magic for dealing with an area where the 2.4GHz band is 'full'. Best advice I can give is to try is to stick to channels 1,6 or 11 with a channel width of 20MHz. The older wireless drivers in the fork may behave a bit 'different' on the AC68, but I wouldn't expect a lot of help in dealing with an overcrowded band.

 

[john9527]

Can u not install fork on Rt-ac66u when MacBook is only connectet via wifi ?


Sent from my iPhone using Tapatalk

I personally don't have any experience with a MacBook, but I would expect that you could perform the update via wifi and your browser. While it's recommended to to use a wired connection, I think the update is actually done in two steps....first transfer....then apply the new firmware. (Maybe @RMerlin can confirm). So if that's the only way you have, it still should be relatively safe.

 

[john9527]

I am running standard netmask and it worked fine before with same settings. Interestingly the Asus EA-N66R AP has a client list (off by default) that can be turned on and it works correctly.

I'm running out of ideas on this one.....last two thoughts....
- If you are using a 10.x.x.x local subnet, I remember there have been some problems reported. Try with a 192.168.x.x/24 network.
- There may be a corrupt value in the nvram for one of the device names. If you do a 'view source' on the networkmap page (index.asp with the right side showing the Client Status list), there should be a line near the top of the source output
var client_list_array = .......
which contains the client names, ip addresses, macs and a couple of other status bytes. Does it look reasonable or corrupted?

 

[crusher888]

Unfortunately, there is no magic for dealing with an area where the 2.4GHz band is 'full'. Best advice I can give is to try is to stick to channels 1,6 or 11 with a channel width of 20MHz. The older wireless drivers in the fork may behave a bit 'different' on the AC68, but I wouldn't expect a lot of help in dealing with an overcrowded band.

hello john thanks for your answer, why would you stick to 20mhz? better signal? wound't i get a lower speed? i still have to understand what's better between 20, 20/40 or 40...
thanks so much

 

[Nullity]

hello john thanks for your answer, why would you stick to 20mhz? better signal? wound't i get a lower speed? i still have to understand what's better between 20, 20/40 or 40...
thanks so much

40Mhz takes up ~8 of the ~11 available 2.4Ghz channels. Greedy = bad.

 

[SuperFly74]

I personally don't have any experience with a MacBook, but I would expect that you could perform the update via wifi and your browser. While it's recommended to to use a wired connection, I think the update is actually done in two steps....first transfer....then apply the new firmware. (Maybe @RMerlin can confirm). So if that's the only way you have, it still should be relatively safe.

Transfer no problem, apply over wifi, no go, gotta be done with wired connection. ?


Sent from my iPhone using Tapatalk

 

[sbailey4]

hello john thanks for your answer, why would you stick to 20mhz? better signal? wound't i get a lower speed? i still have to understand what's better between 20, 20/40 or 40...
thanks so much

Here are a few areas of reference for you. This explains the "why's" that 40mhz could be bad especially in a crowded environment. If you live on a farm and no wifi networks anywhere then yes 40 mhz would be suitable.
Part 1
Part 2
Fix slow wifi (see fix#5 specifically for this topic but 1-4 for other recommendations)

 

[N66uASUS]

What version has SDK5 WiFi and a Bandwidth Limiter (not QOS)?

 

[ColinTaylor]

What version has SDK5 WiFi and a Bandwidth Limiter (not QOS)?

Duplicate post: http://www.snbforums.com/threads/n6...5-wifi-and-a-bandwidth-limiter-not-qos.29449/

 

[crusher888]

Here are a few areas of reference for you. This explains the "why's" that 40mhz could be bad especially in a crowded environment. If you live on a farm and no wifi networks anywhere then yes 40 mhz would be suitable.
Part 1
Part 2
Fix slow wifi (see fix#5 specifically for this topic but 1-4 for other recommendations)

thanks so much!

 

[J0N4TH4N]

Have you restarted the router a few times to assure that QoS is not being quirky?

Hi sorry, its not the router its the ISP's modem that received an new firmware update that isn't working correct.

 

[farfromuman]

I'm running out of ideas on this one.....last two thoughts....
- If you are using a 10.x.x.x local subnet, I remember there have been some problems reported. Try with a 192.168.x.x/24 network.
- There may be a corrupt value in the nvram for one of the device names. If you do a 'view source' on the networkmap page (index.asp with the right side showing the Client Status list), there should be a line near the top of the source output
var client_list_array = .......
which contains the client names, ip addresses, macs and a couple of other status bytes. Does it look reasonable or corrupted?

I am using 192.168.1.x , the source output has this listed:

var client_list_array = '';

I guess I will look up the IPs/MACs in the logs when I do need them, thanks for your help.

 

[john9527]

I am using 192.168.1.x , the source output has this listed:

var client_list_array = '';

I guess I will look up the IPs/MACs in the logs when I do need them, thanks for your help.

From your original post.....
I have about 35 clients and half are setup with IP reservations

I'd suspect at this point that at some point you may have named a client with a character that causes parsing problems. Last try would be to double check that your client names only contain alphanumerics, dash and underscore.

 

[krick]

The 432000 (7 days) was the old default. It was switched by ASUS and I picked up the change a while back. I thought I mentioned in the release notes to check it and manually reset it

My GUI says: "TCP Timeout: Established [________] Default: 432000 (5 days)"

Should the text be changed to show the new 2400 default?

(I'm still running 374.43_2-13E1j9527 on an RT-AC68U if it matters)

 

[john9527]

My GUI says: "TCP Timeout: Established [________] Default: 432000 (5 days)"

Should the text be changed to show the new 2400 default?

(I'm still running 374.43_2-13E1j9527 on an RT-AC68U if it matters)

Yes, it matters that change went in starting with V14 along with updating the default text.

 

[sbailey4]

Hey John I see in your sig BF version So several more changes since B5 I presume? B5 seems to be working great btw on AC66.

 

[john9527]

Hey John I see in your sig BF version So several more changes since B5 I presume? B5 seems to be working great btw on AC66.

Yep...a few more changes coming over 16B5

One thing driving some of the changes.....I contacted my ISP and got them to enable native IPv6 for me ahead of the general rollout for my area (had been running a HE tunnel). This led me to find a couple of 'interesting' quirks in the code. Basically the code assumed during boot that if IPv4 was up, IPv6 also had to be up. For a tunnel, this was a pretty good assumption...seems not to be as good for native. QoS in particular could have a tough time with this.

I'm probably going to push one more beta for a short run, then make a final release.

Oh....and I saw a deal I couldn't pass up on an AC68P....

Current results.....native IPv6, Q0S enabled, IPv4 running through a VPN with AES-126 encryption on a 50/5 service. (Samba sharing, NFS sharing and an OpenVPN server also enabled).

 

[sbailey4]

Yep...a few more changes coming over 16B5

One thing driving some of the changes.....I contacted my ISP and got them to enable native IPv6 for me ahead of the general rollout for my area (had been running a HE tunnel). This led me to find a couple of 'interesting' quirks in the code. Basically the code assumed during boot that if IPv4 was up, IPv6 also had to be up. For a tunnel, this was a pretty good assumption...seems not to be as good for native. QoS in particular could have a tough time with this.

I'm probably going to push one more beta for a short run, then make a final release.

Oh....and I saw a deal I couldn't pass up on an AC68P....

Current results.....native IPv6, Q0S enabled, IPv4 running through a VPN with AES-126 encryption on a 50/5 service. (Samba sharing, NFS sharing and an OpenVPN server also enabled).

Interesting. Nice they let you get it ahead of time. Cant believe they would. Nice results too! Looks like you getting what you pay for +

 

[john9527]

Interesting. Nice they let you get it ahead of time.

I was surprised too.....but it sounded like everything is in place, and they are just 'formally' rolling it out by market area (my guess is for support management).

 

[farfromuman]

From your original post.....
I have about 35 clients and half are setup with IP reservations

I'd suspect at this point that at some point you may have named a client with a character that causes parsing problems. Last try would be to double check that your client names only contain alphanumerics, dash and underscore.

I could not find any names that did not look normal, I even used your utility to pull data out and look at it. I decided to reboot the router one more time and the list populated after a while. Thanks for your help.