Thanks wpte and theMiron. I'll try out your suggestions and report back.
Printable View
Thanks wpte and theMiron. I'll try out your suggestions and report back.
Hi wpte/theMiron
I tried all your suggestions.
Efficient multicast forwarding and WMF are already disabled.
When I run wpte's tool, it is able to map the ports well..
However, when I run the tool suggested by theMiron, it gives following output:
TEST 1 - Operating System Support - PASSED
TEST 2 - SSDP Service Running Check - FAILED
TEST 3 - SSDP Service Automatic Check - FAILED
TEST 4 - UPnPHost Service Running Check - FAILED
TEST 5 - UPnPHost Service Automatic Check - FAILED
TEST 6 - UPnP Framework Firewall Exception Check - PASSED
TEST 7 - Adapter #0 - 192.168.0.7 - PASSED
TEST 8 - Get External IP Address (Result: x.x.x.x) - PASSED
These are all run on my PC. Router is connected directly to my ISP's cable without any modem in between and gets the external IP assigned correctly. Also, I downloaded utorrent and ran that and that is also working fine for adding ports through upnp.
However, the programs that I run on my router itself (e.g. transmission) are not able to open the ports through upnp and the port always shows up as closed. I'm very confused by all these results :(. Unfortunately I'm pretty naive with upnp/nat-pmp etc and couldn't debug anything more. Please let me know if I can provide any more information.
add them (ports) to the vserver or to post-firewall directlyQuote:
Originally Posted by shantanugoel
Yeah, I can do that but I have set transmission to use random ports..I can set it to use fixed port for now and get by this issue but just interested in seeing if the problem can be fixed..Quote:
Originally Posted by theMIROn
Anyways, I did some more searching around and debugging. Used a tool from http://bitlet.org/upnp and it reports no UPnP enabled gateway devices found. Also ran transmission with debug logging mode and saw that UPnpDiscover and UPnP_getValidIGD calls were failing. Searching for this on transmission forums lead me to this ticket https://trac.transmissionbt.com/ticket/3452 where they mention that this problem started happening when they "fixed" their code to use proper return values from UPNP_GetValidIGD. Earlier they were just checking for >1 and now they check specially for 1.
miniupnp says:
so miniupnp is getting confused and returning 3, basically not finding any valid IGD. Searching on miniupnp forums, it is mentioned that this is a router problem, not a miniupnp problem.Quote:
/* UPNP_GetValidIGD() :
* return values :
* 0 = NO IGD found
* 1 = A valid connected IGD has been found
* 2 = A valid IGD has been found but it reported as
* not connected
* 3 = an UPnP device has been found but was not recognized as an IGD
Just thought of providing this information in case you can make some connections :)
please try following (on the router):
1. killall miniupnpd
2. edit /etc/miniupnpd.conf:
search for
and insert lines as following:Code:...
listening_ip=...
...
allow 1024-65535 ... 1024-65535
...
3. miniupnpdCode:...
listening_ip=127.0.0.1
listening_ip=...
...
allow 1024-65535 127.0.0.0/8 1024-65535
allow 1024-65535 ... 1024-65535
...
4. check if it works
just tried this.. didn't work :(Quote:
Originally Posted by theMIROn
Another query: Is it ok to use inotify calls on rtn builds? (since they are built on 2.6 kernel)?
To answer my own question, it works :). I just tried by compiling minidlna with inotify support for wl-500w and then used it with the new firmware and it detected the new files added while it was running :)Quote:
Originally Posted by shantanugoel
I keep getting the message:
and ports entered are not forwarded:(Quote:
miniupnpd[526]: Can't find in which sub network the client is
Sorry, didn't find your original post about problem above. Since which build it appeared?Quote:
Originally Posted by wpte
that was the only post I made about the problem.Quote:
Originally Posted by lly
I'm not quite sure, I just use upnp-nat every now and then and noticed it didn't work:p
shantanugoel (a few posts back) had issues, I remember that before that I had no problems with miniupnpd. after that there's only this update: http://code.google.com/p/wl500g/source/detail?r=3169 as far as I can see in the svnlog.
the configuration seems correct as well:
presentation url is on the same port as my web-admin, that's ok I guess?Quote:
# automagically generated
ext_ifname=vlan2
listening_ip=192.168.2.1/255.255.255.0
port=0
enable_upnp=yes
enable_natpmp=yes
lease_file=/tmp/upnp.leases
secure_mode=no
presentation_url=http://192.168.2.1:8080/
system_uptime=yes
notify_interval=60
clean_ruleset_interval=600
uuid=002618a1-3cfb-0026-18a1-3cfb00000000
model_number=RT-N16
allow 1024-65535 192.168.2.0/24 1024-65535
deny 0-65535 0.0.0.0/0 0-65535
Anyway, I checked it just now, and suprisingly it works:confused: there is no more message about the sub network either...
I didn't change anything either:o
yeah..the issue I had with miniupnpd was that programs running on router itself are not able to open any ports but programs running on my PC can open ports. Using 127.0.0.1 in listening_ip in the configuration didn't solve the problem as well but I noticed that if I run miniupnpd with the listening IP specified on the command line as 127.0.0.1 instead of specifying in config file, then the programs running on the router are able to open ports.
My miniupnpd crashed today...
wel it stayed in a 100% cpu usage loop displaying the messages
over and over again.Quote:
Oct 20 20:12:16 miniupnpd[526]: send(res_buf): Broken pipe
I wasn't able to kill it for some reason:(
I've version 1.9.2.7-rtn-r3422
wpte
100% cpu usage already fixed in r3479 ;) It is a bug inside miniupnpd. I would be glad if someone opened a problem at miniupnpd's forum, I haven't enough time for it.
True root of problem should be investigated, but I can't reproduce this bug myself. Probably, recipient close other end of pipe too early and miniupnpd either don't parse response correctly or it is an hole in workflow...
My bad, I looked over that update:oQuote:
Originally Posted by lly
I've only had it once as well... it's a rare problem I guess...
Looks like a problem with the upnp request parsing, I don't understand why they don't use the intel upnp toolkit (it's a bit bigger in size I guess) since it has been running completely stable here in C here.
I experiment with it to control the QoS rules based on what programs the client PC is running, so that you'll always have optimal rules :D