Hello,

I recently switch my configuration. I have 2 asus wl-500g premium.
They were previously linked with 1 main AP, and the other as a client, and wired PCs on this clients. But there were issues, so I decided to change it. Now, I have a WDS link. it works great, but I don't know why, after about 2-4 days, all my port forwarding stopped working (it's the 3rd time in 2 weeks, and and change my configuration 2 weeks ago).
I didn't have this problem before.

I try restarting /etc/init.d/network, /etc/init.d/dnsmasq, /etc/init.d/firewall, /etc/init.d/qos... without success.
The only way I found to recover my port forwarding is to reboot the main router (the one with firewall, port forwarding, etc).

I need another solution, because it's not very interesting to reboot every day (if I know what is the problem, I could make a cron every night for example, I don't want that cron to reboot my router ! )

Thx

I have the same problem, and i have have researched this a bit. My /etc/config/firewall looks like this:

  forward:proto=tcp dport=116:10.0.0.2:22

The other day, after a few days uptime, the connection was suddenly redirected to port 23. Same
thing happened today, but then it was redirected to port 27. A reboot is the only thing that helps,
but after a while it's back. The problem persists even if i flush the firewall tables, and re-add the
rules with these commands:

  iptables -A forwarding_wan -d 10.0.0.2 -j ACCEPT
  iptables -t nat -A prerouting_wan -p tcp --dport 116 -j DNAT --to 10.0.0.2:22

I think there is something in the DNAT target code.

This is my setup:
  OpenWrt: Kamikaze (7.09)
  Hardware: Linksys WRT54GL Ver 1.1 (i think)
  Kernel: Linux version 2.4.34 (nbd@ds10) (gcc version 3.4.6 (OpenWrt-2.0)) #3 Sun Sep 30 20:33:21 CEST 2007

(Last edited by dstensnes on 28 Nov 2007, 11:21)

How do you see where it is redirected ? you say it's suddently redirected to 23 and not 22.
I'll try this to see if I have the same result.

I have the same issue. Posted a bug report: https://dev.openwrt.org/ticket/2769

Emil

How do you see the log ?
Which log is it ?

Thx

i started tcpdump on my desktop machine, which the connection should be redirected to:
  tcpdump -i eth1 -n 'tcp[13] & 3 != 0 and not src net 10.0.0.0/23'

There i noticed that the new connections, which were redirected to the wrong port, and
i confirmed it by listening on those ports with netcat:
  nc -l -v -p 23

Is there any update on this? I recently posted thinking my problem was isolated but a few people have the same issue. How can i make the router reboot every nite? This is a real issue as the box is my production router and i dont want to have to take it offline.

Thanks,

Chris

well, as noted before; it seems to work when you don't specify the ports. That way it just tries to forward the connection to the same ports on the inside, which seems to work correctly

Hi dstensnes, for me this is a temporal issue, it seems to happen at a random time after 24 hours. I am using the firewall scripts i will delve into that and see if that is specifying the destination port. I havent tested to see if the ports are being redirected to a different port after this initial time period where it is working ok, however the issue does sound very similair to what i have seen so far (i couldnt even ssh into the box this time it went nuts where as before i could and only a few port forwards were affected).

if you enter 'forward:proto=tcp dport=116:10.0.0.2:22' in /etc/config/firewall, it will result in something like this in the NAT table:
  iptables -A prerouting_wan -p tcp -m multiport --dports 116 -j DNAT --to 10.0.0.2

which will just rewrite the address, and send it to 10.0.0.2, but if you specifiy ports with it, it will also try to map the destinationport
to a new destination port, relative to the start of the portrange, which i believe is what causing the problem. Maybe some offset or
something which is not always properly reset, or something like that. Just a wild guess though

Hey all,

I'm experiencing similar problems; ASUS WL-500GP, kamikaze 7.09.

The problem for me appears more readily with the iptables rule:

iptables -t nat -A prerouting_rule -p tcp --dport 80 -s ! 192.168.210.7 -j REDIRECT --to-port 8090

Which under white russian worked fine and never exhibited any problems. This rule now stops working, sometimes almost immediately, sometimes it may take a few days. When inspecting packets, it almost looks like the router just stops forwarding/natting the packets to the required destination. Admittedly I haven't performed a tcpdump at the recieving end and haven't seen the port change as mentioned by others. What I have done has been very brief.

I've also notice my imaps DNAT rule stops too, but the smtp DNAT is still functioning. So it appears to be isolated to individual rules and not something that globally breaks.

No amount of jiggery pokery fixes the issue, a reboot is required. That possibly indicates the kernel is at fault and I'm not sure if I'm willing to test the 2.6 branch yet, I don't believe webif2 has been ported and I think the status is wip for wl-500gp. I might just have to give it a go for the sake of testing.

yes, it seems to be a per-rule problem

Using KAMIKAZE (7.09).

I am very surprised so few people complain about this bug. It severely cripples a very important part of the router.

I tried a quick fix and it seems stable so far.  Edit /usr/lib/common.awk to do single port forwarding instead of multiport. Most people don't use or need multiport anyway. The following awk routine is used by /usr/lib/firewall.awk and gets called from /etc/init.d/firewall. Change it, save it and do a /etc/init.d/firewall reload.

# vi /usr/lib/common.awk

---begin---

function portstr(type, str) {
#       gsub(/-/, ":", str)
#       if (insmod_mport != 1) {
#               print "insmod ipt_multiport >&- 2>&-"
#               insmod_mport = 1
#       }
#       if (type == "src") return " -m multiport --sports " str
#       else return " -m multiport --dports " str
        gsub(/-/, ":", str)
        if (type == "src") return " --sport " str
        else return " --dport " str
}

---end---

You can try running the following command to see how it generates your iptable, it will only print stuff and not actually configure your system:

awk -f /usr/lib/common.awk -f /usr/lib/firewall.awk /etc/config/firewall

I agree. There is probably lots of people around the world, who has been banging their heads in the table over this, before giving up.

I haven't checked but I'm guessing that script relates to config/firewall?

I only use firewall.user due to requirements from previous installs and the lack of motivation to convert. So it's possible the script doesn't effect me.

One thing I did notice though is that this router suffered from the RAM/2 problem (only one out of the two I'm using had this problem - asus wl-500gp).

After modifying nvram and reclaiming the other half of the RAM, I'm yet to experience the problem again, but I'll give it a week or two before I'm sure.

Pixel du Rezo, are you seeing all 32MB of RAM on your wl-500gp?

Yes, the all 32MB is activated, and I also have some swap.

this is not just related to some script. You can run these commands yourself, and still get the same results after a while. As noted earlier, it seems that a reboot is required to fix the problem, suggesting it might be kernel related.

Aaaannnnnd.... its broken again. Okay; So multiport is not the cause of the problem. Dang. The bug has already been reported, now maybe more people can confirm they have this problem. Let's make some noise and get this sucker fixed.

Running Kernel 2.4 Kamikaze (what an appropriate name, it actually does kill itself ;) 7.09 on a WRT54GL v1.1.

-- edit

Yes it indeed does look very much like a kernel/module issue. After a certain time the forwarded port gets increased, or as I saw today, decreased in value. So incoming port 10001 tcp & udp , for example, should be forwarded as 10001, but to a different IP naturally, but after a time the router decides to map the incoming port to 10002 or even higher, or as I saw today, to 9999. It seems the longer you wait , the higher the port number becomes. At least, that is what I experienced. Strange case.

(Last edited by jhalfmoon on 18 Dec 2007, 20:00)

I can confirm that even with a simple redirect it fails daily if not sooner.

I've noticed DNATs dying aswell but it's harder to notice as I'm not monitoring them whereas http hijacking is obvious.

At this point, I would not recommend kamikaze for at least the wl-500gp. If you forward ports at all, it's nearly useless. Everything else runs flawlessly.

Will revert to white russian in the time being.

I have this problem on a wl-500-gp too. I found that not specifying the target port (i.e. use --dport 22 -j DNAT --to 192.168.0.2 instead of --dport 22 -j DNAT --to 192.168.0.2:22) does not seem to trigger the bug for me (running for several weeks now and it still works). So it's only if you actually want to change the port for the local machine, that it messes up with the port numbers for some reason. For me anyway.

Yep, that fixed it for me ... but doesn't really help with the http hijacking and the off-port sshd

Another issue is cropping up too, the wireless has decided to randomly drop out. No wireless nodes are are able to see the network until I reboot the router. I haven't had a chance to have a look from a wired client yet. This has only happened twice in as many weeks.

There's a ticket open:

https://dev.openwrt.org/ticket/2558

Thank you, frostschutz, for the workaround, which works for me, too.

If a target port is specified, say 30,679, it will become any number randomly, given enough traffic. I have seen it going from 6,000+ to 30,000+ on the target host. Mis-allocated and corrupted memory somewhere in the code?

I do have the same Problem on Kamikaze 7.09 - If anybody cares.

Well actually, people do care. It's just that the bugs will not get fixed in the versions they are found in.  Such is the development model of OpenWRT. As as stated in this link, Kamikaze is very much a moving target:

http://forum.openwrt.org/viewtopic.php?id=5487

If you want to see something fixed, then try the latest development version from svn / git:

https://dev.openwrt.org/

Officially, binaries will not be realesed and supported. In reality, binaries do get released, but are still unsupported. So if you want to use Kamikaze, then be prepared to get your hands dirty or stick with White Russian. I myself did not realize this when I switched from WR to Kamikaze. So now I run bleeding edge Kamikaze and it is quite fun. Not fit for production environments though.