For my own purpose I have found a way to use pcp to open a few ports which will be directed to the box itself.
I need this to effectively manage many boxes from a remote location.
The way I do it is not as elegant as I would like to.
The main reason for this is the restrictions that are (deliberately?) created in pcplisten.
These 2 restrictions are:
It also creates a mapping of merely 120 seconds, but that one gets refreshed at half its lifetime by ctlmgr.
What command does it use to do that?
Another observation of mine is that the rules that one creates on a 6.84 box using "internet_forwardrules" in /var/flash/ar7.cfg are migrated after an upgrade to 7.x
This means that these lines disappear out of /var/flash/ar7.cfg but are held somewhere else in writable space and the ctlmgr daemon will continue to keep these ports open.
In what configuration file are these forwards held?
This also means that those forwards can not be managed anymore and will stay there until the box gets a factory reset. That's a bit strange, isn't it?
Like many other manufacturers it seems that AVM think it still owns the box they sold to us.
This means that if I remotely upgrade the >70 boxes to 7.11 the current forwards will be set somewhere and I will not be able to delete those anymore. If I don't want that I could remove the forwards first and then upgrade. Effectively removing the forwards is unwanted as I would lose access. It may work to change /var/flash/ar7.cfg and then do the upgrade to my own 7.11 which will then create my own system to open up the ports....
I need to test that thoroughly first.
In RFC6887 the renewing is described and funny enough it says that I shouldn't be hammering the PCP-server to force a renewal. Of course I don't want to do that, but for the time being I seem to have no other choice. In my script I do my best to minimize the hammering. I observed the behaviour of my script and it only sends out some 4 or 5 maps per port each 120 seconds with an interval of 0.4 seconds. I think that's pretty decent ;-)
Because each 120 seconds there's a small period that there is no mapping existent I don't really want to use the solution I made.
Using "voip_forwardrules" however is even less appealing to me, even though the rules will get upheld by ctlmgr.
As far as I can gather this small period will not be of influence to TCP-connections because an opened connection will stay open for a short while after the mapping expires. On most iptables based firewalls this is done and it appears the AVM-firewall behaves similar.
Most have this as (one of) their first rule(s):
I did a test opening up port 80 with a lifetime of 10 seconds.
If I opened up a browser within that 10 seconds and kept clicking regularly it would be able to connect long (>minute) after the lifetime expired.
This means the "less than a second" disappearance of a mapping should not pose a problem.
UDP is different.
@PeterPawn
Isn't the best solution out of this an addition of a pcp-client without the restrictions of pcplisten?
I need this to effectively manage many boxes from a remote location.
The way I do it is not as elegant as I would like to.
The main reason for this is the restrictions that are (deliberately?) created in pcplisten.
These 2 restrictions are:
- Maximum lifetime of 120 seconds, no "infinite"
- The inability to refresh an existing mapping (maybe it's a hidden feature?)
It also creates a mapping of merely 120 seconds, but that one gets refreshed at half its lifetime by ctlmgr.
What command does it use to do that?
Another observation of mine is that the rules that one creates on a 6.84 box using "internet_forwardrules" in /var/flash/ar7.cfg are migrated after an upgrade to 7.x
This means that these lines disappear out of /var/flash/ar7.cfg but are held somewhere else in writable space and the ctlmgr daemon will continue to keep these ports open.
In what configuration file are these forwards held?
This also means that those forwards can not be managed anymore and will stay there until the box gets a factory reset. That's a bit strange, isn't it?
Like many other manufacturers it seems that AVM think it still owns the box they sold to us.
This means that if I remotely upgrade the >70 boxes to 7.11 the current forwards will be set somewhere and I will not be able to delete those anymore. If I don't want that I could remove the forwards first and then upgrade. Effectively removing the forwards is unwanted as I would lose access. It may work to change /var/flash/ar7.cfg and then do the upgrade to my own 7.11 which will then create my own system to open up the ports....
I need to test that thoroughly first.
In RFC6887 the renewing is described and funny enough it says that I shouldn't be hammering the PCP-server to force a renewal. Of course I don't want to do that, but for the time being I seem to have no other choice. In my script I do my best to minimize the hammering. I observed the behaviour of my script and it only sends out some 4 or 5 maps per port each 120 seconds with an interval of 0.4 seconds. I think that's pretty decent ;-)
Because each 120 seconds there's a small period that there is no mapping existent I don't really want to use the solution I made.
Using "voip_forwardrules" however is even less appealing to me, even though the rules will get upheld by ctlmgr.
As far as I can gather this small period will not be of influence to TCP-connections because an opened connection will stay open for a short while after the mapping expires. On most iptables based firewalls this is done and it appears the AVM-firewall behaves similar.
Most have this as (one of) their first rule(s):
Code:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPTI did a test opening up port 80 with a lifetime of 10 seconds.
If I opened up a browser within that 10 seconds and kept clicking regularly it would be able to connect long (>minute) after the lifetime expired.
This means the "less than a second" disappearance of a mapping should not pose a problem.
UDP is different.
@PeterPawn
Isn't the best solution out of this an addition of a pcp-client without the restrictions of pcplisten?
Zuletzt bearbeitet:
