I am running RC5 on my WRT54Gv2, with PPPoE and qos-scripts 0.9.1-1. Wifi is disabled for now.

When I connect to a tracker, it lists me as "Not Connectable", even though ShieldsUP! tells me that the port is open. µTorrent's own test says that the port is "open and accepting connections". I have disabled zonealarm and the windows firewall on my machine. Configuration is default other than that I have added the following line to my /etc/config/firewall file:

forward:dport=45672:192.168.1.111:45672

Does this forward both TCP *AND* UDP connections? I am wondering if this may be the problem, or if OpenWRT does not meet the specifications, like many routers, of being "P2P friendly". More info on this specification:

http://www.grc.com/sn/SN-042.htm

Please help!

Just to ensure OpenWrt is P2P friendly here ... no qos enable atm ... no bittorrent protocol atm ... The nat table is bigger than many other routers.

Look at /etc/firewall.user instead. OpenWRT uses iptables which is a linux standard... Therefore the device is easily "P2P friendly".

Search the forums for help with iptables, there are plenty of examples.

-jt

(Last edited by johnnytaco on 22 Jun 2006, 06:28)

I changed the following setting in my /etc/config/qos file:

config interface wan
        option classgroup  "Default"
        option enabled      0                           <-- this means disabled, right?
        option upload       512
        option download     2048

...but I'm still getting "Connectable: NO" from the bitmetv.org tracker, which I've never had a problem with before. Do I need to change something in firewall.user? I'm familiar with what iptables is, but not really experienced enough to rewrite something to fix this problem...

"I think all of the open source NATs do this correctly."     -- Steve Gibson

Maybe what Steve meant to say was "...if you can rewrite iptables to make it do so?"... I hope not!

I'm running various VoIP-test programs (like this one) that are supposed to give advises about the NAT type and it's traversal.
I get reports "Port Restricted Cone NAT" and verdicts "No VoIP possible".

"Port restricted Cone" is not the most desirable NAT type it seems...

Actually, if STUN is used I am able to VoIP.

I wonder if it is possible to negotiate OpenWRT to be more p2p-friendly...

(Last edited by booBot on 22 Jun 2006, 14:12)

Did you read the Wiki?

Yes you need a forward line in there to your P2P host. Since you have left out WHAT specific P2P app you are using, it's difficult to say in detail. Above and beyond whether you feel comfortable with iptables or not, you don't seem to have grasped the basic technology, that in order to be "connectable" from outside you need to have a port forwarded from the WAN to your internal host.

As an example here's all I had to add to mine:

### Port forwarding
## -- This forwards port 49152 on the WAN to port 49152 on 10.70.1.21
iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 49152 -j DNAT --to 10.70.1.21:49152
iptables        -A forwarding_rule -i $WAN -p tcp --dport 49152 -d 10.70.1.21 -j ACCEPT

My internal P2P host is on a fixed IP of course.

If you don't want to use the command-line and learn iptables then OpenWRT may not be the best firmware for you.  I'm not being rude here just practical, there are other firmware that build on OpenWRT and make it more n00b-friendly.  I use DD-WRT in many applications and while not as flexible as OpenWRT it's got a nice PhD interface. (PhD=Push here Dummy). OpenWRT may catch up on the GUI front eventually but that's not really it's focus at this time. A solid and stable OS is.

Many people use uPNP (retch!) as a solution to this sort of problem. It's supposed to automagically solve all such problems for you. Well when it works and it's not breaking something else. I usually just set up my own forwards because I don't trust uPNP.

(Last edited by vincentfox on 22 Jun 2006, 21:53)

The /etc/config/firewall file is enough to enable port forwarding/nat correctly.

sunsetview has right that forward:dport=45672:192.168.1.111:45672 is not working propetly.
use forward:dport=45672:192.168.1.111 insteed if you don't wanna to change destination port.
In my opinion option forward:dport=port_A:dest_IP:port_B dont' work, only forward:dport=port:dest_IP

I'd rather tryed to make OpenWRT to be reported as "Full Cone NAT".
How to achieve this?

If you have more  than one computer on your network, "Full Cone NAT" is not for you.

I don't know why people are making up new terms for NAT techniques. What they mean is a 1 to 1 translation where all traffic is directed to a single computer.

This is very simple. All we need to know is what ports your application needs directed to your computer and the address of your computer, and all will be well. For that computer.

Why people write NAT-unfriendly apps in this day and age is beyond me. I mean it's one thing for a P2P system like bittorrent just plain needing one port and one range forwarded for optimal performance, that's no big deal. But to just report "No VoIP Possible" and grump at the user? I'd throw that one back.

Just an unrelated note about p2p friendliness.. This is for all the linux n00bs out there, as I was (and am) when I first got into embedded development.

By default, OpenWrt (as of White Russian RC5 and latest Kamikaze build) defaults to tracking established TCP/IP idle connections for 5 days. This is the standard in the *nix world. However, when you 'abort' an established connection without properly closing it (as can happen sometimes, especially for p2p users), the connection remains established. Therefore, these connections remain tracked until they finally timeout in 5 days. If enough of them get 'stuck' in this state, the conntrack table (size 5953 by default) can fill up.

This is the problem referred to by uTorrent FAQ and others on the original Linksys firmware. It's not really a bug, nor is it that inappropriate. However, it is a good idea to decreae this range as the vast majority of people don't have established connections that remain entirely idle for 5 days.

To fix this problem, add this line to /proc/sysctl.conf like so:

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=3600

This example sets the timeout to 1 hour (3600 seconds). You may want to make it something like 12 or 24 hours.

Why not default to 5 days? Defaulting to less than 5 days should probably be done by 'user friendly' firmwares build on OpenWrt, but not by OpenWrt itself.

The 5953 default size of the conntrack table probably shouldn't be messed with. You don't need more simultaneous connections than this and changing it needs to be done right, else you'll mess up the hash table performance.

(Last edited by db90h on 23 Jun 2006, 19:02)

Thats that I thought, despite vincentfox's comments. I did in fact read the wiki, which says:

So I assumed that I could do everthing in /etc/config/qos and /etc/config/firewall.

db90h's comments are also really helpful. THANKS!

Unfortunately I haven't managed to fix my problem. So I switched back to my Netgear router, used the same configuration and things wouldn't work either! But if I turn uPNP on then it works. So there must be some other port that I need open, but I can't understand why that would be necessary for the tracker. There's also 22 pages of people trying to get connectability working on bitmetv in their forums, and I haven't had time to go through all of that. So right now its looking like bitmetv has something special is going on, although without a "NAT check" program available anywhere on the net, its not possible to really test OpenWRT.

THANKS ALL FOR YOUR HELP!.... I'll update this thread again soon

I use forward:dport=port_A:dest_IP:port_B (where port_A=port_B for me) and works fine here (I havn't try bitorrent protocol, but with ed2k, kademlia it's okay)
I use firewall.user just for PPTP VPN Server.

Sonic did you try "forward:port_A:dest_IP:port_B" when port_A is diffrent from port_B??

I have used bitmetv in the past. Using u-Torrent program, configured to port 49152. BitmeTV is particular about what client software you can use and how you use it. If you do things wrong, they will kick you off their site, they have zero patience. If you don't keep your ratio up or any of a number of other infractions, they will ban you. It's not a very friendly site if you are struggling with technology problems.

With my OpenWRT unit all I had to do was forward port 49152 to the LAN host running u-Torrent.

The u-Torrent software has an option for testing. Look under Options->Speed Guide, there is a button to test if your port is forwarded properly.

Somewhere else in the options is the choice to have the software punch a hole in the Windows XP firewall for port 49152, another step you might have missed. You can also do this manually of course.

(Last edited by vincentfox on 25 Jun 2006, 21:26)

Are you sure that conf-file exists? I can't find it... Seems like a change I could use.

TommyC, you can find it here:  /etc/sysctl.sys

No tested yet, but if that doesn't work perhaps a typo in /usr/lib/common.awk ?

Yo *do* know that the changes are NOT efective inmediately, right? ... after editing /etc/config/firewall , go to /etc/init.d , and execute ./S45firewall

(apart from rebooting, I don't know any other way of reloading the rules if not by running that script ... any help is greatly welcomed)

I have tested and I confirm "forward:port_A:dest_IP:port_B" works without any problems. Of course we must reload the iptables as intrudr says.

Just to make a small correction for people who come across this forum:  Full cone NAT is not the same as all traffic going to a single computer.  The main difference between Full cone NAT and the various restricted NAT types is whether the NAT will forward packets to an internal computer that have a different external host or a different port than the one to which the original packet was sent.

Ex.

My computer on the internal network is 192.168.0.10 .  My external IP is 200.100.50.1 .  My computer sends a packet to 122.133.144.5 at port 7777.

src           sport dst           dport
192.168.0.10  16000 122.133.144.5 7777

NAT changes the packet to be:

src           sport dst           dport
200.100.50.1  30000 122.133.144.5 7777

Let's consider a few response packets:

src            sport dst          dport
122.133.144.6  8888  200.100.50.1 30000

Full cone NAT would forward this response packet to my internal computer even though it comes from a different computer and a different port e.g., 122.133.144.6, port 8888.  Address Restricted NAT and Port Restricted NAT would both drop this packet.

src            sport dst          dport
122.133.144.5  8888  200.100.50.1 30000

Address restricted NAT allows this response packet, but since it comes from a different port 8888, port restricted NAT would drop this packet.

src            sport dst          dport
122.133.144.5  7777  200.100.50.1 30000

Port restricted NAT only allows a packet that comes from the same address and port combination to which the original packet was sent.

I'm still trying to determine how to get iptables to do true full cone NAT on an OpenWRT router, I'll write back if I can determine how.

Hope this helps.

You are right! On the web interface we have to fill "External port'' but not "Internal port" (10.03.1-rc5, Network -> Firewall -> Traffic Redirection -> General Settings), nor add anything on "Advanced Settings" beyond the DNAT redirection type.

uTorrent is able to receiving incoming connections now.

ty