Asuswrt-Merlin 374.41 Beta 1 is now available

[RMerlin]

Oh sorry I forgot to mention my router I'm using AC66U. This doesn't happen often it's usually at night but then again it could be my crappy TalkTalk Fibre


Sent from my iPhone

RT-AC66U driver in 374.41 is the same as in 374.39.

 

[RMerlin]

I just uploaded a Beta 2 build. Main change is a fix for the Comcast IPv6 filtering rule that wasn't properly applied. Please give this new build a shot if you are on Comcast with an IPv6, and were previously experiencing table overflows.

Also post the output of the firewall packet count after a while, so we can see how many packets got filtered by the rule:

ip6tables -t mangle -L -v

 

[cmillar6]

I just uploaded a Beta 2 build. Main change is a fix for the Comcast IPv6 filtering rule that wasn't properly applied. Please give this new build a shot if you are on Comcast with an IPv6, and were previously experiencing table overflows.

Also post the output of the firewall packet count after a while, so we can see how many packets got filtered by the rule:

ip6tables -t mangle -L -v

I'm getting an error trying to unzip beta2 for the AC66u

 

[scarzy]

Same error when trying to unzip beta2 for the AC66u, Thanks for the fast update!

 

[ObliteRon]

Same unzip error for RT-AC66U_3.0.0.4_374.41_beta2.zip ... I assume it needs to be re-uploaded.

 

[RMerlin]

Looks like some of the archives got corrupted when I added the MD5 file into them over a network share. I re-created all archives, they are currently finishing uploading - give it 2 mins.

 

[wbennett77]

Can confirm that AC66, AC56 and N66 are now all extracting without errors.

Cheers!

 

[cmillar6]

Took a few reboots to pull an ipv6 address but I finally got one, never had this happen before. I'll keep an eye out for neighbor table overflow errors.

 

[jim769]

Took a few reboots to pull an ipv6 address but I finally got one, never had this happen before. I'll keep an eye out for neighbor table overflow errors.

Just tried bata 2 here and i can not get a v6 address. Factory reset and many reboots no go. @ Merlin this build is broke for V6 here. Back to 5047

 

[DavidEBSmith]

24 minutes, no neighbor messages.

Chain PREROUTING (policy ACCEPT 5267 packets, 655K bytes)
 pkts bytes target     prot opt in     out     source               destination 
  704 50688 DROP       ipv6-icmp    eth0   any     anywhere             ff02::1:ff00:0/104 ipv6-icmp neighbour-solicitation

Chain INPUT (policy ACCEPT 864 packets, 96989 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain FORWARD (policy ACCEPT 2890 packets, 284K bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain OUTPUT (policy ACCEPT 452 packets, 47445 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain POSTROUTING (policy ACCEPT 3529 packets, 348K bytes)
 pkts bytes target     prot opt in     out     source               destination

 

[RMerlin]

Just tried bata 2 here and i can not get a v6 address. Factory reset and many reboots no go. @ Merlin this build is broke for V6 here. Back to 5047

I doubt it. The only change is the same firewall rule that various other users had been previously using. Be patient - I got similar feedback with Beta 1 too where people sometimes didn't immediately obtain a new IPv6 from Comcast. Sometimes, Comcast seems slow at handing out a new IPv6 after a router reboot/reflash.

 

[RMerlin]

24 minutes, no neighbor messages.

Chain PREROUTING (policy ACCEPT 5267 packets, 655K bytes)
 pkts bytes target     prot opt in     out     source               destination 
  704 50688 DROP       ipv6-icmp    eth0   any     anywhere             ff02::1:ff00:0/104 ipv6-icmp neighbour-solicitation

Chain INPUT (policy ACCEPT 864 packets, 96989 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain FORWARD (policy ACCEPT 2890 packets, 284K bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain OUTPUT (policy ACCEPT 452 packets, 47445 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain POSTROUTING (policy ACCEPT 3529 packets, 348K bytes)
 pkts bytes target     prot opt in     out     source               destination

Already 704 dropped packets in 24 minutes. Check again tomorrow after 12-16 hours to see how many packets got dropped. Some people posting on the Comcast forums reported ridiculous amounts of traffic (amounting in megabytes of daily traffic) being dropped by the filter rule.

 

[RMerlin]

It's still working the same on my RT-N66U. Messages go to both /tmp/var/log/nmbd.log and syslog.

Might be platform-specific, as Asus uses different Samba versions between MIPS/ARM.

 

[RMerlin]

Nope

ASUS changed the connection script, /rom/etc/ppp/3g/Generic_conn.scr,

Both scripts within this pastebin, (beta1 row 131)
http://paste.ubuntu.com/7256272/

I have no idea how become root with this read-only file system for testing....

Asus seems to still be fiddling with that script.

merlin@mint-dev ~/fmk/trunk/374-5517-ac66/rootfs $ ls rom/etc/ppp/3g/Generic_conn.scr  -l
-rwxr-xr-x 1 root root 5763 Apr 13 21:18 rom/etc/ppp/3g/Generic_conn.scr
merlin@mint-dev ~/fmk/trunk/374-5517-ac66/rootfs $ ls ../../374-5047-ac68/rootfs/rom/etc/ppp/3g/Generic_conn.scr  -l
-rwxr-xr-x 1 root root 5252 Apr  2 07:49 ../../374-5047-ac68/rootfs/rom/etc/ppp/3g/Generic_conn.scr
merlin@mint-dev ~/fmk/trunk/374-5517-ac66/rootfs $ ls ../../374-4887-ac68/rootfs/rom/etc/ppp/3g/Generic_conn.scr  -l
-rwxr-xr-x 1 root root 2555 Mar 25 06:09 ../../374-4887-ac68/rootfs/rom/etc/ppp/3g/Generic_conn.scr

I could try switching to the newer script found in their recent 5517 release to see if it helps.

 

[geko53]

Asus seems to still be fiddling with that script.
[...]
I could try switching to the newer script found in their recent 5517 release to see if it helps.

That would be great! Seems that the issue is affecting Huawei-sticks primarily - tried some different sticks (Huawei E372, ZTE MF652, 4G XSStick P14), but only E372 refused connecting...

Hope that a workaround can be found.

Tot kijk
Gerald

 

[geko53]

USB 3G/4G issue

Could this help to track down the issue?

System Log using Huawei E372:

Jan 1 01:00:31 WAN Connection: Ethernet link down.
Jan 1 01:00:32 pppd[909]: Connect script failed
...
Jan 1 01:01:37 pppd[1225]: In file /tmp/ppp/peers/3g: unrecognized option '/dev/'
Jan 1 01:01:37 WAN Connection: Fail to connect with some issues.

in file /tmp/ppp/peers/3g you can read:

/dev/ttyACM0
linkname wan0
modem
crtscts
noauth
noipdefault
usepeerdns
defaultroute
nopcomp
noaccomp
novj
nobsdcomp
nodeflate
persist
holdoff 10
connect "/bin/comgt -d /dev/ttyACM0 -s /etc/ppp/3g/Generic_conn.scr"
disconnect "/bin/comgt -d /dev/ttyACM0 -s /etc/ppp/3g/Generic_disconn.scr"

When changing the USB stick and making a reboot I get the following System Log (using ZTE MF652):

Jan 1 01:00:23 WAN Connection: Ethernet link down.
Jan 1 01:00:25 pppd[824]: Serial connection established.
Jan 1 01:00:25 pppd[824]: Using interface ppp0
Jan 1 01:00:25 pppd[824]: Connect: ppp0 <--> /dev/ttyACM0
Jan 1 01:00:28 pppd[824]: local IP address 77.xxx.xxx.82
Jan 1 01:00:28 pppd[824]: remote IP address 10.0.0.1
Jan 1 01:00:28 pppd[824]: primary DNS address 213.xx.xx.16
Jan 1 01:00:28 pppd[824]: secondary DNS address 213.xx.xx.17

No idea what makes the difference...

Ciao
Gerald

 

[cyborgpunte]

Hi, here are my diffs attached
But I have no clue if it's relevant

enviroment RT-AC68U in dualwan mode
LTE Huawei E3276s-150 (none hilink model "normal model") in 3G+ mode
Revision: 21.263.03.01.07
+GCAP: +CGSM,+DS,+ES
^FHVER:"E3276s-150 21.263.03.01.07,CH1E3276SM Ver.C"
AT^SETPORT?:A1,A2;10,12,16,A1,A2

2pcs Generic_conn.scr
374.41_b1 NOT functional modem always in state "disconnected"
374.41_a4 functional in dualwan mode both failover as well as failback
((but must be in USB3.0 port and my WD USB3.0 disc must be in USB2.0 port)

 

[cmillar6]

Neighbor Table Overflow errors appear to be resolved for Comcast with this build, Thanks Merlin.

 

[johnnyboy]

Systemlog ->Connections ->Refresh seems not correct.

The Refresh get the messages from /proc/ip_conntrack or nf_conntrack by using /usr/sbin/netstat-nat tool. But this program's output seems not match the contents of ip_conntrack or nf_conntrack. Some lines will never be discarded after a period of time, and will remain in the window forever.

By inspect the ip_conntrack or nf_conntrack files, I found these zombie lines in it. So I think it may caused by the /proc or net code in the kernel.

 

[neil0311]

Updated to beta 2 last night around 10pm eastern. I have Comcast HSI and typically I've been seeing hundreds of neighbour table overflow errors and printk errors just in a two hour period.

Since the update.....ZERO neighbour overflow or printk errors were logged. No other issues noted with IPv6.

Thank you for the update Merlin.