Hi,

i'm using rc3 jffs2 and did a clean install on my wrt54gs. i'm having strange behaviours of iptables which i can't explain to myself. maybe you could give me a hint.

The problem is, iptables automatically adds to almost each firewall rule a random source ports range restriction. examples:

iptables -t nat -A prerouting_rule -i ppp0 -p tcp --dport 22 -j DNAT --to 192.168.2.2

the result (see the source-ports range):

Chain prerouting_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           tcp spts:0:832 dpt:22 to:192.168.2.2

If i delete this rule from the Chain and fire up the exact same command as above, the line is reading:

Chain prerouting_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           tcp spts:0:964 dpt:22 to:192.168.2.2

If you specify a --sport or a range with --sports iptables uses their values, only when no source ports specified it behaves like drunken.

Other examples from iptables -L -vn:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    1    56 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
 1217  242K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:0:64 dpts:255:65535 option=!2 flags:0x02/0x02

...

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
   13   672 TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:0:68 dpts:255:65535 flags:0x06/0x02 TCPMSS clamp to PMTU

What the heck is going on? Can someone reproduce this?

The box is running a vanilla rc3 only ntpclient & screen added.

root@OpenWrt:~>ipkg list_installed
base-files - 2 - OpenWrt filesystem structure and scripts
base-files-brcm - 1 - Board/architecture specific files
bridge - 1.0.6-1 - Ethernet bridging tools
busybox - 1.00-2 - Core utilities for embedded Linux systems
dnsmasq - 2.22-2 - A lightweight DNS and DHCP server
dropbear - 0.45-3 - a small SSH 2 server/client designed for small memory environments.
hotplug - 2 - Hotplug script for WDS
ipkg - 0.99.149-2 - lightweight package management system
iptables - 1.3.1-1 - The netfilter firewalling software for IPv4
kernel - 2.4.30-brcm-2 -
kmod-brcm-et - 2.4.30-brcm-2 - Proprietary driver for Broadcom Ethernet chipsets
kmod-brcm-wl - 2.4.30-brcm-2 - Proprietary driver for Broadcom Wireless chipsets
kmod-diag - 2.4.30-brcm-2 - Driver for Router LEDs and Buttons
kmod-ppp - 2.4.30-brcm-2 - PPP support
kmod-pppoe - 2.4.30-brcm-2 - PPP over Ethernet support
kmod-wlcompat - 2.4.30-brcm-3 - Compatibility module for using the Wireless Extension with broadcom's wl
libgcc - 3.4.4-2 - GCC support library
libncurses - 5.2-7 - a terminal handling library and common terminal definitions
mtd - 2 - Tool for modifying the flash chip
ntpclient - 2003_194-1 - NTP client for setting system time from NTP servers.
nvram - 1 - NVRAM utility and libraries for Broadcom hardware
ppp - 2.4.3-6 - a PPP (Point-to-Point Protocol) daemon (with MPPE/MPPC support)
ppp-mod-pppoe - 2.4.3-6 - a PPPoE (PPP over Ethernet) plugin for PPP
screen - 4.0.2-1 - A 'window manager' for the terminal session
uclibc - 0.9.27-2 - Standard C library for embedded Linux systems
wificonf - 4 - Replacement utility for wlconf
wireless-tools - 28.pre7-1 - Tools for setting up WiFi cards using the Wireless Extension
zlib - 1.2.2-2 - an implementation of the deflate compression method (library)
Successfully terminated.

root@OpenWrt:~>lsmod
Module                  Size  Used by    Tainted: P
pppoe                   9384   1
pppox                   1372   1 [pppoe]
ppp_generic            21892   3 [pppoe pppox]
slhc                    6352   0 [ppp_generic]
wlcompat               14688   0 (unused)
wl                    423640   0 (unused)
et                     32064   0 (unused)
diag                    2560   0 (unused)

(Last edited by thermoman on 21 Sep 2005, 19:14)

Sorry, but please post bug reports for RC3 to the sticky thread "White Russian RC3 - Bug Reports" in this subforum.

Thanks.

Hi,

I've just bought a new WRT54GS V1.1 and set it up with RC2 and it shows up the same
strange behavior. I need to allow SSH from WAN and uncommented the two lines from
the /etc/firewall.user script. Sometimes the iptables -L output looks like this:

ACCEPT     tcp  --  anywhere             anywhere            tcp spts:0:65532 dpt:22

or if it's working normal like this:

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:22

The same happens with this line from /etc/init.d/S45firewall:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

which looks like this:

TCPMSS     tcp  --  anywhere             anywhere            tcp spts:0:65532 flags:SYN,RST/SYN TCPMSS clamp to PMTU

or

TCPMSS     tcp  --  anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

Also I have trouble with a simple port forwarding script I use for ARD where I don't specify any -sport
option but sometimes it shows up with spts:0:65532 in the iptables output. Also it's curious that on this
router the link is very unstable ... I often have to reconnect the ARD tool to get a screen refresh and
other unusual behavior.

I got the same setup running on a GS V 1.0 and it does work fine ... it's completly the same setup and
has the same packages installed as on the V 1.1 Router. Also it works without failure for over a month
now, ARD, SSH, everthing is running real fine.

Anyone who found a solution yet or even has an idea what causes this trouble?

.g23

the only solution at this time is to use rc1

Hi,

hm, I don't like to switch back to an older version as a solution. There must be a way to find out or
better to fix this problem I think.

Tomorrow I will get the CVS sources downloaded and try to check out what has changed in the iptables
related sections. Guess it will be hard work also as I am not a very expierienced user of OpenWRT and
until now felt fine with the precompiled versions of OpenWRT. Hope someone of the developer team might
give me some starting points where to look.

I don't exactly know how many users of OpenWRT are affected by this strange behavior of iptables or
notice the problem at all but to me it is very annoying as I also think it's not only the case that iptables
makes unwanted source port settings but also that a of the ip stack / port forwarding capabilities is
scrambled.

As I told on my previous post I have another box with exactly the same setup except its a V1.0 router.
On this box my port forwardings for Apple Remote Desktop works really fine, on the V1.1 router I've
recently setup you have to reconnect nearly every minute ... it's nearly impossible to use it under this
conditions. Also the linespeed on the good ARD connection is much slower but it works ...

I hope that we/I will find out the problem as I think a router with a broken netfilter package isn't worth
much.

Bye
.g23

I have another image that you could try: http://openwrt.inf.fh-brs.de/~nbd/test/

Tried it, even with removed ppp/pppoe and kmod-ppp* Packages and resetted nvram as suggested on irc - it didn't solve the issue.

But thanks for investigating, anyways.

Greetings,
thermoman

Hi,

same for me, didn't change anything...

@thermoman: which version of the router are you using, also a 1.1? and what do you exactly mean by resetting nvram?

.g23

yes, it's a wrt54gs v1.1. resetting nvram variables mean erasing them - the bootprocess of the box will reprogram the nvram with the hardware defaults. see http://openwrt.org/OpenWrtDocs/Troubleshooting (Resetting defaults).

Greetings,
thermoman

any fixes/news/solutions to this problem?

setting --sport 0:65535 when using a dport argument seems to solve the problem for now.
i found out that the problem only occurs after resetting nvram on my ver. 1.1 wrt54gs

i will do further investingations on that issue. first i will reflash the wrt with linksys's original firmware to see if that resets the nvram to values which do not produce this problem.

i have also sent a wrt54gs with the same problem to ndb so that he can reproduce this strange behavior.

I tried the latest build from http://downloads.openwrt.org/people/nbd/whiterussian/ and now it works.

Partyparty.

What? It works with my latest build? I didn't add a fix...

Well, someone has done something somewere

cannot confirm that.

problem is still the same, found out that it matters if you run /etc/init.d&S45firewall or just /etc/firewall.user or run iptables command manually.
the first thing works correct, without generating random spts. the other two generate random spts.

OK. I have something that might fix the iptables weirdness. Seems like the problem is related to the high-network-load crash on WRT54G v2.2 and WRT54GS v1.1.

WARNING: This script may contain bugs, may not work at all or may even brick your router
Here's the script: http://openwrt.inf.fh-brs.de/~nbd/linksys-fixup.sh
Run it, then do nvram commit and reboot your router

And, with nbd's excellent script, it works even better.

(I realized that i was using nvram settings from dd-wrt 23beta)

with this script it works perfectly here! (WRT54GS 1.1)
now I can use shorewall without problems... BIG THX!

Same to me - running the script chaged 3 nvram variables which resulted in properly iptables rules:

-clkfreq=200
+clkfreq=216
-sdram_init=0x000b
-sdram_ncdl=0xff0008
+sdram_init=0x010b
+sdram_ncdl=0x0

Thanks for investigating nbd!

Greetings,
thermoman

Please don't set these nvram variables on every router that seems to have this problem. On some it might just cause the boot loader to enter a reboot loop. Using the script should be safe, since I ported the same checks that Linksys does in their firmware to a shell script.

reporting success with nbds scipt.

Hello nbd,

Wow... the fix is a magic!

Just for my curiosity, could you kindly explain

(1) where these weird port values come from
(2) why changing these values could get the things right

Cheers,
dfman

(Last edited by dfman on 19 Oct 2005, 09:11)

I have no idea. This is a hardware-related problem...

Linksys screwed up the settings for RAM refresh and timings in the boot loader defaults. Setting them manually in NVRAM helps...