Hello,
I have also the 500gp and I have the same problem ... I'm right now compiling the dev version to see if it will solve the problem.

Since I would also like to open the ssh access to my openwrt from the internet, I uncommented the following lines in the/etc/firewall.user file:

iptables -t nat -A prerouting_wan -p tcp --dport 22 -j ACCEPT
iptables        -A input_wan      -p tcp --dport 22 -j ACCEPT

But this has also no effect. Can you confirm this ?

Edit: I tried this trick to forward a port as shown here https://dev.openwrt.org/ticket/2558

iptables -t nat -A prerouting_wan -p tcp --dport 4800 -j DNAT --to 192.168.1.10
iptables          -A forwarding_wan -p tcp --dport 4800 -d 192.168.1.10 -j ACCEPT

I of course adapted it to my network but this also doesn't work !

Regards,
Tex

(Last edited by Tex-Twil on 14 Feb 2008, 16:53)

Hello,
this is getting me crazy. I really can get the ports open on the internet even if this workaround is supposed to work : https://dev.openwrt.org/ticket/2558  !! Could someone help me to find out what am I doing wrong ?

This issue makes my router totally useless

edit: Switching back to White Russian sovled my problems

Thanks,
Tex

(Last edited by Tex-Twil on 17 Feb 2008, 13:48)

Anybody knows, is it fixed development version from git?

Eug asked me by email this question:

I use the lastest stable version :

$ cat /etc/banner
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 WHITE RUSSIAN (0.9) -------------------------------
  * 2 oz Vodka   Mix the Vodka and Kahlua together
  * 1 oz Kahlua  over ice, then float the cream or
  * 1/2oz cream  milk on the top.
 ---------------------------------------------------

cheeers.

Any news on this issue? I think it should be a priority fix.

switching to Kamikaze 7.09 with kernel 2.6 (instead of 2.4) fixes this issue for me (linksys wrt54).

Folks,

I'm testing this problem on Kamikaze 7.09 (2.4 kernel).  After some effort to remove the variables, it appears that it is QoS-scripts causing the fault.  I'm yet to say this with certainty though, but I should know within a few days.

I'm in the process of testing this as well.  I haven't tested removing QOS.  I'm currently testing a patch I made to remove certain netfilter extensions from kamikaze 2.4.  We can cover more ground by updating this thread, I'll report back as well...

I doubt it's the QoS scripts. I don't use them, and I've had this problem as well.

(Last edited by placebo on 9 Jun 2008, 04:19)

Hmm, interesting.  Are you sure you have absolutely no queuing configured, even though qos-scripts isn't being used?

I was running PacketProtector 2.5 (based off Kamikaze 7.09) and the problem never occurred, however Qos-scripts was broken.  I moved back to Kamikaze to get QoS functionality back and that is when the problem started for me.   I've since disabled QoS and the problem has not occurred again in four days, even with some hefty downloads.

I have a test router which is showing promise, 15 days with correct port forwarding.  I have removed all of the netfilter modules I'm not using.  Perhaps someone else would like to test what I have done...

I compiled kamikaze 2.4 with the following netfilter modules removed:

  rm target/linux/generic-2.4/patches/603-netfilter_nat_pptp.patch
  rm target/linux/generic-2.4/patches/606-netfilter_NETMAP.patch
  rm target/linux/generic-2.4/patches/608-netfilter_ipset.patch
  rm target/linux/generic-2.4/patches/609-netfilter_string.patch
  rm target/linux/generic-2.4/patches/611-netfilter_condition.patch
  rm target/linux/generic-2.4/patches/612-netfilter_quota.patch
  rm target/linux/generic-2.4/patches/613-netfilter_nat_h323.patch
  rm target/linux/generic-2.4/patches/614-netfilter_nat_rtsp.patch
  rm target/linux/generic-2.4/patches/615-netfilter_nat_mms.patch
  rm target/linux/generic-2.4/patches/617-netfilter_time.patch
  rm target/linux/generic-2.4/patches/620-netfilter_iprange.patch
  rm target/linux/generic-2.4/patches/621-netfilter_random.patch
  rm target/linux/generic-2.4/patches/622-netfilter_ipset_porthash.patch
  rm target/linux/generic-2.4/patches/623-netfilter_ip6t_reject.patch

Now, after removing those files, it takes a bit of work to get things compiling again.  I have some patches, but they might not apply cleanly for you.   You might have to work these out by hand...

diff -urN package.old/kernel/modules/netfilter.mk package/kernel/modules/netfilter.mk
--- package.old/kernel/modules/netfilter.mk    2008-05-19 14:55:29.000000000 -0400
+++ package/kernel/modules/netfilter.mk    2008-05-19 14:56:18.000000000 -0400
@@ -206,6 +206,7 @@
 define KernelPackage/ipt-iprange
   SUBMENU:=$(NF_MENU)
   TITLE:=Module for matching ip ranges
+  DEPENDS:=@LINUX_2_6
   FILES:=$(foreach mod,$(IPT_IPRANGE-m),$(LINUX_DIR)/net/$(mod).$(LINUX_KMOD_SUFFIX))
   AUTOLOAD:=$(call AutoLoad,40,$(notdir $(IPT_IPRANGE-m)))
 endef
@@ -221,6 +222,7 @@
   SUBMENU:=$(NF_MENU)
   TITLE:=IPSET Modules
   KCONFIG:=$(KCONFIG_IPT_IPSET)
+  DEPENDS:=@LINUX_2_6
   FILES:=$(foreach mod,$(IPT_IPSET-m),$(LINUX_DIR)/net/$(mod).$(LINUX_KMOD_SUFFIX))
   AUTOLOAD:=$(call AutoLoad,40,$(notdir $(IPT_IPSET-m)))
 endef

diff -urN target.old/linux/generic-2.4/patches/610-netfilter_connbytes.patch target/linux/generic-2.4/patches/610-netfilter_connbytes.patch
--- target.old/linux/generic-2.4/patches/610-netfilter_connbytes.patch    2008-05-19 14:40:13.000000000 -0400
+++ target/linux/generic-2.4/patches/610-netfilter_connbytes.patch    2008-05-19 14:52:05.000000000 -0400
@@ -1,16 +1,3 @@
-Index: linux-2.4.35.4/net/ipv4/netfilter/Config.in
-===================================================================
---- linux-2.4.35.4.orig/net/ipv4/netfilter/Config.in
-+++ linux-2.4.35.4/net/ipv4/netfilter/Config.in
-@@ -11,6 +11,8 @@ if [ "$CONFIG_IP_NF_CONNTRACK" != "n" ];
-   dep_tristate '  Amanda protocol support' CONFIG_IP_NF_AMANDA $CONFIG_IP_NF_CONNTRACK
-   dep_tristate '  TFTP protocol support' CONFIG_IP_NF_TFTP $CONFIG_IP_NF_CONNTRACK
-   dep_tristate '  IRC protocol support' CONFIG_IP_NF_IRC $CONFIG_IP_NF_CONNTRACK
-+  dep_tristate '  Connection tracking flow accounting' CONFIG_IP_NF_CT_ACCT $CONFIG_IP_NF_CONNTRACK
-+  dep_tristate '  Connection byte counter support' CONFIG_IP_NF_MATCH_CONNBYTES $CONFIG_IP_NF_CT_ACCT $CONFIG_IP_NF_CONNTRACK $CONFIG_IP_NF_IPTABLES
-   dep_tristate '  GRE protocol support' CONFIG_IP_NF_CT_PROTO_GRE $CONFIG_IP_NF_CONNTRACK
-   dep_tristate '   PPTP protocol support' CONFIG_IP_NF_PPTP $CONFIG_IP_NF_CT_PROTO_GRE
- fi
 Index: linux-2.4.35.4/net/ipv4/netfilter/Makefile
 ===================================================================
 --- linux-2.4.35.4.orig/net/ipv4/netfilter/Makefile
@@ -439,27 +426,15 @@
 +};
 +
 +#endif
-Index: linux-2.4.35.4/net/ipv4/netfilter/ip_conntrack_proto_gre.c
-===================================================================
---- linux-2.4.35.4.orig/net/ipv4/netfilter/ip_conntrack_proto_gre.c
-+++ linux-2.4.35.4/net/ipv4/netfilter/ip_conntrack_proto_gre.c
-@@ -237,16 +237,16 @@ static unsigned int gre_print_conntrack(
- /* Returns verdict for packet, and may modify conntrack */
- static int gre_packet(struct ip_conntrack *ct,
-               struct iphdr *iph, size_t len,
--              enum ip_conntrack_info conntrackinfo)
-+              enum ip_conntrack_info ctinfo)
- {
-     /* If we've seen traffic both ways, this is a GRE connection.
-      * Extend timeout. */
-     if (ct->status & IPS_SEEN_REPLY) {
--        ip_ct_refresh_acct(ct, ct->proto.gre.stream_timeout);
-+        ip_ct_refresh_acct(ct, ctinfo, iph, ct->proto.gre.stream_timeout);
-         /* Also, more likely to be important, and not a probe. */
-         set_bit(IPS_ASSURED_BIT, &ct->status);
-     } else
--        ip_ct_refresh_acct(ct, ct->proto.gre.timeout);
-+        ip_ct_refresh_acct(ct, ctinfo, iph, ct->proto.gre.timeout);
-     
-     return NF_ACCEPT;
- }
+diff -urN linux-2.4.35.4.old/net/ipv4/netfilter/Config.in linux-2.4.35.4/net/ipv4/netfilter/Config.in
+--- linux-2.4.35.4.old/net/ipv4/netfilter/Config.in   2008-05-16 09:51:20.000000000 -0400
++++ linux-2.4.35.4/net/ipv4/netfilter/Config.in       2008-05-16 09:52:55.000000000 -0400
+@@ -11,6 +11,8 @@
+   dep_tristate '  Amanda protocol support' CONFIG_IP_NF_AMANDA $CONFIG_IP_NF_CONNTRACK
+   dep_tristate '  TFTP protocol support' CONFIG_IP_NF_TFTP $CONFIG_IP_NF_CONNTRACK
+   dep_tristate '  IRC protocol support' CONFIG_IP_NF_IRC $CONFIG_IP_NF_CONNTRACK
++  dep_tristate '  Connection tracking flow accounting' CONFIG_IP_NF_CT_ACCT $CONFIG_IP_NF_CONNTRACK
++  dep_tristate '  Connection byte counter support' CONFIG_IP_NF_MATCH_CONNBYTES $CONFIG_IP_NF_CT_ACCT $CONFIG_IP_NF_CONNTRACK $CONFIG_IP_NF_IPTABLES
+ fi
+
+ if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then

Is there any queueing configured by default? I'm running a fairly stock version of Kamikaze.

No, there's no queuing by default.

My system ran for a week with no issues, and I enabled QoS again about three days ago.  Port redirection is still working, so I'm now having to doubt my initial assessments.

There is ONE other thing I've done though during this process which might be affecting it:  I enabled swap space on a USB stick.

I think the only thing I can do for now is sit back and basically use the router until the problem occurs again.  I need to run some packet tracing at that point in time to see if my internal servers are getting packets on random ports, as other folks have described.

Hey folks,

The router has been up for 13 days now with no failures.  During this uptime I have disabled and enabled QoS without a restart.

I will now reboot the router with QoS enabled and give it a few more days to see if the problem occurs.   Once again, I can only say that using a swapfile is the only change I believe I have made.

I recently thought trunk had fixed this problem, the router was up for 2 months, then it stopped forwarding.  Its hard to debug a problem thats not easy to reproduce...

Hmmm.  If it's up for two months and then fails, it has to be some form of resource exhaustion.  What is needed therefore is a quick diagnostics script to gather all of the relevant details.

I'll have a think about what should be grabbed and put one together this weekend, and I'll publish the script in this thread.

What happened with your netfilter patches? I assume you did that on a different router since your previous post suggests that one would have been up for a month now.

So far, the router with the patches is working.  I only have it installed in one location though, I dont have any other router which uses port forwarding...

I'm running X-wrt snapshots (r11520) and have this same problem. I don't have QoS enabled. I get maybe 2 days of forwarding before I have to reboot.

I look forward to the diagnostic script when it is available, I'll be glad to run it here. Please let me know if there is any other info that would be useful in diagnosing this.

This is a very simple script that will gather the really high level stuff that I'm wanting to take a look at the next time mine has a problem:

#!/bin/sh

iptables -L -n -t filter -vv > /tmp/diag_iptables_filter
iptables -L -n -t nat -vv > /tmp/diag_iptables_nat
iptables -L -n -t mangle -vv > /tmp/diag_iptables_mangle
cat /proc/meminfo > /tmp/diag_meminfo
cat /proc/net/ip_conntrack > /tmp/diag_ip_conntrack
cat /proc/net/ip_conntrack | wc -l > /tmp/diag_active_connections
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max > /tmp/diag_max_connections
lsmod > /tmp/diag_lsmod
cat /etc/firewall.user > /tmp/diag_firewall.user
uptime > /tmp/diag_uptime
tar zcvf /tmp/portfw_diag_`date -I`.tgz /tmp/diag_*

You could merely paste the above into a shell prompt or save them to a file and keep it handy.  Either way the result is a file located in the /tmp folder called "portfw_diag_<date>.tgz".  The script should be run when the problem is happening, not after rebooting of course.

After this I'm going to knock up a short script to enable some detailed Firewall logging so that we can see what IPTables is doing as a connection attempt is made.    Ultimately I think this is a resource exhaustion problem, but the question is which resource.

(Last edited by kaldek on 3 Jul 2008, 02:03)

Thanks for this script. I tried running it last night, but when I tried to scp the tgz file back to my desktop I ran into the same issue -- my ssh/scp port, which is one of those I forward, was not accessible from my router. Since this was not being forwarded but was being used locally on the router, this may not be a port forwarding issue per se.

I rebooted so I could copy the file over, but unfortunately I forgot to copy it out of the /tmp fs first. 8-O I'll re-run this in a day or two when the problem manifests again.

Think it might be related to the off-by-one bug? https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/2570 and http://forum.openwrt.org/viewtopic.php?id=12165

I'm not entirely convinced that it's a netfilter bug. Port forwarding was fine years ago when I last used 2.4 and was working fine on 2.6 until I switched to OpenWrt and a WRT54GL. I'd try 2.6 again, but I need wireless. sumpfralle mentioned earlier 2.6 fixes port forwarding for him, not sure if his problems were due to the off-by-one thing. I added logging into the prerouting and forward chains, and it confirms the presence of the bug in 7.09. Here's the rules I threw in to replicate the bug:

iptables -t nat -A prerouting_wan -p tcp --dport 25002 -j LOG --log-prefix "PREROUTING: "                          
iptables -t nat -A prerouting_wan -p tcp --dport 25002 -j DNAT --to <LAN IP>:25002                       
iptables        -A forwarding_wan -p tcp -j LOG --log-prefix "FORWARD: "                                     
iptables        -A forwarding_wan -p tcp --dport 25002 -j LOG --log-prefix "TEST2: "                         
iptables        -A forwarding_wan -p tcp --dport 25002 -d <LAN IP> -j ACCEPT

This is the result:

Jul  3 10:45:30 Openwrt user.warn kernel: PREROUTING: IN=eth0.1 OUT= MAC=<MAC> SRC=<SRC> DST=<Openwrt> LEN=60 TOS=0x00 PREC=0x20 TTL=46 ID=36889 DF PROTO=TCP SPT=41892 DPT=25002 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0 
Jul  3 10:45:30 Openwrt user.warn kernel: FORWARD: IN=eth0.1 OUT=br-lan SRC=<SRC> DST=<LAN IP> LEN=60 TOS=0x00 PREC=0x20 TTL=45 ID=36889 DF PROTO=TCP SPT=41892 DPT=25003 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0

Note that DPT goes from 25002 in the prerouting chain to 25003 in the forward chain and the TEST2 log rule is never hit. Of course, 8.08 was announced recently, maybe it's fixed in that?

I've been running nightly snapshots and updated to the snapshot as of Monday. It's not fixed in that, so I don't know if a fix will be available in 8.08.

Thanks for pointing this out. I will test the off-by-one behavior after the long weekend. 2.6 is not an option as I am running on a WRT54GL and need wireless.

Neither am I.  However, some live testing when the problem occurs will help here.

There are some folks experience this right now, so I'm going to knock up a script which does the following:

- Accepts the published port and the real port as arguments
- Sniffs the external interface and internal interface for the ports supplied in the arguments (using tcpdump)
- Stores the output to dump files in /tmp

With the script running, a few attempts to get through the router can be made, and we will then see if the ports are being forwarded but off by one.  The script can then terminate (I may do this as a separate script which just does a killall on all tcpdump processes).

P.S.  I should add that the tcpdump check is important, because response packets to an off-by-one error would likely have the TCP "RESET" flag set and won't make it through the Firewall at the other end, nor be accepted by the client PC.  OpenWRT by default does allow unsolicited outbound packets at least, making this test a little easier.

(Last edited by kaldek on 4 Jul 2008, 01:51)

If you are interested, I'll post one of my hacked images.  Perhaps it will fix your router, but if not we'll know its not a problem with the modules I removed...

EDIT: http://www.psyc.vt.edu/openwrt/openwrt- … uashfs.trx

(Last edited by netprince on 4 Jul 2008, 02:39)