Hi hnyman,

I found a question after the release 36612. In r36612 or before, if I create a "Port Forwards" rule using LuCI, OpenWrt tries to distinguish whether the mapping is destined to the router itself or another host in the zone. Respectively, OpenWrt will create filter rule in the INPUT chain (linked to zone_wan  chain as showed below), and in the FORWARD chain, besides NAT rules.

-A zone_wan -d 192.168.1.1/32 -p tcp -m tcp --dport 22 -m conntrack --ctstate DNAT -j ACCEPT
-A zone_wan -d 192.168.1.1/32 -p tcp -m tcp --dport 443 -m conntrack --ctstate DNAT -j ACCEPT

But this isn't the case in r36936 or r37529. In these newer releases, OpenWrt always create filter rules in FORWARD chain (besides NAT rules) without caring whether the destination is bound to the router itself.

-A zone_lan_forward -s 192.168.1.0/24 -d 192.168.1.1/32 -p tcp -m tcp --dport 22 -m comment --comment "1022T (reflection)" -j zone_lan_dest_ACCEPT
-A zone_lan_forward -s 192.168.1.0/24 -d 192.168.1.1/32 -p tcp -m tcp --dport 443 -m comment --comment "1443T (reflection)" -j zone_lan_dest_ACCEPT

-A zone_wan_forward -d 192.168.1.1/32 -p tcp -m tcp --dport 22 -m comment --comment "1022T" -j ACCEPT
-A zone_wan_forward -d 192.168.1.1/32 -p tcp -m tcp --dport 443 -m comment --comment "1443T" -j ACCEPT

I assume this isn't the intended purpose, because these rules make no sense and I also have to create additional "Traffic Rules" to access the router remotely.

Post the exact rules in /etc/config/firewall.

r37529:

root@wndr3700:/etc/config# cat firewall

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fe80::/10'
        option src_port '547'
        option dest_ip 'fe80::/10'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config include
        option path '/etc/firewall.user'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp'
        option src_dport '443'
        option dest_ip '192.168.1.10'
        option dest_port '443'
        option name '443T'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp'
        option src_dport '1022'
        option dest_ip '192.168.1.1'
        option dest_port '22'
        option name '1022T'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp'
        option src_dport '1443'
        option dest_ip '192.168.1.1'
        option dest_port '443'
        option name '1443T'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp'
        option src_dport '10022'
        option dest_ip '192.168.1.10'
        option dest_port '22'
        option name '10022T'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp'
        option src_dport '10443'
        option dest_ip '192.168.1.10'
        option dest_port '443'
        option name '10443T'

config rule
        option target 'ACCEPT'
        option src 'wan'
        option proto 'tcp'
        option name 'Manage-This-Router'
        option family 'ipv4'
        option dest_ip '192.168.1.1'
        option dest_port '22 443'

config include 'miniupnpd'
        option type 'script'
        option path '/usr/share/miniupnpd/firewall.include'
        option family 'IPv4'
        option reload '1'

(Last edited by chromatid on 29 Jul 2013, 03:14)

Well, remove the "option dest" from the redirects pointing at the router itself.

Not working. After removing it from one "redirect", it complains

And I would hope the unnecessary (steps) could be kept unnecessary. I appreciate your great job.

Is 192.168.1.1 configured anywhere in uci?
For me your rules work just fine (10.11.12.13 is my router lan ip)

config redirect
    option target 'DNAT'
    option src 'wan'
    option dest 'lan'
    option proto 'tcp'
    option src_dport '1443'
    option dest_port '443'
    option name '1443T'
    option dest_ip '10.11.12.13'

root@uplink:~# fw3 print | grep 1443T
Warning: Section @redirect[5] (1443T) refers to a destination address on this router, assuming port redirection
iptables -t filter -A zone_wan_input -p tcp -d 10.11.12.13/32 -m tcp --dport 443 -m conntrack --ctstate DNAT -m comment --comment 1443T -j ACCEPT
iptables -t filter -A zone_lan_forward -p tcp -s 10.11.12.0/24 -d 10.11.12.13/32 -m tcp --dport 443 -m comment --comment "1443T (reflection)" -j zone_lan_dest_ACCEPT
iptables -t nat -A zone_wan_prerouting -p tcp -m tcp --dport 1443 -m comment --comment 1443T -j DNAT --to-destination 10.11.12.13:443
iptables -t nat -A zone_lan_prerouting -p tcp -s 10.11.12.0/24 -d 146.52.137.175/32 -m tcp --dport 1443 -m comment --comment "1443T (reflection)" -j DNAT --to-destination 10.11.12.13:443
iptables -t nat -A zone_lan_postrouting -p tcp -s 10.11.12.0/24 -d 10.11.12.13/32 -m tcp --dport 443 -m comment --comment "1443T (reflection)" -j SNAT --to-source 10.11.12.13

what release are we talking about? trunk or attitude?
I am afraid nobody will guaranty working trunk. cause similar rules are working for me in attitude.

(Last edited by mmhorda on 29 Jul 2013, 20:46)

192.168.1.1 is the default router IP. It's fine for me, so I never changed it in any way.

@mmhorda, all the versions are AA.

the same with me

My build has the standard wifi drivers, so there is nothing build-specific.

There have been quite a lot of wifi driver changes in July and some patches has been applied in the last few days. Hopefully those will correct your problems.

Trunk: http://nbd.name/gitweb.cgi?p=openwrt.gi … 11;hb=HEAD
AA12.09: http://nbd.name/gitweb.cgi?p=attitude_a … 11;hb=HEAD

My current trunk build already has all the patches, and I will probably update the AA12.09 build today.

If the problems continue, you might check the bug tracker for similar problems or write on an own thread about it, as I highly doubt if the devs modifying the wifi driver ever read this build-specific thread.

EDIT:
AA r37743 build is now available.
Trunk r37745 is now available.

(Last edited by hnyman on 10 Aug 2013, 08:44)

I am not sure if you already added these in but I have 1 suggestion for sysctl.conf
This line
net.ipv4.tcp_slow_start_after_idle=0
I noticed that during jperf testing the graph always show a slow start tcp.
When I added that line the slow start behaviour dissappear.
Not sure this is by design but that line fixed it.
The default value of this sysctl is 1

(Last edited by alphasparc on 14 Aug 2013, 16:06)

Does that actually affect routed traffic? TCP window sizes are negotiated between sender and recipient (PC and web server). As far as I know, routers, even in NAT mode does not change TCP window sizes unless it was a "man in the middle" attack.

- r37792: fix for button hotplug actions taking 100% CPU

Button hotplug scripts taking 100% CPU was fixed today by r37792, or actually changes made to procd (http://nbd.name/gitweb.cgi?p=luci2/proc … a9b0899517 ).

(Last edited by hnyman on 15 Aug 2013, 15:23)

Hi guys,

Can anyone tell me what linux kernel is being used with r37815?

Apparently 2.6.34 kernel and above have IGMP snooping built in.

Thanks

Both of my builds have the default kernels:
Trunk has 3.10.4

And the AA 12.09 build has kernel 3.3.8.

Sorry hnyman, trying to get my head around this....

So when people refer to the kernel, 2.6.34, 3.10.4 is a higher version of the same thing?

I know your build is running 3.10.4 so hopefully IGMP snooping is supported - something to play with when i get home.

Just wanted to make sure i had the right kernel version and wasn't sure whether there was an internal linux kernel version as well as an OpenWRT version.

Thanks for clearing that up buddy.

Edit: I can't believe my stupidity sometimes...... Just realised i was comparing the OpenWRT version, such as 10.03, the kernel version, 3.10.4.

What an idiot!!!

(Last edited by Wriggerz on 21 Aug 2013, 17:28)

I can confirm that problem with a Nokia N9. There are now some reverting patches in the ticket ticket now. As I don't have the possibility at the moment to set up my own build environment I would like to ask politely if either dannukjgs or ferob can maybe test it as described in the ticket's comment? Or maybe hnyman can do the test builds? FYI I'm using the Attitude Adjustment builds on a WNDR3800.
Thanks and sorry for not testing it myself.

I have created test versions for Attitude Adjustment.
You have to replace the file /lib/modules/3.3.8/ath9k.ko in the live system with the test versions and test after rebooting.
http://koti.welho.com/hnyman1/Openwrt/a … th9k_test/
The directory contains four versions of ath9k.ko: the original and three test versions, whose names show which patches are included.

There have been no significant check-ins in Attitude, so the August 18th build itself is still valid.

In addition to #14092, see also discussion at #14097:
https://dev.openwrt.org/ticket/14097#comment:8
Most probably both tickets are about the same issue and it is related to "n" mode...

(Last edited by hnyman on 1 Sep 2013, 11:13)

Thank you very much for the test builds!
I've thoroughly tested all three combinations and the only working one is 900_901_902.

The problematic wifi tx queue changes have been removed from AA by r37920. So my current r37920 AA build should probably work better, hopefully.
https://dev.openwrt.org/changeset/37920 or
http://nbd.name/gitweb.cgi?p=attitude_a … c2a240227b

Thanks. Would you be able to make a build with channels 12 and 13 activable?
I live in Europe and here they are available for wifi.

There was a fix that used to work with AA rc1, but doesn't work with final, for some reason.
https://dev.openwrt.org/ticket/9678#comment:19

Send me a PM if you can.

(Last edited by Deroute on 15 Sep 2013, 11:24)

Channel availability is based on the wi-fi radio's country code selection. 12 and 13 will available for countries like Italy or France for example. Review this file and pick the country code with frequency that ends "2482".

https://dev.openwrt.org/browser/branche … /regdb.txt

Ok, because in standard AA final they were blocked even changing the country.
Also, the max wifi power admissible in Europe is double the US one.
And also that was blocked in standard release.

They say it's because the bootloader ignores their settings, adn they can't legally override it (even if it's a bug), or something like that.
The producers override it anyway because they have a a special agreement with the chipmaker and so on.

If it works straight out of the box in your distro, then I'm more than happy.

You are asking a question in a thread for hnyman's custom build, not the "standard" build. So default assumption is that you're using one of his builds on the Netgear router. If you look at his build, he has enabled country code swtiching feature "CONFIG_ATH_USER_REGD=y" in the config file for his builds:

http://koti.welho.com/hnyman1/Openwrt/a … 708.config

Oh my God. It works!
Everything WORKS!!!

The wifi works and I have my extra EU channels.

The WAN works and it's bridged to ethernet.
I can talk to my router on 192.168.1.1 without any conflicts with the main network! [Right?]
Before I had to use the first eth hole as WAN and the second as my first ethernet hole.

Oh, and the wifi button is working better than ever (no extra long presses needed).

Good work, fantastic distro!

(Last edited by Deroute on 17 Sep 2013, 20:21)