Port incrementing - Linksys BEFSR41v3 only seems to support a description length of 11 characters

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open an application (such as SubEthaEdit) that maps a port.
2. Force quit the application (simulating a sudden shutdown or crash)
3. Re-open said application.
4. Look at current port forwarding.
5. Observe the fact that annoyingly, in addition to the previously
forwarded 6942, 6943 is now forwarded as well. When this happens a lot,
these build up.

Now, this can be helped if you add the following code:

+ (void)initialize {
  signal(SIGTERM, terminateSignal);  
}

And before the @implementation:

void terminateSignal(int signal) {
    pid_t my_pid;
    fflush(stdout);
    [[TCMPortMapper sharedInstance] stopBlocking];
    my_pid = getpid();
    kill(my_pid, SIGKILL);
}

However, this will only guard against force quits (and Xcode terminate),
and not crashes or sudden power loss. It would be great if this didn't
happen/didn't have to happen in both my applications and SubEthaEdit.
Overall, however, I love the framework.

What version of the product are you using? On what operating system? Intel
or PPC?

Original issue reported on code.google.com by AriXm...@gmail.com on 28 Apr 2009 at 1:31

[GoogleCodeExporter]

Just thought of another instance where this could cause a problem - I'm at 
home, with
my laptop, and launch my application. The port is forwarded on my home router. 
I then
close my computer and go to someone else's house, and open the computer. There 
is no
chance for the computer to close the port at my house. Therefore, when I return 
to my
house and launch the application again, the port will become forwarded again, 
but
TCMPortMapper will increment the number.

Original comment by AriXm...@gmail.com on 28 Apr 2009 at 10:40

[GoogleCodeExporter]

can you elaborate more on this? are you using upnp or natpmp for that to 
happen? does the actual port the app 
is using locally also increase? e.g. in SubEthaEdit we use the port range from 
6942 up to 6950 depending on 
which ports already are in use. And a tear down, crash can cause the port still 
to be in use for a little time.

in addition to that: what router are you using? we had issues with AVM routers 
where this build up was an actuall 
bug because these routers replace anything non-alphanumeric in the description 
with a dot which caused port 
mappings to acumulate. please make sure to use the lastest version of the 
tcmportmap framework for testing 
this.

Original comment by dasge...@gmail.com on 29 Apr 2009 at 8:36

[GoogleCodeExporter]

I'm using UPnP on my Linksys BEFSR41v3 router. Only the external ports 
increment. So,
if this happens several times, I'll see something like this:
Name         Internal Port         External Port
SubEthaEdit  6942                  6942
SubEthaEdit  6942                  6943
SubEthaEdit  6942                  6944
SubEthaEdit  6942                  6945

Original comment by AriXm...@gmail.com on 29 Apr 2009 at 11:23

[GoogleCodeExporter]

thanks for the quick report - could you plese report to me the version of 
subethaedit you are using as well as the 
list PortMap is showing to you when you press the "All UPNP Mappings" button in 
the lower left when multiple 
port mappings are in place. Normally the applications should recognize mappings 
as their own and reuse them. 
this is clearly a bug and the way the descriptions of the mappings look like 
will help my find and fix it.

Original comment by dasge...@gmail.com on 29 Apr 2009 at 12:07

[GoogleCodeExporter]

Hey, sorry for my delayed response. I totally forgot :p

I was using SEE 3.2 (now 3.2.1)
Attached are my mappings.

Original comment by AriXm...@gmail.com on 5 May 2009 at 8:22

Attachments:

• [Picture 2.png](https://storage.googleapis.com/google-code-attachments/tcmportmapper/issue-33/comment-5/Picture 2.png)

[GoogleCodeExporter]

thank you very much - the issue seems your router only supports 11 characters 
for the description of a port 
mapping. i will address this issue in one of the next releases. 

Original comment by dasge...@gmail.com on 6 May 2009 at 6:05

[GoogleCodeExporter]

Original comment by dasge...@gmail.com on 6 May 2009 at 6:06

• Changed title: Port incrementing - Linksys BEFSR41v3 only seems to support a description length of 11 characters

[GoogleCodeExporter]

Original comment by dasge...@gmail.com on 6 May 2009 at 6:06

• Changed state: Accepted

[GoogleCodeExporter]

Hey, has this been fixed, or will it be at some point? It's kind of 
inconvenient for testing my app ;)

Original comment by AriXm...@gmail.com on 28 May 2009 at 8:04

[GoogleCodeExporter]

i currently don't have a upnp setup here, i'll look into it next week probably. 
however, 11 characters are really 
short, I'm kind of reluctant to make that change because then the descriptions 
get really cryptic... i'll probably 
change the order of the description to begin with the hash and then let a 
prefix match decide. 

Original comment by dasge...@gmail.com on 28 May 2009 at 9:52

[GoogleCodeExporter]

I really need to get a new router, this one is terrible ;)
I mean the UPnP support is obviously bad, plus it tends to randomly crash and 
either stop the web interface, the 
DHCP server, or internet access altogether :(

Anyway, thanks for all of your help in this issue. Is there a way I can force 
my application's description to be only 
a few letters so it'll at least work for my testing? Where does it take that 
value from?

Original comment by AriXm...@gmail.com on 28 May 2009 at 10:03

[GoogleCodeExporter]

if fixed this issue in the trunk - if you could check it out and test it with 
your router, i would be delighted to 
know if it actually works ;)

Original comment by dasge...@gmail.com on 1 Jul 2009 at 9:39

• Changed state: Fixed

[GoogleCodeExporter]

I'm back from vacation - I'll test if it works and get back to you. Thanks!

Original comment by AriXm...@gmail.com on 19 Jul 2009 at 2:30