1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

UPnP Inactive Rules Cleaning

Discussion in 'Tomato Firmware' started by dmb41crash, Jul 11, 2010.

  1. dmb41crash

    dmb41crash Networkin' Nut Member

    I'm running TeddyBear v1.27.8747 ND Std on a WRT54GL v1.1 with Inactive Rules Cleaning activated. Trouble is, the entries never get deleted automatically. Skype stays around forever, as well as Pidgin, even well after the programs are closed in Windows. Even when the computers in question are completely shut down and/or disconnected from the router for 24 hours or more, the UPnP entries remain.

    Am I misunderstanding how the inactive rules cleaning is supposed to work, by automatically deleting inactive UPnP entries after the indicated period of time, or no?

    For the record, I've already re-flashed the firmware, even doing an NVRAM clear both before and after the flash. The router has been rebooted several times, including a power recycle, to no avail.

    [​IMG]
     
  2. ewmailing

    ewmailing Networkin' Nut Member

    I would like to know the real answer to this too. But I have a few guesses.
    First, the cleaning threshold might be an indicator. Maybe nothing gets cleaned up until after you exceed that number of open ports. So maybe try lowering the threshold to 1 or 2. (I would avoid 0 in case 0 has special meaning.)

    Here is a sample excerpt from a miniupnp config file:
    # unused rules cleaning.
    # never remove any rule before this threshold for the number
    # of redirections is exceeded. default to 20
    #clean_ruleset_threshold=10
    # clean process work interval in seconds. default to 0 (disabled).
    # a 600 seconds (10 minutes) interval makes sense
    clean_ruleset_interval=600


    Second, it could be that the option only works for NAT-PMP. UPnP is a mess and technically allows ports to stay open forever. NAT-PMP which actually has a thought-out/designed specification says ports should be leased for a certain amount of time (like DHCP addresses). So cleaning might only apply to NAT-PMP. You might try enabling NAT-PMP. it's a way better protocol than UPnP. I think Skype supports it now. A lot of software now seems to support both and will try to pick NAT-PMP first if available (assuming the option is not disabled).

    Third, maybe this is a MiniUPnP bug you should report to the authors.
     
  3. mstombs

    mstombs Network Guru Member

    miniupnp does clear upnp, but yes it only clears old ones if above the threshold - but surely it is a windows app bug not removing mapping when programs cleanly shut-down?
     
  4. dmb41crash

    dmb41crash Networkin' Nut Member

    Good info, thanks! I will definitely give NAT-PMP a try and see if my software supports it. If so, I will give up on UPnP, which I'm not a huge fan of anyways for the reasons mentioned. If not, I will play with the threshold and see if lowering it helps.


    A bug in Windows/Windows software?!? Say it ain't so! :biggrin:
     
  5. TerminatorHTK

    TerminatorHTK LI Guru Member

    I too am seeing the rules never get cleaned up. Has anyone come up with a value for the cleaning threshold that works well?
     
  6. Azuse

    Azuse LI Guru Member

    This has been bugged, as far as I've noticed, since victek last updated his 2.4k builds (don't remember which tb build they're based on though). I used to have the threshold at zero and tried values up to a reasonable number for small lan but none work. Unless a program actually closes it's port (plenty don't) they stay open and build up quite quickly.

    Automatic cleaning has been broke for some time.
     
  7. Toastman

    Toastman Super Moderator Staff Member Member

    Unlike NAT-PMP, there wasn't a built-in method in UPnP to expire old connections that were not properly closed. The miniupnpd author thought about this and how it could be done, and from posts on his support forum this is my understanding of what he did.

    The way it is supposed to work is that a traffic counter was implemented on the connection on each forwarded port. At the cleaning interval time, the counter for each connection is checked and if it is the same, that connection is assumed to be dead ( i.e. it isn't passing any traffic ) and the connection should be expired. This seems to have stopped working? Or maybe not - see my next post below. http://www.linksysinfo.org/forums/showpost.php?p=371811&postcount=9
     
  8. TerminatorHTK

    TerminatorHTK LI Guru Member

    I'm running Teddy Bear's mod on an Asus RT-N16 router. After reading the replies above, I was about to give up. But I had set the counter 5 from the default of 20, so thought I'd give it one last check. Imagine my surprise, it actually did clean up most of the rules, and left the few that were active. So I'm not sure if this might be working, but maybe not with the default of 20?

    BTW, what exactly does this redirection parameter do? Redirection implies more than just looking for 'no traffic'?
     
  9. Toastman

    Toastman Super Moderator Staff Member Member

    I notice that the expire function works with pretty much everything on my system, except P2P clients which are often left. [I'm using the latest Teddy Bear code as a base here.]

    Now, this just might be the usual problem with remote servers still trying to connect with your P2P client even though it has closed the port - the very same thing that causes lots of strange unclassified connections. These could be incrementing the expiry counters and thus it would seem that the uTorrent application was still passing traffic.

    To test this I unplugged my PC from the LAN - it was running uTorrent, Skype, MSN Messenger, Yahoo Messenger, Teredo. After an hour I ran the expire function and everything was correctly deleted - except for uTorrent. There were incoming unclassified connections from more than a dozen remote P2P clients - you can see that the destination port is the one that uTorrent had been using.

    I disconnected from the ISP and reconnected, obtaining a new IP. The incoming unclassified connections were no longer there - they were now going to the OLD IP somewhere in the cloud - and we can now forget about them. I ran the expire function again and the uTorrent portforwards (redirections) were now removed.

    It seems repeatable, so this could be the explanation. Anything that tries to connect with an application after it has "closed" but failed to delete the UPnP entry, may prevent the expire function from working. There may be other applications that do this, but it's very common with P2P.
     
  10. Azuse

    Azuse LI Guru Member

    P2P servers give up after x amount of hours. I had entries that were almost a month old (pc restarted each day, different ports). Anyway, once utorrent is closed software firewalls will reject the p2p traffic which is what stops servers sending it.

    Open task manager and end the utorrent process i.e. simulate a crash for the router, how long does the entry stay in the router?
     
  11. Toastman

    Toastman Super Moderator Staff Member Member

    All unused rules cleared after IP change. 6 of these were uTorrent and the other was Skype.

    Not all P2P servers give up so easily, it's been well documented that some continue for days to try to get part files from you, long after you've closed your P2P application. It's not a bug in your own client, it's the remote P2P client that has you in a list as a supplier for that file, and it tries to connect to you to get it. How long it will do that depends on how it is configured - but that's outside your control.

    To answer your last question, in my case, they remain until they are expired after obtaining a new IP from my ISP. Or, to put it another way, my systems remain up for months on end with more than a hundred users opening and closing ports several times a day. But I don't ever get the buildup of ports that other users report. The reason for that is probably that my ISP renews the lease and changes my WAN IP every 24 hours. After that IP change, there are no longer any incoming connections to those closed ports, and all "hung" redirections get closed on the next expire cycle.

    That is why I called attention to it in the post above. It may or may not be the explanation but it seems so from my experiments. Your mileage may vary.
     
  12. Azuse

    Azuse LI Guru Member

    Indeed :)

    Still, like pretty much everyone on my isp my ip is static. In fact no isp in this country would bother switching them daily, even dynamic ips only change if a user disconnects (which basically means they never do).

    Anyway, I've been prodding upnp since early dec. (I play with the utorrent betas) but the client I've used has no torrents in it, it's simply the dht running i.e. no server spamming requests. Granted I only noticed this relatively recently, but it didn't occur in the older raf build I used.

    For example. I "crashed" utorrent twice earlier, then ran it and close it properly just now. The last enrty removed itself correctly however I have Udp entries on 15915 & 29049. I have had no traffic on 15915 at all in the past 20 min yet the port is still open (not surprising since I crashed 4 hours ago). 29049 is also labelled utorrent, and hasn't been active on the port for 4 hours but the router is listing several outbound connections on the port every minute which is, odd..

    Going through wireshark log atm, but 15915 should have been closed and hasn't.
     
  13. mstombs

    mstombs Network Guru Member

    It is not unusual for entries to appear to be the wrong way round, it seems to be 'by design' :-

    http://www.faqs.org/docs/iptables/theconntrackentries.html
     
  14. Azuse

    Azuse LI Guru Member

    Fair enough. Seems the pcs firewall was rejecting packets because the program wasn't using the port, which makes sense. Just deleted it.

    Now the 15915 entry was older and there was no traffic at all going to it, not on the pc or listed in the router, yet it stayed open all night and didn't actually close until this morning. I find this strange.
     
  15. rhester72

    rhester72 Network Guru Member

    Is it possible that it considers the port still 'active' if incoming UDP traffic continues even though there is no listener on the destination IP? (I'm not sure if it considers the connection 'idle' just because the listener goes away.)

    Rodney
     

Share This Page