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

[ocram59]

Let's double check that everything is there.....try these commands.....both should return a file....

modprobe -l | grep webmon (that's a small 'L' in -l)
find /usr/lib -name libipt_webmon*

Hi John thanks for your help
Here it is the result of the commands you suggested

admin@RT-N66U:/tmp/home/root# modprobe -l | grep webmon
/lib/modules/2.6.22.19/kernel/net/ipv4/netfilter/ipt_webmon.ko

admin@RT-N66U:/tmp/home/root# find /usr/lib -name libipt_webmon*
/usr/lib/iptables/libipt_webmon.so
admin@RT-N66U:/tmp/home/root#

and here it is the ls of the modules :

admin@RT-N66U:/tmp/home/root# ls -al /lib/modules/2.6.22.19/kernel/net/ipv4/netfilter/ipt_webmon.ko
-rw-r--r--  1 admin  root  30412 Mar 11 4:35 /lib/modules/2.6.22.19/kernel/net/ipv4/netfilter/ipt_webmon.ko

admin@RT-N66U:/tmp/home/root# ls -al /usr/lib/iptables/libipt_webmon.so
-rwxr-xr-x    1 admin    root         10400 Mar 11 04:34 /usr/lib/iptables/libipt_webmon.so

Looks like everything is in place?
Is it possible that any other setting or installed package could cause a conflict with webmon?

Thanks
Ocram

 

[d4free]

Hi, i know that you need to put

nvram set 0:maxp2ga0=114
nvram set 0:maxp2ga1=114
nvram set 0:maxp2ga2=114
nvram set 1:maxp5ga0=114,114,114,114
nvram set 1:maxp5ga1=114,114,114,114
nvram set 1:maxp5ga2=114,114,114,114
nvram set wl_TxPower=500
nvram set wl0_TxPower=500
nvram set wl1_TxPower=500
nvram set pci/1/1/ccode=#a
nvram set pci/1/1/regrev=0
nvram set pci/2/1/ccode=#a
nvram set pci/2/1/regrev=0

nvram set 0:ccode=#a
nvram set 1:ccode=#a
nvram set 0:regrev=0
nvram set 1:regrev=0
nvram set wl0_country_code=#a
nvram set wl0_country_rev=0
nvram set wl0_reg_mode=off
nvram set wl1_country_code=#a
nvram set wl1_reg_mode=off
nvram set regulation_domain_5G=#a
nvram set regulation_domain=#a
nvram set wl_country_rev=0
nvram set wl_country_code=#a
nvram commit
reboot

to get max power, but what do i need to do if i only want 200mW output on 2.4 and 5ghz?
Is using the commands
nvram set wl_TxPower=200
nvram set wl0_TxPower=200
nvram set wl1_TxPower=200
instead of 500 enough? Or do i need to lower the 114 thingys too

What does nvram set 0:maxp2ga0=114 etc etc do?

 

[john9527]

and here it is the ls of the modules :

admin@RT-N66U:/tmp/home/root# ls -al /lib/modules/2.6.22.19/kernel/net/ipv4/netfilter/ipt_webmon.ko
-rw-r--r-- 1 admin root 30412 Mar 11 4:35 /lib/modules/2.6.22.19/kernel/net/ipv4/netfilter/ipt_webmon.ko

admin@RT-N66U:/tmp/home/root# ls -al /usr/lib/iptables/libipt_webmon.so
-rwxr-xr-x 1 admin root 10400 Mar 11 04:34 /usr/lib/iptables/libipt_webmon.so
Looks like everything is in place?
Is it possible that any other setting or installed package could cause a conflict with webmon?

As far as I can tell, that looks right.

Then, I was going to suggest what you already tried.....

I also tried to executed the firewall_start lines manually one by one and I got no error

Only other idea is if you are running a VPN Client....then you need to add a rule covering the tunnel....for example for OpenVPN
iptables -t filter -I FORWARD -o tun11 -j monitor

 

[RadarJammer]

I think a line is missing from your commands:

nvram set wl1_country_rev=0

...

nvram set 0:ccode=#a
nvram set 1:ccode=#a
nvram set 0:regrev=0
nvram set 1:regrev=0
nvram set wl0_country_code=#a
nvram set wl0_country_rev=0
nvram set wl0_reg_mode=off
nvram set wl1_country_code=#a
nvram set wl1_reg_mode=off
nvram set regulation_domain_5G=#a
nvram set regulation_domain=#a
nvram set wl_country_rev=0
nvram set wl_country_code=#a
nvram commit
reboot

...

 

[Gunner84]

Just to say thanks John.

Im running update 8 on my n66u and so far all seems good. I downgraded from 378.51 so did a reset. not changed much in way of settings.
Just using a fixed channel for 2.4ghz band and disabled wps.

Is there any tweaks I should make?

 

[Builder71]

Hi John
Thanks alot for the update.
I tried to enable webmon following the txt you provided to us on RT-N66U
For some reason it did not work and so i began to investigate about the possible reason.
I found a post of yours in another thread and I noticed some differences in the firewal-start script

Here it is the content of the txt

--Start of code
# Enable webmon monitoring
  if [ -z "$(iptables -n -L FORWARD | grep 'web_monitor')" ]; then
     modprobe ipt_webmon
     iptables -t filter -N monitor
     iptables -t filter -I FORWARD -o eth0 -j monitor
     iptables -A monitor -p tcp -m webmon --max_domains 2000 --max_searches 2000
fi

It looks like that the script looks for web_monitor but it creates the table" monitor" so the test is always positive.


This is what I found in another post.

# Enable webmon monitoring
  if [ -z "$(iptables -n -L FORWARD | grep 'web_monitor')" ]; then
     modprobe ipt_webmon
     iptables -t filter -N web_monitor
     iptables -t filter -I FORWARD -o eth0 -j web_monitor
     iptables -A web_monitor -p tcp -m webmon --max_domains 2000 --max_searches 2000
fi

In this scritpt the table web_monitor is created and tested so , it looks like that there is a small error in the more recent txt?
Anyway for some reason with either versions of firewall_start , webmon seems to have problems in workking on my RT-N66U and the two reports files are create but always zero Length

I also tried to executed the firewall_start lines manually on eby one and I got no error
So at this pont I have no clue on why webmon does not work here
Any suggestiion?
Anoone having webmon working onr RT-N66U

Thanks alot for your fork and your continuos support to us

Best Regards
Ocram

I don't have in-depth knowledge with scripts, but I used the "Using-Webmon.txt" file from John's download section to create them.
It's working great on my RT-N66U.

 

[Builder71]

...
As you can see the files are bot up to date (7.28 PM) but always 0 length
...

This is normal.

"Things in /proc are not really files. In most cases, they're not even files in memory. When you access these files, the proc filesystem driver performs a system call that gets data appropriate for the file, and then formats it for output. This is usually dynamic data that's constructed on the fly. An example of this is /proc/net/arp, which contains the current ARP cache."

 

[Builder71]

Hmmm, catched it again.
I applied a setting in my wireless professional page before.
Guess not related but I'll try again to recreate...

Edit: **YES**, that did the trick!
Just hit Apply on the Wireless Professional page (tested 5 GHz), no need to change anything.
This gives the spinning icon and failed to start message on my VPN Server page.

I hope you can recreate John.

 

[john9527]

Edit: **YES**, that did the trick!
Just hit Apply on the Wireless Professional page (tested 5 GHz), no need to change anything.
This gives the spinning icon and failed to start message on my VPN Server page.

I hope you can recreate John.

Just to make sure I got the conditions.....the Server is actually already up, but when you go into the gui you get that message?

 

[Builder71]

Just to make sure I got the conditions.....the Server is actually already up, but when you go into the gui you get that message?

Yes sir.
And if you see the failed to start message, the OpenVPN server is not affected.
Keeps running fine.
It's some kind of GUI reporting the wrong thing bug.

 

[john9527]

Yes sir.
And if you see the failed to start message, the OpenVPN server is not affected.
Keeps running fine.
It's some kind of GUI reporting the wrong thing bug.

Could you do it one more time and check the following nvram values for me when you have the message up?

nvram get vpn_server1_state
nvram get vpn_server1_errno
nvram get vpn_server2_state
nvram get vpn_server2_errno

 

[Builder71]

Could you do it one more time and check the following nvram values for me when you have the message up?

nvram get vpn_server1_state
nvram get vpn_server1_errno
nvram get vpn_server2_state
nvram get vpn_server2_errno

See pic.

 

[john9527]

Yes sir.
And if you see the failed to start message, the OpenVPN server is not affected.
Keeps running fine.
It's some kind of GUI reporting the wrong thing bug.

Bad news....I can't recreate it

I'll hunt through the code and see if I can spot anything.....

And when you get a chance....a couple more nvram vars (doesn't need to be in the strange state)
nvram get vpn_serverx_eas
nvram get vpn_server_unit

And what happens if you have the message up and just hit refresh in your browser?

 

[reboot4239]

Is there still a vulnerability in the WPS script? Should WPS be disabled?

 

[john9527]

Is there still a vulnerability in the WPS script? Should WPS be disabled?

As far as I know, I've picked up everything. It doesn't ring a bell....have a pointer?

 

[RMerlin]

Bad news....I can't recreate it

I've had this happen randomly to me over the past months, and I never managed to figure out what triggered it. All I knew was that the status nvram wasn't set to a running value, leaving it out of sync with reality, and leaving the webui thinking the rc daemon was currently busy generating default key/certs.

Asus and I both did a number of changes to that OpenVPN page over the past months. It's possible that one of these changes has since resolved it, since it's been a while since I've last experienced it. I recommend you take a look at the following areas:

- router/openvpn/* (the nvram errno/state code is set there)
- rc/openvpn.c
- www/*VPN* pages (not sure which of these you are using in the 376.43 codebase, I moved things around a bit at some point)

EDIT: the status nvram I was thinking of is vpn_server1_state. For some reason that value would sometimes be set to "0" despite the key/certs being already there.

There's also a vpn_server1_errno, but it's unrelated to the display of the configuration message you are seeing on the webui.

 

[john9527]

I already had honed in on the vpn_server1_state variable, thanks for confirming....what I can't figure out (yet?) is what his recreate scenario does to trigger it. Just re-applying settings on the Wireless/Professional page?????

 

[reboot4239]

As far as I know, I've picked up everything. It doesn't ring a bell....have a pointer?

Yeah, here's what I found:

http://www.securityweek.com/asus-routers-plagued-command-execution-vulnerability

Many ASUS wireless routers are affected by a vulnerability that can be exploited by an attacker with access to the target’s local area network (LAN) to execute arbitrary commands.

The security hole was uncovered by Joshua Drake, practice manager of Accuvant Labs’ research and development department. The flaw has been assigned the CVE identifier CVE-2014-9583.

According to Drake, the vulnerability exists in infosvr, a LAN discovery service that runs with root privileges. The service listens on UDP broadcast port 9999, which can be leveraged by an unauthenticated attacker to send packets containing malicious code and take control of the device.

Drake has successfully tested the attack on an ASUS RT-N66U router running firmware version 3.0.0.376.2524-g0013f52. However, David Longenecker, who has also recently discovered a vulnerability in Asus routers, has confirmed that the bug affects the newest router model, RT-AC87U, running the latest firmware release (3.0.0.4.378_3754).

Longenecker has pointed out in a blog post that the exploit for this attack is limited to 237 characters. If the limit is exceeded, the device likely crashes due to a buffer overflow.

ASUS is reportedly aware of the issue and is already working on a fix. However, an exploit for the vulnerability is publicly available so users who don’t trust the individuals connecting on their LAN should take some measures.

A new version of Asuswrt-Merlin, a custom firmware for ASUS routers developed by Eric Sauvageau, mitigates potential attacks by disabling the feature responsible for remote code execution. Sauvageau has pointed out that this is just a temporary solution until Asus releases a proper fix. Alternatively, the expert recommends using the router’s firewall to block potential attacks.

Longenecker recommends killing the infosvr process on boot by running a script from a USB drive.

Another option, suggested by Drake, is to disable the infosvr service after boot. This task, which can be carried out by leveraging the vulnerability itself, must be repeated after each boot.

“Remove the remote command execution functionality from this service. Even if it were guarded with strong authentication, broadcasting a password to the entire LAN isn't really something to be desired. If command execution is truly desired it should be provided via SSH or similar secure mechanism,” Drake recommended.

 

[RMerlin]

I already had honed in on the vpn_server1_state variable, thanks for confirming....what I can't figure out (yet?) is what his recreate scenario does to trigger it. Just re-applying settings on the Wireless/Professional page?????

Due to the randomness of the issue, I suspect it might be something more arcane, such as a racing condition somewhere. And I still don't know if the issue still exists, or was fixed at some point in time.

 

[john9527]

Many ASUS wireless routers are affected by a vulnerability that can be exploited by an attacker with access to the target’s local area network (LAN) to execute arbitrary commands.

Fixed since Update-06E.....I put out a special build just to address this.