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

[terribell]

I remember that that was the case, but I can sort of envision a scenario where the 802.1x problem may possible lock thing up as it tries to deal with a potentially invalid certificate on the client side (just to make sure we're talking the same thing, this is not the router 802.11 options, but the special security option on the clients).

Also, please check for any follow-on error/informational messages which usually contain the 'real' reason for the failure.

I'm not using the 802.1x security on my wireless connection of my windows device, only WPA2 connections.

Regarding the messages, I've not found anything that can lead me to 'real' reason, if you have any advice where to look it would be appreciated.

I've just reset again to factory defaults to see if the problem disappears, only thing that is worst than before the reset is that I'm having only 60/100mbps DL/UL on wireless while before it was 200/100mbps on wireless, wired speed remains with 200/100mbps.
Which is strange since it is configured exactly like before with a manual configuration without reloading any saved configuration.

 

[john9527]

@terribell - Take a look under 'Windows Logs/Application' and 'Windows Logs/System' at around the timestamp for the log you posted.

For the wireless, double check that you really have the wireless parms set to what you had before. Could also be external, with a noise/interference source popping up.

 

[john9527]

Release V17E8 is now available...There were a couple of fixes I wanted to get out prior to the next major release.
Unless a significant issue is found, I expect this to be that last update in the V17 series. V18 will be next...in about 8 weeks.

LATEST RELEASE: Update-17E8
9-April-2016
Merlin fork 374.43_2-17E8j9527
Download http://1drv.ms/1uChm3J
============================

Update-17E8

• Dropbear: validates xauth input (security fix from upstream) - was only exposed to people you have already given SSH access to
• Dropbear: disable X11 forwarding support (security fix) - was only exposed to people you have already given SSH access to
• No longer flush the mangle table on QOS start, just delete any existing QOS rules
  This will help cure some 'mysterious' loss of iptables mangle rules, both firmware and user added
• Rewrite VPN exclusive mode 'Only VPN clients use VPN DNS' option
  There are some differences between the main Merlin branch now and this fork, and I didn't like how this was behaving. Changed the implementation somewhat and I think it's much better now.
  Note that this option and any Parental Controls/DNS Filter options will bypass some custom addons, like AB-Solution, for some clients . This is true for the main Merlin releases as well.
• Source address field added to Port Forwarding system log page
• Fix for enhanced httpd status watchdog incorrectly shutting down on the first failure/recovery
• Fix for Native DHCP addresses sometimes failing to renew successfully - @LiFePO4
• Fix for Traditional QOS gui issues in modifying or deleting user rules - @Grump
• Fix for client names not showing in Parental Controls selection pulldown

Enjoy!

 

[unknownz]

hi there, thanks for the great work.

does the new update (17E8) fix the port forwarding issue that was previously reported?

im currently on (17E5) and also encounter similar issue with regards to port forwarding.

my current port forwarding is as such:
- WAN port 8080 to LAN port 80 (192.168.1.131) - works ok
- WAN port 8181 to LAN port 81 (192.168.1.134) - not working

Spoiler: output of iptables -t nat -L -v | grep DNAT

0 0 DNAT tcp -- any any anywhere anywhere tcp dpt:7080 to:192.168.1.1:80
242 12584 DNAT tcp -- any any anywhere anywhere tcp dpt:7443 to:192.168.1.1:8443
1 52 DNAT tcp -- any any anywhere anywhere tcp dpt:31107 to:192.168.1.135:22
0 0 DNAT tcp -- any any anywhere anywhere tcp dpt:27272 to:192.168.1.135:21
1 52 DNAT tcp -- any any anywhere anywhere tcp dpt:5001 to:192.168.1.135:5001
52 3184 DNAT tcp -- any any anywhere anywhere tcp dpt:7681 to:192.168.1.135:443
8 464 DNAT tcp -- any any anywhere anywhere tcp dpt:7682 to:192.168.1.135:80
285 17308 DNAT tcp -- any any anywhere anywhere tcp dpt:webcache to:192.168.1.131:80
0 0 DNAT tcp -- any any anywhere anywhere tcp dpt:6260 to:192.168.1.136:6260
7 312 DNAT tcp -- any any anywhere anywhere tcp dpt:9000 to:192.168.1.135:1080
307 19648 DNAT tcp -- any any anywhere anywhere tcp dpt:8181 to:192.168.1.134:81

 

[john9527]

my current port forwarding is as such:
- WAN port 8080 to LAN port 80 (192.168.1.131) - works ok
- WAN port 8181 to LAN port 81 (192.168.1.134) - not working

The iptables data shows that the forwarding is working fine (307 packets were forwarded to .134:81). Since you are using a non-standard port on the .134 destination, have you opened the firewall on the client for port 81?

 

[unknownz]

The iptables data shows that the forwarding is working fine (307 packets were forwarded to .134:81). Since you are using a non-standard port on the .134 destination, have you opened the firewall on the client for port 81?

.131 and .134 are actually my ip cameras (different manufacturer) and i've no issue accessing the login page for both devices on my local LAN.
http://192.168.1.131/eng/index.html
http://192.168.1.134:81/

it is only accessing from the WAN that im facing this issue.

 

[john9527]

Any problems with port forwarding usually affect all forwards, not just a single one. From the router point of view, it looks like the forward is occurring. Just to make sure, you might try setting the protocol to both to cover UDP as well just in case.

BTW....what model router?

Right now, my best suggestion is to check the support site for that particular camera.

 

[unknownz]

Any problems with port forwarding usually affect all forwards, not just a single one. From the router point of view, it looks like the forward is occurring. Just to make sure, you might try setting the protocol to both to cover UDP as well just in case.

BTW....what model router?

Right now, my best suggestion is to check the support site for that particular camera.

yes, i agree that issue(s) with port forwarding should affect all rules and that's the reason im puzzled that this only happens to 1 forward rule.

tried your suggestion about setting both TCP/UDP but fails as well

Spoiler: output of iptables -t nat -L -v | grep DNAT

admin@rt-n66u:/tmp/home/root# iptables -t nat -L -v | grep DNAT
0 0 DNAT tcp -- any any anywhere anywhere tcp dpt:7080 to:192.168.1.1:80
137 7100 DNAT tcp -- any any anywhere anywhere tcp dpt:7443 to:192.168.1.1:8443
1 52 DNAT tcp -- any any anywhere anywhere tcp dpt:31107 to:192.168.1.135:22
0 0 DNAT tcp -- any any anywhere anywhere tcp dpt:27272 to:192.168.1.135:21
0 0 DNAT tcp -- any any anywhere anywhere tcp dpt:5001 to:192.168.1.135:5001
3 156 DNAT tcp -- any any anywhere anywhere tcp dpt:7681 to:192.168.1.135:443
0 0 DNAT tcp -- any any anywhere anywhere tcp dpt:7682 to:192.168.1.135:80
0 0 DNAT tcp -- any any anywhere anywhere tcp dpt:6260 to:192.168.1.136:6260
0 0 DNAT tcp -- any any anywhere anywhere tcp dpt:9000 to:192.168.1.135:1080
22 1408 DNAT tcp -- any any anywhere anywhere tcp dpt:8181 to:192.168.1.134:81
0 0 DNAT udp -- any any anywhere anywhere udp dpt:8181 to:192.168.1.134:81
366 23424 DNAT tcp -- any any anywhere anywhere tcp dpt:webcache to:192.168.1.131:80
0 0 DNAT udp -- any any anywhere anywhere udp dpt:webcache to:192.168.1.131:80

im currently using asus rt-n66u

on tomato-shibby firmware, i did not encounter this port forwarding issue with the same setup/forward rule(s)

 

[john9527]

@unknownz - A silly thought.....do you have either URL or Keyword filters defined (even if not for this address). If so, please try disabling them.

 

[unknownz]

@unknownz - A silly thought.....do you have either URL or Keyword filters defined (even if not for this address). If so, please try disabling them.

i've not done any setup on those 2 filters so they're in the default state i.e. disabled

 

[john9527]

@unknownz - The only other difference with Tomato is that Tomato doesn't do CTF. Try it with that disabled if you have it enabled.

 

[tyspeed42]

Installed V17E8 on both my AC68U and AC66U and all is well and working awesome. Thanks John.

 

[unknownz]

@unknownz - The only other difference with Tomato is that Tomato doesn't do CTF. Try it with that disabled if you have it enabled.

yes, that was the reason why i made the switch.

have disabled "NAT Acceleration" and again, no luck with the forwarding.

guess i might try updating to 17E8 or try testing out with Merlin's firmware when im more free

 

[john9527]

@unknownz - When you say access from WAN, are you really outside your LAN or accessing from your LAN with a WAN address? If the latter, try this....

ssh/telnet to the router and

nvram set fw_nat_loopback=1
nvram commit

then reboot

 

[unknownz]

@unknownz - When you say access from WAN, are you really outside your LAN or accessing from your LAN with a WAN address? If the latter, try this....

ssh/telnet to the router and

nvram set fw_nat_loopback=1
nvram commit

then reboot

my meaning of WAN would be e.g. mobile data (3G/4G), public/office WiFi (verified no ports restriction), etc.

 

[terribell]

@terribell - Take a look under 'Windows Logs/Application' and 'Windows Logs/System' at around the timestamp for the log you posted.

For the wireless, double check that you really have the wireless parms set to what you had before. Could also be external, with a noise/interference source popping up.

From the logs you suggested it only informs that the router did not respond to the association request:
"
The Network Diagnostics Framework has completed the diagnosis phase of operation. The following repair option was offered:

Helper Class Name: RNWF MSM Helper Class

Root Cause: Wireless association to SSID-X failed
A response was not received from the router or access point.

Root Cause Guid: {0576ac9e-f3d4-4148-ac43-0820b503d3b3}

Repair option: Resetting your wireless network adapter
This will disable and then enable the network adapter "Wi-Fi" on this computer.

RepairGuid: {07d37f7b-fa5e-4443-bda7-ab107b29afb9}

Seconds required for repair: 300

Security context required for repair: 80

Interface: Wi-Fi ({f6129256-cf3b-4894-90f9-ed498e880549})
"

 

[sbailey4]

Any reason for the LAN speed to drop substantially with v17? Plugged in I am now only getting around 200mbs on a 1gb connection. Direct connect to modem 850-900 mbs. I cant totally recall but I was getting 500-600 previously I believe. (had a 30/30 connection that they somehow provisioned wrong so was getting 500mbs for a while). Officially upgraded to 1gb last week. For some reason through AC66 it taps our around 200. NAT acceleration is enabled. I cleared NVRAM this am to default the router but didnt seem to make a difference.

 

[john9527]

Any reason for the speed to drop substantially with v17?

No, nothing I can think of. Given the changes in service you've had (and I'm assuming a new modem as well), first thing I would do is power down the modem and router for about 1/2 hour to allow the ISP to reset the connection. Then power up the modem and let it sync, then the router.

 

[Deleted member 27741]

^^ THIS. I have to do this after every firmware change. Cox slows it down to a generic speed without fail and powering down the modem and router for 1/2 hour always takes care of it.

 

[sbailey4]

No, nothing I can think of. Given the changes in service you've had (and I'm assuming a new modem as well), first thing I would do is power down the modem and router for about 1/2 hour to allow the ISP to reset the connection. Then power up the modem and let it sync, then the router.

No new modem. just changed the IP address it connects to (so they said) to point to new servers. Dunno because as I said I was already getting 500/600 before they did anything. And I can get those speeds (even 850/900) direct connected to modem. Maybe I will downgrade to 16 and see what happens. (after your recommendation ) Thanks John!