Page 40 of 48 FirstFirst ... 303839404142 ... LastLast
Results 586 to 600 of 714

Thread: New oleg firmware version

  1. Thanks wpte and theMiron. I'll try out your suggestions and report back.

  2. 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.

  3. #588
    Quote Originally Posted by shantanugoel View Post
    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 directly

  4. Quote Originally Posted by theMIROn View Post
    add them (ports) to the vserver or to post-firewall directly
    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..

    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:
    /* 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
    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.

    Just thought of providing this information in case you can make some connections

  5. #590
    please try following (on the router):
    1. killall miniupnpd
    2. edit /etc/miniupnpd.conf:
    search for
    Code:
    ...
    listening_ip=...
    ...
    allow 1024-65535 ... 1024-65535
    ...
    and insert lines as following:
    Code:
    ...
    listening_ip=127.0.0.1
    listening_ip=...
    ...
    allow 1024-65535 127.0.0.0/8 1024-65535
    allow 1024-65535 ... 1024-65535
    ...
    3. miniupnpd
    4. check if it works

  6. Quote Originally Posted by theMIROn View Post
    please try following (on the router):
    1. killall miniupnpd
    2. edit /etc/miniupnpd.conf:
    search for
    Code:
    ...
    listening_ip=...
    ...
    allow 1024-65535 ... 1024-65535
    ...
    and insert lines as following:
    Code:
    ...
    listening_ip=127.0.0.1
    listening_ip=...
    ...
    allow 1024-65535 127.0.0.0/8 1024-65535
    allow 1024-65535 ... 1024-65535
    ...
    3. miniupnpd
    4. check if it works
    just tried this.. didn't work

  7. Another query: Is it ok to use inotify calls on rtn builds? (since they are built on 2.6 kernel)?

  8. Quote Originally Posted by shantanugoel View Post
    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

  9. #594
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    I keep getting the message:
    miniupnpd[526]: Can't find in which sub network the client is
    and ports entered are not forwarded

  10. #595
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by wpte View Post
    I keep getting the message:

    and ports entered are not forwarded
    Sorry, didn't find your original post about problem above. Since which build it appeared?

  11. #596
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    Quote Originally Posted by lly View Post
    Sorry, didn't find your original post about problem above. Since which build it appeared?
    that was the only post I made about the problem.

    I'm not quite sure, I just use upnp-nat every now and then and noticed it didn't work

    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:
    # 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
    presentation url is on the same port as my web-admin, that's ok I guess?

    Anyway, I checked it just now, and suprisingly it works there is no more message about the sub network either...
    I didn't change anything either

  12. 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.

  13. #598
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    My miniupnpd crashed today...
    wel it stayed in a 100% cpu usage loop displaying the messages
    Oct 20 20:12:16 miniupnpd[526]: send(res_buf): Broken pipe
    over and over again.
    I wasn't able to kill it for some reason
    I've version 1.9.2.7-rtn-r3422

  14. #599
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    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...

  15. #600
    Join Date
    Dec 2007
    Location
    The Netherlands - Eindhoven
    Posts
    1,767
    Quote Originally Posted by lly View Post
    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
    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

Page 40 of 48 FirstFirst ... 303839404142 ... LastLast

Similar Threads

  1. Probleme mit der Oleg firmware
    By errox in forum German Discussion - Deutsch (DE)
    Replies: 15
    Last Post: 14-06-2008, 23:26
  2. new firmware 1.9.2.7-8 by oleg
    By alien433 in forum WL-500gP Firmware Discussion
    Replies: 31
    Last Post: 24-01-2008, 21:31
  3. Oleg firmware not working.
    By wpte in forum WL-500gP Q&A
    Replies: 6
    Last Post: 07-01-2008, 13:48
  4. C Compiler voor de oleg firmware
    By wouzs in forum Dutch Discussion - Nederlands
    Replies: 1
    Last Post: 28-10-2007, 16:57

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •