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

[rtn66uftw]

20/40 will 'downgrade' automatically based on conditions....40 forces it (may be 40, but may actually not be optimal and you may be impacting someone else's connection).

Hi John! Would you recommend 20 or 20/40 in wifi crowded area? When I turn on inSSIDer, I can see about 10 other wifi networks. Most of them at about -80dBm, two of which are at about -50dBm. Thanks!

 

[Nullity]

Hi John! Would you recommend 20 or 20/40 in wifi crowded area? When I turn on inSSIDer, I can see about 10 other wifi networks. Most of them at about -80dBm, two of which are at about -50dBm. Thanks!

Most people consider 40Mhz to be a bad idea on 2.4Ghz, especially in a congested WiFi situation like yours.

20/40 is likely fine on 5Ghz.

 

[threepwood]

Upgraded to beta 19B4 and happy to report that the new MEO IPTV profile is working flawlessly.

John, will you also add the new profiles to the Initial Setup page (like Asus/Merlin firmwares)? They're to be found when setting up the Internet Connection Type and selecting "Special requirement from ISP".

Keep up the good work.

 

[rtn66uftw]

Most people consider 40Mhz to be a bad idea on 2.4Ghz, especially in a congested WiFi situation like yours.

20/40 is likely fine on 5Ghz.

Thanks! I'm wondering if either AC68U or N66U will be able to automatically fall back to 20 MHz in case of interference in 20/40 MHz mode?

 

[ColinTaylor]

Thanks! I'm wondering if either AC68U or N66U will be able to automatically fall back to 20 MHz in case of interference in 20/40 MHz mode?

Yes, that's the whole purpose of 20/40 MHz mode. 20 forces 20MHz mode, 40 forces 40MHz mode and with 20/40 the router will be in 40MHz mode unless it detects a conflict with another device in which case it will switch to 20MHz mode (and stay there).

See here for an explanation and test results for the N66U:
http://www.smallnetbuilder.com/wireless/wireless-features/31743-bye-bye-40-mhz-mode-in-24-ghz-part-1
http://www.smallnetbuilder.com/wireless/wireless-features/31744-bye-bye-40-mhz-mode-in-24-ghz-part-2

Remember also that even if your client can only communicate in 20MHz mode it can still talk to an access point running in 40MHz mode (it just uses the primary channel).

 

[john9527]

Can confirm this is fixed. Thanks John!

19B4 loaded, sftp is working.

Upgraded to beta 19B4 and happy to report that the new MEO IPTV profile is working flawlessly.

Thanks all for the feedback!

John, will you also add the new profiles to the Initial Setup page (like Asus/Merlin firmwares)? They're to be found when setting up the Internet Connection Type and selecting "Special requirement from ISP".

Will take a look.

 

[john9527]

Thanks! I'm wondering if either AC68U or N66U will be able to automatically fall back to 20 MHz in case of interference in 20/40 MHz mode?

Can confirm it works on the AC68.....occasionally after a reboot with it set to 20/40, I'll get a 40MHz connection. Usually within about a minute it will fall back to the 20MHz. This with about 10-15 other access points around.

 

[john9527]

John, can you add support for slovenian telecom iptv provider to lan-iptv?

sent from Kodi 17 Krypton

Sorry, but if it's not in ASUS/Merlin, I have no idea what is required (and even then, I'm passing on some, like Movistar, because of all the changes required).

 

[Chrysalis]

Time for another beta...
For this one, I need some help testing some changes that I am unable to run.

BETA RELEASE: Update-19B4
27-August-2016
Merlin fork 374.43_2-19B4j9527
Download http://bit.ly/1UGjcOX
============================

Following are the major changes (full changelog is in the zip files)

• Support prefix lengths other than 64 for native IPv6
  This is one needing some testing, as my ISP only supports 64 prefix length.
• Support Meo, Vodaphone and Hinet MOD profiles for IPTV
  Another one where I need help testing, both the new profiles and older ones, as I needed to make some changes affecting the older profiles in order to support the new.
  Before anyone asks, Movistar is NOT supported. Movistar is a complex nightmare, and I quit working on it after backporting over 1000 lines of code.
• Update to version 6 of IPSET for ARM routers
  This updates IPSET to the same version used by Tomato and DD-WRT for ARM. It will require some changes to scripts if you are using IPSET on ARM. Here's a code snip that will detect the IPSET version and apply the correct modules. The rest of the commands for IPSET should be backwards compatible. If you find something that is not, please give feedback.
  

  # Load ipset modules                                                        
  ipset -v | grep -i "v4" > /dev/null 2>&1                                      
  if [ $? -eq 0 ];                                                              
  then                                                                    
     # old ipset                                                           
     ipsetv=4                                                              
     lsmod | grep "ipt_set" > /dev/null 2>&1 || \                          
     for module in ip_set ip_set_nethash ip_set_iphash ipt_set             
     do                                                                    
         insmod $module                                                
     done                                                                  
  else                                                                          
     # new ipset                                                  
     ipsetv=6                                                     
     lsmod | grep "xt_set" > /dev/null 2>&1 || \                  
     for module in ip_set ip_set_hash_net ip_set_hash_ip xt_set   
     do                                                           
         insmod $module                                       
     done                                                         
  fi

• Fixes/Updates
  • Minidlna would use a different uuid on every start. If your DLNA client tracked DLNA servers, this would result in multiple 'phantom' servers being shown as offline.
  • Dropbear: fix ability to link to SFTP server - @errorsys
  • Dropbear: include dropbearconvert utility
  • AICloud: pick up some changes tied to the update to lighttpd - @Grump

As always, a reminder to users with MIPS routers to have a backup of /jffs just in case!

SHA256

5d7f532aba9c797fd0de1960ff9bceeb2a33eac844e0f78d24c61cf39347675f  RT-AC68U_3.0.0.4_374.43_2-19B4j9527.trx
a03585f705272da7abb109c2cb631a824c99c7eeb54e9a80e835aa837f5ce7dc  RT-AC56U_3.0.0.4_374.43_2-19B4j9527.trx
411f51434e13234520c1514b876c16ad78c7a4b14ed1d4348cf3cf5e234b4276  RT-N16_3.0.0.4_374.43_2-19B4j9527.trx
8a0c0133ef51dd0c6decb1eccaa985f6e60d0eeab939aeefef8cf14883eb2659  RT-AC66U_3.0.0.4_374.43_2-19B4j9527.trx
4d85fc688974c72e8286b7ea5f2c6c6efb292eb1e6a68c15f907fac412423f64  RT-N66U_3.0.0.4_374.43_2-19B4j9527.trx

John crazy timing.

My ISP Sky in the UK uses /56 prefix but I did not know the firmware did not support it, and I was unable to get it to work.

So I will flash this and report back.

 

[john9527]

John crazy timing.

My ISP Sky in the UK uses /56 prefix but I did not know the firmware did not support it, and I was unable to get it to work.

So I will flash this and report back.

Great! The LAN prefix length field on the IPv6 setup page was a display only (always 64). Now you can enter a new value to change it.

 

[rtn66uftw]

Yes, that's the whole purpose of 20/40 MHz mode. 20 forces 20MHz mode, 40 forces 40MHz mode and with 20/40 the router will be in 40MHz mode unless it detects a conflict with another device in which case it will switch to 20MHz mode (and stay there).

See here for an explanation and test results for the N66U:
http://www.smallnetbuilder.com/wireless/wireless-features/31743-bye-bye-40-mhz-mode-in-24-ghz-part-1
http://www.smallnetbuilder.com/wireless/wireless-features/31744-bye-bye-40-mhz-mode-in-24-ghz-part-2

Remember also that even if your client can only communicate in 20MHz mode it can still talk to an access point running in 40MHz mode (it just uses the primary channel).

Can confirm it works on the AC68.....occasionally after a reboot with it set to 20/40, I'll get a 40MHz connection. Usually within about a minute it will fall back to the 20MHz. This with about 10-15 other access points around.

Thank you guys!

 

[Chrysalis]

Great! The LAN prefix length field on the IPv6 setup page was a display only (always 64). Now you can enter a new value to change it.

done it but still no go.

However I got no idea if my isp has activated ipv6 so I am defenitly not a reliable test case. Officially I am supposed to be using their router as they do not support third party routers, apparently I need to wait for their supplied router to update its firmware, then activate ipv6 on my account and then it will finally work on third party routers, the prefix they use is /56.

I have left 19b4 installed as nothing seems broken but right now I plan to leave the isp's router plugged in for a day or two to see if they update its firmware and activate ipv6, if they do the ac68 will get plugged back in and I will try native ipv6 on it again. I will update here if some progress.

 

[john9527]

done it but still no go.

However I got no idea if my isp has activated ipv6

It should be the modem that needs to be provisioned to support IPv6. If you can access the modem logs, you may be able to see the configuration change pushed and a modem reboot.

 

[Builder71]

Don't profess to know the details as to how it's being used by the providers, but the PRIO field sets a 802.11q qos tag for the various VLANs (it's a parameter passed to vconfig). Some of the profiles do use a PRIO other than 0.

Basically yes, the profiles are setting up the LAN ports and VLANs.

Interesting.
Connected my ISP's Arcadyan to see if I could find some more info for the PRIO setting.
Yes it does, see attached picture.

Using Google this should be CoS numbers on layer 2.
So internet and IP telephony (VLAN34) uses CoS 1.
IP TV (VLAN 4) uses CoS 5.

Seems to match with a CoS table I found on the internet.

Priority - 802.1p Name
0 - Best Effort (lowest)
1 - Background
2 - Reserved
3 - Effort
4 - Load
5 - Video
6 - Voice
7 - Network (highest)

So internet and IP telephony is on "Background" and IP TV on "Video".
I tried this on my RT-N66U and it seems to work!

Only weird thing is, the RT-N66U allows you to enter PRIO = 0-9.
While the Layer 2 CoS setting is only a 3 bit value. (8 possible values.)
So 0 -> 7 in the above table is fine.
Does the RT-N66U accept #8 and #9?

That is why I'm not 100% sure if the values I see in my Arcadyan directly translate to the PRIO setting.

Any thoughts on this?

 

[john9527]

Only weird thing is, the RT-N66U allows you to enter PRIO = 0-9.

ASUS does the checking in two steps It only checks for a single digit number when you enter the value....when you try to Apply with PRIO equal 8 or 9 it will flag it with a pop-up telling you it must be between 0 and 7.

 

[Builder71]

ASUS does the checking in two steps It only checks for a single digit number when you enter the value....when you try to Apply with PRIO equal 8 or 9 it will flag it with a pop-up telling you it must be between 0 and 7.

Nice, I was afraid to hit Apply and test it.
So it does directly translate to the PRIO setting.
Seems to work great.

Guess still not good enough for a RT-N66U "ISP Profile". (Telfort FTTH, in Dutch: Telfort Glasvezel.)
This setup drives my STB into "bridged mode".
The Arcadyan, from my ISP, sets the STB into "routed mode".

In routed mode the STB gives you one extra menu item "Meer TV".
Effectively the STB can go on the WWW as well.
That adds a few Apps like Netflix, weather radar and so on.
Not really interested in that because my Chromecast V2 is much more powerful.

However it is a challenge to get this routed mode working with the RT-N66U.
Great (CLI) stuff for a rainy sunday afternoon.

 

[Chrysalis]

It seems dhcp6s.conf is missing, where should this file exist?

Sep 1 13:51:40 dhcp6s: start dhcp6s (0)
Sep 1 13:51:40 dhcp6s[2990]: yyerror0: /etc/dhcp6s.conf 4: syntax error
Sep 1 13:51:40 dhcp6s[2990]: yyerror0: /etc/dhcp6s.conf 4: fatal parse failure: exiting (1 errors)
Sep 1 13:51:40 dhcp6s[2990]: main: failed to parse configuration file

 

[octopus]

John, can you add support for slovenian telecom iptv provider to lan-iptv?

sent from Kodi 17 Krypton

Here you can get what you want, tut to config manual settings to IPTV.
http://www.snbforums.com/threads/fo...ilable-v18e3-v19b4.18914/page-210#post-278534

 

[Chrysalis]

ok now it is working.

The dhcp6c.conf is not been auto generated so I made one in /jffs/configs based on this post.

http://www.snbforums.com/threads/asuswrt-merlin-376-48-is-out.20605/page-9#post-150440

That then generated an error that /tmp/dhcp6 could not execute so I then found this post on ddwrt forums.

http://www.dd-wrt.com/phpBB2/viewtopic.php?p=905229&sid=d2a29ad940bd3d569bea44b054a9511f#905229

I confirmed /sbin/dhcp6-state exists so ammended the script line.

Now dhcp6c started and fields are populated in the ipv6 page. I am about to test if wan ipv6 is actually working.

Here is contents of my dhcp6c.conf file

interface eth0 {
script "/sbin/dhcp6c-state";
send rapid-commit;
send ia-pd 1015880;
request domain-name-servers;
request domain-name;
};
id-assoc pd 1015880 {
prefix-interface br0 {
sla-id 1;
sla-len 0;
};
};

wan ipv6 is working.

 

[Chrysalis]

another update.

radvd gets confused with a non /64 prefix, lan prefix has to be /64, so the auto generated radvd.conf was generating these errors.

Sep  1 14:23:34 radvd[4610]: prefix length should be 64 for br0
Sep  1 14:23:38 radvd[4610]: prefix length should be 64 for br0
Sep  1 14:23:45 radvd[4610]: prefix length should be 64 for br0

and no lan devices were been assigned a ipv6 ip, only link local.

The generated radvd.conf had added a /56 as follows.

nterface br0
{
IgnoreIfMissing on;
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvHomeAgentFlag off;
AdvManagedFlag on;
AdvOtherConfigFlag on;
prefix <censored>::/56
{
  AdvOnLink on;
  AdvAutonomous off;
  AdvValidLifetime 3600;
  AdvPreferredLifetime 3600;
  DeprecatePrefix on;
};
RDNSS fe80::a62:66ff:fe96:afe0 {};
};

The fix was to ammend the /56 to /64. Now lan side devices have wan ipv6 access.

It seems also dhcp6c doesnt even attempt to start automatically, I have to run service start_dhcp6c. Dhcpv6 is ticked in the ipv6 settings page.