opening ports for FB on 7.59+

[fraternl]

For years I've used Freetz (not Freetz-NG) with the addition of a script using /bin/pcplisten
I always had access and didn't fail.

The script was a bit comprehensive and probably unnecessary complex, but it turned out to be rock solid.

I do not want to revisit that script anymore, so I went to a simple cronjob like this:

*/2 * * * * /bin/pcplisten tcp 127.0.0.1 10 120 ten
*/2 * * * * /bin/pcplisten tcp 127.0.0.1 11 120 eleven
*/2 * * * * /bin/pcplisten tcp 127.0.0.1 12 120 twelve

I noticed this resulted in only 2 entries in the firewall
I assumed the PCP-server was too busy handling 3 of those that quickly after each other, so I changed the cronjob to this:

*/2 * * * * /bin/pcplisten tcp 127.0.0.1 10 120 ten
*/2 * * * * sleep 1 && /bin/pcplisten tcp 127.0.0.1 11 120 eleven
*/2 * * * * sleep 2 && /bin/pcplisten tcp 127.0.0.1 12 120 twelve

and this turned out to be working for all 3 entries.
Time will tell how reliable it all is.

I assume most do not have the need to open 3 ports, but even if it's 2 it's probably more reliable to give the 2nd one a delay.

If so, I can finally start using 7.8+
Can someone using the simple cron approach tell me if the ports turn out to be always available and open?

[fraternl]

This needs more examination...
Just lost an entry using this approach and although they showed in the AVM-interface they weren't actually working either.

I will come back later.

[fraternl]

Mmmmm, the 127.0.0.1 is incorrect.
It should contain the LAN IP

*/2 * * * * /bin/pcplisten tcp 192.168.178.1 10 120 ten
*/2 * * * * sleep 2 && /bin/pcplisten tcp 192.168.178.1 11 120 eleven
*/2 * * * * sleep 4 && /bin/pcplisten tcp 192.168.178.1 12 120 twelve

As the LAN-IP can be different for each box I tried 169.254.1.1 and that worked too.

*/2 * * * * /bin/pcplisten tcp 169.254.1.1 10 120 ten
*/2 * * * * sleep 2 && /bin/pcplisten tcp 169.254.1.1 11 120 eleven
*/2 * * * * sleep 4 && /bin/pcplisten tcp 169.254.1.1 12 120 twelve

[fda77]

There was a thread about the same a short time ago

To avoid timing problems you could use 119 .. read there!

I assume most do not have the need to open 3 ports, but even if it's 2 it's probably more reliable to give the 2nd one a delay.

You could use a script and then you dont need "sleep"

[fraternl]

By using 119 seconds you will make sure that you don't invoke the command too early.
That's true.

If you do, The port will be closed for 2 minutes.
But it also means it is not listening for a second each 2 minutes.

For most things it's not a problem, but I have 1 service which does have a problem with it.

With this approach I have yet to encounter a missing open port.
I will find out when I start using it extensively.

In the script I was using for classic Freetz I monitored if the opening was succesful and if not, it would retry until it was.

If this is working (also under stress) then there may be no need for it.

[fda77]

Instead "cron" you could try to "sleep". But for multiple ports it could cause delays too...
Have you tried https://freetz-ng.github.io/freetz-ng/make/#pcp ? Maybe it works better

[fraternl]

I've done some testing and came to the conclusion that the "119 seconds" is safe.
I don't see any gaps and I even think the port doesn't really close until another half minute.

So, I'm back at:

*/2 * * * * /bin/pcplisten tcp 169.254.1.1 10 119 ten
*/2 * * * * /bin/pcplisten tcp 169.254.1.1 11 119 eleven
*/2 * * * * /bin/pcplisten tcp 169.254.1.1 12 119 twelve

Still, I did find some way to expand upon it.
I really want to open up the ports as quickly as possible and worst-case scenario it can take up to 2 minutes after it has completely started up (also 3 minutes) after a reboot.

I do this by waiting until the box has connected to a timeserver and then I calculate how many seconds there are until the next 2 minutes.
Then I initiate a pcplisten for exact the right time.

I monitored the opening and it was spot on.

I logged in using the box from the LAN-interface, but pulled the WAN.
I then started to repeat the line

date && grep 169.254 /proc/kdsld/dsliface/internet/ipmasq/pcp44

So I will see the time and the port forwards.
And then I connected the WAN

It apparently opened the ports 65 seconds before 17:42

root@fritz:/var/mod/root# date && grep 169.254 /proc/kdsld/dsliface/internet/ipmasq/pcp44
Mon Aug 12 17:41:59 CEST 2024
MAP  TCP [169.254.1.1]:10 [10.0.0.43]:10 use 1, lifetime 65 secs, expire in 1 secs
MAP  TCP [169.254.1.1]:11 [10.0.0.43]:11 use 1, lifetime 65 secs, expire in 1 secs
MAP  TCP [169.254.1.1]:12 [10.0.0.43]:12 use 1, lifetime 65 secs, expire in 1 secs
root@fritz:/var/mod/root# date && grep 169.254 /proc/kdsld/dsliface/internet/ipmasq/pcp44
Mon Aug 12 17:41:59 CEST 2024
MAP  TCP [169.254.1.1]:10 [10.0.0.43]:10 use 1, lifetime 65 secs, expire in 0 secs
MAP  TCP [169.254.1.1]:11 [10.0.0.43]:11 use 1, lifetime 65 secs, expire in 0 secs
MAP  TCP [169.254.1.1]:12 [10.0.0.43]:12 use 1, lifetime 65 secs, expire in 0 secs
root@fritz:/var/mod/root# date && grep 169.254 /proc/kdsld/dsliface/internet/ipmasq/pcp44
Mon Aug 12 17:42:00 CEST 2024
root@fritz:/var/mod/root# date && grep 169.254 /proc/kdsld/dsliface/internet/ipmasq/pcp44
Mon Aug 12 17:42:01 CEST 2024
MAP  TCP [169.254.1.1]:10 [10.0.0.43]:10 use 1, lifetime 119 secs, expire in 119 secs
MAP  TCP [169.254.1.1]:11 [10.0.0.43]:11 use 1, lifetime 119 secs, expire in 119 secs
MAP  TCP [169.254.1.1]:12 [10.0.0.43]:12 use 1, lifetime 119 secs, expire in 119 secs
root@fritz:/var/mod/root# date && grep 169.254 /proc/kdsld/dsliface/internet/ipmasq/pcp44
Mon Aug 12 17:42:01 CEST 2024
MAP  TCP [169.254.1.1]:10 [10.0.0.43]:10 use 1, lifetime 119 secs, expire in 118 secs
MAP  TCP [169.254.1.1]:11 [10.0.0.43]:11 use 1, lifetime 119 secs, expire in 118 secs
MAP  TCP [169.254.1.1]:12 [10.0.0.43]:12 use 1, lifetime 119 secs, expire in 118 secs
root@fritz:/var/mod/root# date && grep 169.254 /proc/kdsld/dsliface/internet/ipmasq/pcp44
Mon Aug 12 17:42:04 CEST 2024
MAP  TCP [169.254.1.1]:10 [10.0.0.43]:10 use 1, lifetime 119 secs, expire in 115 secs
MAP  TCP [169.254.1.1]:11 [10.0.0.43]:11 use 1, lifetime 119 secs, expire in 115 secs
MAP  TCP [169.254.1.1]:12 [10.0.0.43]:12 use 1, lifetime 119 secs, expire in 115 secs

In my /etc/init.d/rc.xxxxxx script where I fill the cronjob with these values I also have this:

sh /sbin/openports &

cat /sbin/openports

#!/bin/sh

# Calculate seconds until next cron "*/2 * * * *"
safe_seconds() {
  # Calculate the number of seconds passed within the current 2-minute window
  seconds_passed_in_interval=$((`date +%s` % 120))

  # Calculate the number of seconds remaining until the next even minute, minus 1 second
  echo $((119 - seconds_passed_in_interval))
}


# Wait until we know what time it is
while sleep 2 ; do
  [ `date +%s` -gt 1723476000 ] && break
done

# check if ports are still closed
if ! grep -q 169.254 /proc/kdsld/dsliface/internet/ipmasq/pcp44 ; then
  # Try to open port until cron takes over:
  /bin/pcplisten tcp 169.254.1.1 10 `safe_seconds` temp
  /bin/pcplisten tcp 169.254.1.1 11 `safe_seconds` temp
  /bin/pcplisten tcp 169.254.1.1 12 `safe_seconds` temp
fi

The moment the FB knows what time it is it starts to open up the ports for the amount of seconds left until the next even minute.
This way the ports are opened quickly after startup.

[fda77]

Have you considered to used "pcp" freetz tool to open the ports by "regular" way? Maybe there is another timing, so far nobody tested it

In my /etc/init.d/rc.xxxxxx script where I fill the cronjob with these values I also have this:
sh /sbin/openports &

This will cause "zombie" processes as long as your script is not terminated!

[fraternl]

This will cause "zombie" processes as long as your script is not terminated!

It's done on purpose, so it doesn't halt the rc.xxx script.
It works exactly as expected.

[fda77]

it can cause problems as expected you later ask here to fix!

[fraternl]

Have you considered to used "pcp" freetz tool to open the ports by "regular" way? Maybe there is another timing, so far nobody tested it

Some 5 years ago I tested it extensively and ended up using a script which persistently tries pcplisten until it knows it renewed the session.

When I switched to freetz-ng I noticed that it was possible again the set it in the Freetz WebIF.
Now that's gone again in 7.8x I need to go back doing it myself.

Now I like the simplicity of using cron.
I am now also more sure there is no problem if the session expired a few seconds.
I was unnecessary afraid of that.

The above script is merely added to open the ports a bit earlier than the cronjob does for the first time.
I prefer to have access as quickly as possible after a restart.
My guess is that most do not care as long as the port opens in reasonable time and does not close.

I think that's covered with:

*/2 * * * * /bin/pcplisten tcp 169.254.1.1 10 119 ten

I don't see it as a downside to use cron.

[fda77]

doing it myself

Yes, currently it seems onbody investigating this!

I prefer to have access as quickly as possible after a restart.
My guess is that most do not care as long as the port opens in reasonable time and does not close.

my observation is that a crappy german telekom dsl line needs at least 2min 50 sec to "train" so a 2 min cron is perfect...

[fraternl]

my observation is that a crappy german telekom dsl line needs at least 2min 50 sec to "train" so a 2 min cron is perfect...

When I did my test the box was already running for some time, but the WAN was unplugged.
pcplisten doesn't do anything until the WAN is up.

So those "up to 2 minutes" come on top of that.
As you can see in the test, I "won" 65 seconds.

I do agree it may not be worth the effort, but it was a nice programming exercise.

[fda77]

pcplisten doesn't do anything until the WAN is up.

Thx, i did not test it.
Does the "pcp" tool also does nothing as long there is no internet connection?

[fraternl]

Not even the port you set for the external AVM-WebIF will have an entry.

[fda77]

This is handle in a different way in ar7.cfg by avm

grep ^websrv  /var/flash/ar7.cfg -A9

i think "ctlmgr" opens it

[aldaja]

Can you tell more about opening port Via ar7.cfg?
In new firmware VoIP forward 0.0.0.0:1194 not working
I wouldn't like open remote access to httpS:
Elsewhere I can inject other service in Wbesrv

[fraternl]

I know that it will be opened at a certain stage and /proc/kdsld/dsliface/internet/ipmasq/pcp44 will show it.
However, it will not be opened until the WAN is up.

[fda77]

yes, thats really annoying! and no updates are possible until it is closed.

Have you considered to used "pcp" freetz tool to open the ports by "regular" way?