Hello,
I have telnet access on my FB.
Is it possibile to set a portforwarding using command line?
Thanks
s
I have telnet access on my FB.
Is it possibile to set a portforwarding using command line?
Thanks
s
Zuletzt bearbeitet:
[Info] Port forwarding using CLI
- Ersteller stefanoIT
- Erstellt am
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Hello
Maybe :gruebel:
You need 7 "lines" to read/write a single forwarding (IPv4)...
...this example shows reading (r).
Maybe :gruebel:
You need 7 "lines" to read/write a single forwarding (IPv4)...
Code:
local FW_IP=$(ctlmgr_ctl r forwardrules settings/rule${count}/fwip)
local FW_PORT=$(ctlmgr_ctl r forwardrules settings/rule${count}/port)
local FW_PORT_ST=$(ctlmgr_ctl r forwardrules settings/rule${count}/fwport)
local FW_PORT_EN=$(ctlmgr_ctl r forwardrules settings/rule${count}/endport)
local FW_PRT=$(ctlmgr_ctl r forwardrules settings/rule${count}/protocol)
local FW_DESCR=$(ctlmgr_ctl r forwardrules settings/rule${count}/description)
local FW_ACT=$(ctlmgr_ctl r forwardrules settings/rule${count}/activated)
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Without any fact regarding the current environment (the only information is: "on my FB" - could be read as "on my FRITZ!Box router" with (at least some) guessing due to the current sub-forum), it's surely useless to speculate.
If I need to open a port in a newer FRITZ!OS version and the target is a local service (on the router itself, mapped 1:1 to the external port), I use "pcplisten" to establish the needed forwarding ... but this little utility is present only in firmware using PCP for port forwarding. Additionally it has some flaws in newer versions - while in earlier versions the "lifetime" could be set up to 300 seconds, newer ones accept still these 300 seconds as argument (everything above 300 leads to an error), but the created forwarding has only a lifetime of 120 seconds ... no matter if a value greater than 120 seconds was specified during the call.
Such a forwarding (which can't be established using ctlmgr commands - all forwardings to the router itself are denied there and may be established using a modified ar7.cfg only) may be useful, if you've an own service running on the box and you don't want to change the ar7.cfg file - any changes there are only in effect after ctlmgr, multid and dsld have been restarted. Using "pcplisten" as opposite needs a regular update of this registration, but it's working without traces and any needs to undo changes to configuration files later.
If the target of the forwarding is any other local device, there're many other options to establish them ... starting with the already mentioned "ctlmgr_ctl" (here I'm unsure, if it's possible to establish the needed values one after the other), following the path over "set.lua" to the official API (TR-064) to establish such a forwarding.
As mentioned above, the intention isn't really clear and the question
If I need to open a port in a newer FRITZ!OS version and the target is a local service (on the router itself, mapped 1:1 to the external port), I use "pcplisten" to establish the needed forwarding ... but this little utility is present only in firmware using PCP for port forwarding. Additionally it has some flaws in newer versions - while in earlier versions the "lifetime" could be set up to 300 seconds, newer ones accept still these 300 seconds as argument (everything above 300 leads to an error), but the created forwarding has only a lifetime of 120 seconds ... no matter if a value greater than 120 seconds was specified during the call.
Such a forwarding (which can't be established using ctlmgr commands - all forwardings to the router itself are denied there and may be established using a modified ar7.cfg only) may be useful, if you've an own service running on the box and you don't want to change the ar7.cfg file - any changes there are only in effect after ctlmgr, multid and dsld have been restarted. Using "pcplisten" as opposite needs a regular update of this registration, but it's working without traces and any needs to undo changes to configuration files later.
If the target of the forwarding is any other local device, there're many other options to establish them ... starting with the already mentioned "ctlmgr_ctl" (here I'm unsure, if it's possible to establish the needed values one after the other), following the path over "set.lua" to the official API (TR-064) to establish such a forwarding.
As mentioned above, the intention isn't really clear and the question
needs a much better explanation - the simple answer is "Yes." ... but I'd assume, it's not really helpful.stefanoIT schrieb:
Hello,
my FB is a 7360 SL with a modified firmware 6.30 with telnet enabled (and debug.cfg too)
I'm searching a way to create a portforwarding in debug.cfg because it is impossible create a porforwarding to 192.168.178.1 using web interface and the changes to ar7.cfg are lost if I change anything in the network using web interface.
That's the reason.
Thanks
my FB is a 7360 SL with a modified firmware 6.30 with telnet enabled (and debug.cfg too)
I'm searching a way to create a portforwarding in debug.cfg because it is impossible create a porforwarding to 192.168.178.1 using web interface and the changes to ar7.cfg are lost if I change anything in the network using web interface.
That's the reason.
Thanks
Zuletzt bearbeitet:
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Hello
Then probably (good chance) this is working for 7360SL with 6.30...
http://www.ip-phone-forum.de/showthread.php?t=278890&p=2091637&viewfull=1#post2091637
(found with google: site:ip-phone-forum.de koyaanisqatsi+ar7.cfg+voip+forward+rules )
Then probably (good chance) this is working for 7360SL with 6.30...
http://www.ip-phone-forum.de/showthread.php?t=278890&p=2091637&viewfull=1#post2091637
(found with google: site:ip-phone-forum.de koyaanisqatsi+ar7.cfg+voip+forward+rules )
What I am searching for is a way to do that using command line because ar7.cfg is overwritten at avery change in FB configuration.
Same here. After upgrading my 7490 to FW 6.80, I can't change the ar7.cfg manually anymore. Every change is overwritten after a reboot. I tried to stop ctlmgr, multid and dsld (by "killing" them) before changing the ar7.cfg, but that also doesn't work.
Any advice how to configure permanent forwardings to the router itself is very much appreciated.
@stefanoIT: could you do my a favor and fix the typo in the thread subject? It's "port forwarding", not "portforwording". This thread wasn't found by the search function because of the typo.
Any advice how to configure permanent forwardings to the router itself is very much appreciated.
@stefanoIT: could you do my a favor and fix the typo in the thread subject? It's "port forwarding", not "portforwording". This thread wasn't found by the search function because of the typo.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Abusing the "voip_forwardrules" should at least install the specified mappings (they're shown in the "showpcpinfo" output as "complete") ... I didn't check, if they're working as expected.
There are no "static" forwardings anymore, it looks like all allowed inbound connections have to be announced to the PCP daemon and this daemon creates the needed entries.
I don't know (didn't test it yet), if each component manages its own forwardings (and voipd is needed to create them, if "voip_forwardrules" is used) or if another component (dsld/multid/ctlmgr) handles this for all forwardings from ar7.cfg.
If you use the "ike_forwardrules" from "vpn.cfg" to work around the new limitations, the "avmike" daemon has to be started - as far as I know. Therefore at least one configured VPN connection has to exist, otherwise the daemon will quit immediately.
In my imagination this new way is also the reason, why "unauthorized" forwardings to "SELF" are detected immediately - they violate some (unknown) rules and aren't taken into account, if the forwardings are created with PCP MAP requests or while the existing mappings are enumerated, if they're about to be (re-)written to the "ar7.cfg" file.
There are some interesting things to explore (and to tell/mention), if anyone compares the PCP RFCs (there's a long list (at least eight) of these RFCs - many extensions were added later) with AVM's implementation (the "visible part", if you've got a shell session) - but that's a long story. The full PCP support (and its internal use) is a new feature in 06.80 (I'd bet, that was another reason to change the whole setup process for portforwardings from GUI) and because this is in its core a german BBS, an exhaustive explanation and discussion should be shifted to another thread (and continued in German, to provide any information to a broader audience).
The most important thing to mention/remember: Each mapping has a limited "lifetime" now - it looks like AVM shortened it to 120 seconds during the beta phase (I would say, it was possible to setup 300 seconds in the beginning) and there has to be any instance, which renews a MAP request regularly. This may be a service from AVM, if you can "fool" it to accept "unauthorized" mappings.
A different approach without any need to change the ar7.cfg file could be, that a "wrapper" starts the required service (the "target") and a parallel task (shell script or whatever), which sets up the mapping and renews it, as long as the (service) daemon is running. Here you could use the "pcplisten" utility mentioned earlier - but "the best solution" needs additional information. If you - as an example - want to start the real service from inetd.conf, you've to create the mapping independent of the running service instance, which is a completely different approach.
TL;DR: It's not as easy as in former versions to establish a permanent mapping using "internet_forwardrules". Possibly the "mark 1" option could change system's view of such a "custom mapping", but I didn't test it. Use other options as a workaround solution, if the required daemons are started in your device (voipd / avmike) or establish your own mapping with "pcplisten" (or other utilities, but you've to create them yourself, while "pcplisten" is already present). I'd (personally) prefer the solution without additional changes to "ar7.cfg" or "vpn.cfg" - if AVM changes the validation logic for other entries in the next step, your problems will re-occur.
There are no "static" forwardings anymore, it looks like all allowed inbound connections have to be announced to the PCP daemon and this daemon creates the needed entries.
I don't know (didn't test it yet), if each component manages its own forwardings (and voipd is needed to create them, if "voip_forwardrules" is used) or if another component (dsld/multid/ctlmgr) handles this for all forwardings from ar7.cfg.
If you use the "ike_forwardrules" from "vpn.cfg" to work around the new limitations, the "avmike" daemon has to be started - as far as I know. Therefore at least one configured VPN connection has to exist, otherwise the daemon will quit immediately.
In my imagination this new way is also the reason, why "unauthorized" forwardings to "SELF" are detected immediately - they violate some (unknown) rules and aren't taken into account, if the forwardings are created with PCP MAP requests or while the existing mappings are enumerated, if they're about to be (re-)written to the "ar7.cfg" file.
There are some interesting things to explore (and to tell/mention), if anyone compares the PCP RFCs (there's a long list (at least eight) of these RFCs - many extensions were added later) with AVM's implementation (the "visible part", if you've got a shell session) - but that's a long story. The full PCP support (and its internal use) is a new feature in 06.80 (I'd bet, that was another reason to change the whole setup process for portforwardings from GUI) and because this is in its core a german BBS, an exhaustive explanation and discussion should be shifted to another thread (and continued in German, to provide any information to a broader audience).
The most important thing to mention/remember: Each mapping has a limited "lifetime" now - it looks like AVM shortened it to 120 seconds during the beta phase (I would say, it was possible to setup 300 seconds in the beginning) and there has to be any instance, which renews a MAP request regularly. This may be a service from AVM, if you can "fool" it to accept "unauthorized" mappings.
A different approach without any need to change the ar7.cfg file could be, that a "wrapper" starts the required service (the "target") and a parallel task (shell script or whatever), which sets up the mapping and renews it, as long as the (service) daemon is running. Here you could use the "pcplisten" utility mentioned earlier - but "the best solution" needs additional information. If you - as an example - want to start the real service from inetd.conf, you've to create the mapping independent of the running service instance, which is a completely different approach.
TL;DR: It's not as easy as in former versions to establish a permanent mapping using "internet_forwardrules". Possibly the "mark 1" option could change system's view of such a "custom mapping", but I didn't test it. Use other options as a workaround solution, if the required daemons are started in your device (voipd / avmike) or establish your own mapping with "pcplisten" (or other utilities, but you've to create them yourself, while "pcplisten" is already present). I'd (personally) prefer the solution without additional changes to "ar7.cfg" or "vpn.cfg" - if AVM changes the validation logic for other entries in the next step, your problems will re-occur.
The solution I found was to insert the following lines in debug.cfg
My firmware has debug.cfg working and I created a forward rule to IP 192.168.178.19 using web interface.
I had to delay the ip alias setup to avoid the disabling of the rule at the startup and however I enable the rule during startup using ctlmgr_ctl.
Code:
/usr/bin/ctlmgr_ctl w forwardrules settings/rule0/activated 1
(/bin/sleep 30; /sbin/ifconfig lan:1 192.168.178.19) &My firmware has debug.cfg working and I created a forward rule to IP 192.168.178.19 using web interface.
I had to delay the ip alias setup to avoid the disabling of the rule at the startup and however I enable the rule during startup using ctlmgr_ctl.
So I also tried to modify the "voip_forwardrules", and they are get reverted to the config before the change.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
@whoopie:
Ich mache mal in Deutsch weiter, soweit ich weiß, kann @stefanoIT das lesen und ist damit nicht im Nachteil (or I'll write it again in English, if it's really needed).
Hast Du die Änderung an der "voip.cfg" bei gestartetem "ctlmgr" und "voipd" vorgenommen? Ich weiß nicht so genau, wer von den beiden jetzt alles seine eigene Kopie der Daten im Speicher hält und dann für das Schreiben einer Datei aus dieser Kopie zuständig ist ... aber eine Änderung an der voip.cfg (113.06.80, nur mit "modfs" angepaßt an meine Bedürfnisse):
führt bei mir genau zum gewünschten Ergebnis (auch wenn da kein Daemon läuft, ich hatte auch zuvor geschrieben, daß ich nur bis zum "mapping complete" getestet hatte:
(beide Kommandos gerade erst ausgeführt, die "network failure"-Meldungen stammen von einer noch nicht aktiven Internetverbindung nach einem Neustart).
Es geht also bei Dir vielleicht weniger um die Frage, wie man das realisieren kann als vielmehr darum, wie man es (richtig) einrichtet?
Ich mache mal in Deutsch weiter, soweit ich weiß, kann @stefanoIT das lesen und ist damit nicht im Nachteil (or I'll write it again in English, if it's really needed).
Hast Du die Änderung an der "voip.cfg" bei gestartetem "ctlmgr" und "voipd" vorgenommen? Ich weiß nicht so genau, wer von den beiden jetzt alles seine eigene Kopie der Daten im Speicher hält und dann für das Schreiben einer Datei aus dieser Kopie zuständig ist ... aber eine Änderung an der voip.cfg (113.06.80, nur mit "modfs" angepaßt an meine Bedürfnisse):
Code:
$ [COLOR="#0000FF"]grep -A 5 voip_forward /var/flash/ar7.cfg[/COLOR]
voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
"tcp 0.0.0.0:5060 0.0.0.0:5060",
[COLOR="#FF0000"]"tcp 0.0.0.0:1234 0.0.0.0:1234",[/COLOR]
"udp 0.0.0.0:7078+32 0.0.0.0:7078";
voip_ip6_forwardrules = "udp 5060 # SIP", "tcp 5060 # SIP",
"udp 7078-7109 # RTP";
Code:
$ [COLOR="#0000FF"]showpcpitems | sed -e "s|192.168.<intern>|192.168.178|g" -e "s|<external_address>|101.102.103.104|g" | grep -C 2 1234[/COLOR]
0 MAP VOIP UDP 192.168.178.1 :5060 active 101.102.103.104 forever "VOIP", ignore
0 MAP VOIP TCP 192.168.178.1 :5060 active 101.102.103.104 forever "VOIP", ignore
[COLOR="#FF0000"] 0 MAP VOIP TCP 192.168.178.1 :1234 active 101.102.103.104 forever "VOIP", ignore[/COLOR]
0 MAP VOIP UDP 192.168.178.1 :7078-7109 active 101.102.103.104 forever "VOIP", ignore
0 MAP VPN UDP 192.168.178.1 :500 active 101.102.103.104 forever "VPN", ignore
$ [COLOR="#0000FF"]showpcpinfo | sed -e "s|192.168.<intern>|192.168.178|g" -e "s|<external_address>|101.102.103.104|g" | grep -C 2 1234[/COLOR]
age 82950 lasttime 17 endtime 55 nsent 0
last actions: req 17 reply 17 (secs ago)
[COLOR="#FF0000"]MAP TCP [192.168.178.1]:1234 [101.102.103.104]:1234, lifetime 120 secs, renew in 16 secs[/COLOR]
uniqid 0, cfgflags ignore_proxy_errors
group "0v4/voip" desc "VOIP"
--
wanted_lifetime 120 lifetime 120
pid 2940 caddr [192.168.178.1]
[COLOR="#FF0000"]MAP TCP [192.168.178.1]:1234 [101.102.103.104]:1234 use 1, lifetime 120 secs, expire in 73 secs[/COLOR]
uniqid 0, cfgflags ignore_proxy_errors
nonce 07200d4cec9b142bfdfd7517
--
1970-01-01 01:01:46.216 - MAP complete VOIP UDP [192.168.178.1]:5060 "VOIP" - error (network failure)
1970-01-01 01:01:46.218 - MAP complete VOIP TCP [192.168.178.1]:5060 "VOIP" - error (network failure)
1970-01-01 01:01:46.291 - MAP complete VOIP TCP [192.168.178.1]:1234 "VOIP" - error (network failure)
1970-01-01 01:01:46.299 - MAP complete VOIP UDP [192.168.178.1]:7078-7109 "VOIP" - error (network failure)
2017-01-31 22:00:52.084 - MAP complete VPN UDP [192.168.178.1]:500 "VPN" - error (network failure)
--
2017-01-31 22:00:52.728 - MAP complete VOIP UDP [192.168.178.1]:5060 "VOIP": external [101.102.103.104]:5060
2017-01-31 22:00:52.729 - MAP complete VOIP TCP [192.168.178.1]:5060 "VOIP": external [101.102.103.104]:5060
[COLOR="#FF0000"]2017-01-31 22:00:52.773 - MAP complete VOIP TCP [192.168.178.1]:1234 "VOIP": external [101.102.103.104]:1234
[/COLOR]2017-01-31 22:00:52.776 - MAP complete VOIP UDP [192.168.178.1]:7078-7109 "VOIP": external [101.102.103.104]:7078-7109p
2017-01-31 22:00:52.963 - MAP complete VPN UDP [192.168.178.1]:500 "VPN": external [101.102.103.104]:500Es geht also bei Dir vielleicht weniger um die Frage, wie man das realisieren kann als vielmehr darum, wie man es (richtig) einrichtet?
Zuletzt bearbeitet:
Du schreibst, dass ich die voip.cfg anpassen soll, ich glaube, das ist ein Tippfehler, oder?
Habe jetzt den ctlmgr und voipd Deamon vor der Änderung der ar7.cfg beendet, und jetzt ging es. Danke für die Hilfe!
Habe jetzt den ctlmgr und voipd Deamon vor der Änderung der ar7.cfg beendet, und jetzt ging es. Danke für die Hilfe!
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Ja, war ein Tipp-/Denkfehler (beim VPN betrifft es dann tatsächlich die "vpn.cfg") - lasse ich stehen als "Medienkompetenzübung" für spätere Leser, die dann eben auch bis zum Ende lesen müssen, wo Du das klarstellst. ;-)
Sorry for bringing this one back from the grave, but I had the same challenge (configure a port-forwarding via ctlmgr_clt). koyaanisqatis's reply leads the way! To configure a single IPv4 port forwarding on shell, you have to execute the following commands. Those were executed on FRITZ!Box 7490 @FRITZ!OS 6.83. It's important to follow the exact order of commands!
Note: Don't worry that while executing the "port-commands" no response value is shown, it gets set in background!
To check if port forwarding is configured properly and active, use the application PeterPawn suggested or dump the forwardrule UI-module
Furthermore it's possible to add the following kinds of forwards via shell too:
- myfritz forwards
- ipv6 port forwardings
- igd port forwardings
The procedure to do that, for example for myfritz forwardings, is slightly more "complicated", because you have to configure (add instances and configure the parameter in exact oder) in multiple UI-modules:
- forwardrules
- ipv6firewall
- landevice
- myfritzdevices
best regards,
edge
Code:
# ctlmgr_ctl r forwardrules settings/rule/newid
rule0
# ctlmgr_ctl w forwardrules settings/rule0/fwip 192.168.178.26
192.168.178.26
# ctlmgr_ctl w forwardrules settings/rule0/port 55700
# ctlmgr_ctl w forwardrules settings/rule0/fwport 55667
# ctlmgr_ctl w forwardrules settings/rule0/endport 55705
# ctlmgr_ctl w forwardrules settings/rule0/protocol TCP
TCP
# ctlmgr_ctl w forwardrules settings/rule0/description Test-FW
Test-FW
# ctlmgr_ctl w forwardrules settings/rule0/activated 1
1
#Note: Don't worry that while executing the "port-commands" no response value is shown, it gets set in background!
To check if port forwarding is configured properly and active, use the application PeterPawn suggested or dump the forwardrule UI-module
Code:
# showpcpitems | grep Test
4624 MAP FORW TCP 192.168.178.26 :55667-55672 active 78.51.177.110 55700-55705 forever "Test-FW", ignore
#
# showpcpinfo | grep Test
Jun 4 08:08:01 pcpd[2967]: msg_endpoint: got empty command
Jun 4 08:08:01 dsld[3009]: avmipc: got empty command
group "0v4/normal/4624" desc "Test-FW"
desc "Test-FW"
2017-06-04 07:56:47.745 - MAP complete FORW TCP [192.168.178.26]:55667-55672 "Test-FW": external [78.51.177.110]:55700-55705
#
# ctlmgr_ctl u forwardrules
forwardrules:settings/
use_exposed_host=0
exposed_host=
exposed_host_list=error
rule0/
UID=forw4744
landeviceref=landevice4624
activated=1
description=Test-FW
protocol=TCP
port=55700
endport=55705
fwip=192.168.178.26
fwport=55667
fwendport=55672
pcphandling=ignore
state=2
result=0
result_code=0
eprefixlen=0
eaddr=78.51.177.110
eport=55700
eport_end=55705
fw_type=1
myfritzdevice_uid=
myfritzservice_uid=
#Furthermore it's possible to add the following kinds of forwards via shell too:
- myfritz forwards
- ipv6 port forwardings
- igd port forwardings
The procedure to do that, for example for myfritz forwardings, is slightly more "complicated", because you have to configure (add instances and configure the parameter in exact oder) in multiple UI-modules:
- forwardrules
- ipv6firewall
- landevice
- myfritzdevices
best regards,
edge
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Even if this was an english thread in the past, I'll continue writing in german (a german entry should be a benefit for more readers) ...
Ich habe das irgendwann mal so realisiert, daß ein Shell-Skript tatsächlich die korrekte Reihenfolge der Anweisungen enthält (man kann sie der Lua-Seite im GUI für das Einrichten von Weiterleitungen entnehmen) und daraus aber eine Eingabe-Datei für ein Lua-File (analog zu "set.lua" und "queries.lua" - die Ausgabe des letzteren kann man auch leichter in Shell-Skripten parsen als "ctlmgr_ctl u"-Ausgaben) erzeugt, die das dann "in einem Rutsch" (also praktisch wie das GUI selbst) einrichtet ... ich finde nur gerade die Datei dazu mal wieder nicht, sonst hätte ich sie angehangen; so muß es beim "Prinzip" bleiben.
Gerade beim Abfragen von vielen Variablen mit einzelnen "ctlmgr_ctl"-Aufrufen dauert das schon mal etwas ... da ist "queries.lua" dann oft schneller und am Ende ist es meist auch schneller als "ctlmgr_ctl" mit der neuen "list(...)"-Syntax, wo das "Interpretieren" der Werte dann wieder schwieriger ist (da entscheidet die Einrückung bzw. der Schrägstrich darüber, ob ein neuer Eintrag der nächsthöheren Ebene beginnt in einer Zeile oder nicht).
Wie man das ggf. einfacher realisieren könnte, wenn man sich ein "spezialisiertes" Lua-Skript erstellt (dessen Eingabe kann ja ein Shell-Skript generieren und auch die Ausgabe verarbeiten), habe ich mal bei VPN-Verbindungen mit einem Beispiel versucht zu zeigen. Das befindet sich - neben "queries.lua" und "set.lua" - dann auch im YourFritz-Repository.
Ich habe das irgendwann mal so realisiert, daß ein Shell-Skript tatsächlich die korrekte Reihenfolge der Anweisungen enthält (man kann sie der Lua-Seite im GUI für das Einrichten von Weiterleitungen entnehmen) und daraus aber eine Eingabe-Datei für ein Lua-File (analog zu "set.lua" und "queries.lua" - die Ausgabe des letzteren kann man auch leichter in Shell-Skripten parsen als "ctlmgr_ctl u"-Ausgaben) erzeugt, die das dann "in einem Rutsch" (also praktisch wie das GUI selbst) einrichtet ... ich finde nur gerade die Datei dazu mal wieder nicht, sonst hätte ich sie angehangen; so muß es beim "Prinzip" bleiben.
Gerade beim Abfragen von vielen Variablen mit einzelnen "ctlmgr_ctl"-Aufrufen dauert das schon mal etwas ... da ist "queries.lua" dann oft schneller und am Ende ist es meist auch schneller als "ctlmgr_ctl" mit der neuen "list(...)"-Syntax, wo das "Interpretieren" der Werte dann wieder schwieriger ist (da entscheidet die Einrückung bzw. der Schrägstrich darüber, ob ein neuer Eintrag der nächsthöheren Ebene beginnt in einer Zeile oder nicht).
Wie man das ggf. einfacher realisieren könnte, wenn man sich ein "spezialisiertes" Lua-Skript erstellt (dessen Eingabe kann ja ein Shell-Skript generieren und auch die Ausgabe verarbeiten), habe ich mal bei VPN-Verbindungen mit einem Beispiel versucht zu zeigen. Das befindet sich - neben "queries.lua" und "set.lua" - dann auch im YourFritz-Repository.
Zuletzt bearbeitet:
I'll continue, from here on, in german as well.
Interessant ist, das bei aktiven ctlmgr "Debugging" (Ausführen von "ctlmgr -s" + "ctlmgr -m" sowie dann "tail -f /var/tmp/ctlmgrmsg.log") eine komplett andere Reihenfolge dargestellt wird. Folgt man dieser manuell, d.h. mit einzelnen ctlmgr_ctl calls, kann das Port-Forwarding nicht erreicht werden, da er schon das Setzen des Protokolls nicht mehr ausführt. Dabei ist es unerheblich ob das Instanz-Objekt "rule0" mit oder ohne SID (-s Schalter zur ctlmgr_ctl) "erstellt"/vorgemerkt wird. Warum das so ist, habe ich bisher nicht verstanden, aber ist ja auch nur halb so wild.
Off-Topic Frage an PeterPawn:
Kennst Du Dich mit dem "station_add/station_del" Parameter aus dem wlan UI-Modul aus? Wenn ich das richtig verstehe, wird damit die Public Hotspot (HS2.0) Funktion angesteuert (im Gegensatz zur "private Hotspot", der WLAN-Gastzugangs, Funktion). Führt man "ctlmgr_ctl w wlan settings/station_add 1" (Wert scheint dabei vermutlich egal zu sein, da Write-OP, Hauptsache er ist vorhanden) aus, werden die Instanzen "securitiesX" und "stationsX" (X jeweils für den Instanz-Index und auf einer 7490 2fach (securities) und 4fach (stations)) angelegt und nur teilweise befüllt.
Wenn man das mal mit der Config einer Cable-Box vergleicht, Link auf die Seite kann ich leider nicht einfügen (sind Paste-Bin Links verboten?) anguckt, fehlt die Hälfte. Weißt Du, wie und ob das überhaupt auf einer 7490 vollständig konfigurierbar/nutzbar ist? Eventuell fehlen ja noch Libs o.ä. und es ist eh nicht umsetztbar.
Des Weiteren ist die "ar7.cfg" Sektion "hotspotcfg", im Gegensatz zu der Cable-Box Export-Datei, auf einer 7490 leer. Ist das dazugehörige "ctlmgr Modul" eventuell "hotspotgre"?!?
Gruß,
Edge
Interessant ist, das bei aktiven ctlmgr "Debugging" (Ausführen von "ctlmgr -s" + "ctlmgr -m" sowie dann "tail -f /var/tmp/ctlmgrmsg.log") eine komplett andere Reihenfolge dargestellt wird. Folgt man dieser manuell, d.h. mit einzelnen ctlmgr_ctl calls, kann das Port-Forwarding nicht erreicht werden, da er schon das Setzen des Protokolls nicht mehr ausführt. Dabei ist es unerheblich ob das Instanz-Objekt "rule0" mit oder ohne SID (-s Schalter zur ctlmgr_ctl) "erstellt"/vorgemerkt wird. Warum das so ist, habe ich bisher nicht verstanden, aber ist ja auch nur halb so wild.
Code:
...
<59118.721837>ctlmgr:msg from luacgi5507: T from:luacgi5507 to:forwardrules seq:44 sid:f6fcf29927cb839b client_tcpport:22242 client_ip:192.168.178.20 trans-type:query key:settings/rule/newid error_code:0
<59118.722776>ctlmgr:msg OUT: T from:forwardrules to:luacgi5507 seq:1108 sid:0000000000000000 trans-type:response key:settings/rule/newid re_seq:44 error_code:0 <row><v>rule0</v></row>
<59118.728037>ctlmgr:msg from luacgi5507: T from:luacgi5507 to:manager seq:45 sid:f6fcf29927cb839b client_tcpport:22242 client_ip:192.168.178.20 trans-type:group_begin gid:cgi_group error_code:0
<59118.728810>ctlmgr:msg from luacgi5507: T from:luacgi5507 to:forwardrules seq:46 sid:0000000000000000 trans-type:set key:settings/rule0/activated gid:cgi_group error_code:0 <row><v>1</v></row>
<59118.737290>ctlmgr:msg from luacgi5507: T from:luacgi5507 to:forwardrules seq:47 sid:0000000000000000 trans-type:set key:settings/rule0/description gid:cgi_group error_code:0 <row><v>Test-FW</v></row>
<59118.738648>ctlmgr:msg from luacgi5507: T from:luacgi5507 to:forwardrules seq:48 sid:0000000000000000 trans-type:set key:settings/rule0/protocol gid:cgi_group error_code:0 <row><v>TCP</v></row>
<59118.970104>ctlmgr:msg from luacgi5507: T from:luacgi5507 to:forwardrules seq:49 sid:0000000000000000 trans-type:set key:settings/rule0/port gid:cgi_group error_code:0 <row><v>55667</v></row>
<59118.972129>ctlmgr:msg from luacgi5507: T from:luacgi5507 to:forwardrules seq:50 sid:0000000000000000 trans-type:set key:settings/rule0/fwport gid:cgi_group error_code:0 <row><v>55667</v></row>
<59118.973305>ctlmgr:msg from luacgi5507: T from:luacgi5507 to:forwardrules seq:51 sid:0000000000000000 trans-type:set key:settings/rule0/fwendport gid:cgi_group error_code:0 <row><v>55669</v></row>
<59118.974539>ctlmgr:msg from luacgi5507: T from:luacgi5507 to:forwardrules seq:52 sid:0000000000000000 trans-type:set key:settings/rule0/fwip gid:cgi_group error_code:0 <row><v>192.168.178.26</v></row>
<59118.975828>ctlmgr:msg from luacgi5507: T from:luacgi5507 to:forwardrules seq:53 sid:0000000000000000 trans-type:set key:settings/rule0/fw_type gid:cgi_group error_code:0 <row><v>1</v></row>
...Off-Topic Frage an PeterPawn:
Kennst Du Dich mit dem "station_add/station_del" Parameter aus dem wlan UI-Modul aus? Wenn ich das richtig verstehe, wird damit die Public Hotspot (HS2.0) Funktion angesteuert (im Gegensatz zur "private Hotspot", der WLAN-Gastzugangs, Funktion). Führt man "ctlmgr_ctl w wlan settings/station_add 1" (Wert scheint dabei vermutlich egal zu sein, da Write-OP, Hauptsache er ist vorhanden) aus, werden die Instanzen "securitiesX" und "stationsX" (X jeweils für den Instanz-Index und auf einer 7490 2fach (securities) und 4fach (stations)) angelegt und nur teilweise befüllt.
Wenn man das mal mit der Config einer Cable-Box vergleicht, Link auf die Seite kann ich leider nicht einfügen (sind Paste-Bin Links verboten?) anguckt, fehlt die Hälfte. Weißt Du, wie und ob das überhaupt auf einer 7490 vollständig konfigurierbar/nutzbar ist? Eventuell fehlen ja noch Libs o.ä. und es ist eh nicht umsetztbar.
Des Weiteren ist die "ar7.cfg" Sektion "hotspotcfg", im Gegensatz zu der Cable-Box Export-Datei, auf einer 7490 leer. Ist das dazugehörige "ctlmgr Modul" eventuell "hotspotgre"?!?
Gruß,
Edge
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Das mit dem Plugin für den "ctlmgr" könnte hinkommen und auch, daß es in den DSL-Boxen nicht vorhanden ist. Dieses Feature basiert ja auf einem EuroDOCSIS-Standard ... jedenfalls soweit ich weiß. Ich habe keine Provider-Box, mit der man das mal unter die Lupe nehmen könnte und als ich die noch hatte, gab es die Option bei VF/KD (damals noch KDG) noch nicht. Meines Wissens werden die relevanten Tunnel-Parameter ohnehin über SNMP bzw. das config-File gesetzt und ich habe keine Idee, warum AVM das überhaupt in der "ar7.cfg" ablegen will - da ich an der Stelle auch keine Möglichkeiten zu (sinnvollen) Tests habe, ist das ein von mir stark vernachlässigter Bereich der Firmware (zumindest bisher).
Bei der Protokollierung sehe ich, daß die m.E. genau in der Reihenfolge abläuft, wie es beim Setzen in der "/usr/www/avm/internet/port_fw_edit.lua" (irgendwo um Zeile 340 bis 350 herum in der 06.83) auch passiert. Wenn das bei Dir mit "ctlmgr_ctl" nicht in dieser Folge klappen will, liegt das vielleicht daran, daß das mit "box.set_config" vielleicht doch eher als eine Art Transaktion läuft (ist aber auch nur eine Vermutung meinerseits) und irgendwelche Probleme durch abhängige Settings bei der Lua-Version seltener oder gar nicht auftreten. Jedenfalls im Vergleich zur Variante mit einzelnen "ctlmgr_ctl"-Aufrufen, wo das vielleicht alles Schritt für Schritt erfolgt, solange man nicht die neue Syntax auch hier benutzt ... mit der könnte man ja inzwischen mehr als eine Variable setzen in einem Aufruf.
Bei der Protokollierung sehe ich, daß die m.E. genau in der Reihenfolge abläuft, wie es beim Setzen in der "/usr/www/avm/internet/port_fw_edit.lua" (irgendwo um Zeile 340 bis 350 herum in der 06.83) auch passiert. Wenn das bei Dir mit "ctlmgr_ctl" nicht in dieser Folge klappen will, liegt das vielleicht daran, daß das mit "box.set_config" vielleicht doch eher als eine Art Transaktion läuft (ist aber auch nur eine Vermutung meinerseits) und irgendwelche Probleme durch abhängige Settings bei der Lua-Version seltener oder gar nicht auftreten. Jedenfalls im Vergleich zur Variante mit einzelnen "ctlmgr_ctl"-Aufrufen, wo das vielleicht alles Schritt für Schritt erfolgt, solange man nicht die neue Syntax auch hier benutzt ... mit der könnte man ja inzwischen mehr als eine Variable setzen in einem Aufruf.
Wichtig ist es vielleicht noch zu erwähnen das bei den Spielereien in der ar7.cfg bzgl. VoIP Portweiterleitungen das auch der VoIP Daemon läuft. Man muss also auch einen externen VoIP Anbieter in der F!Box eingetragen haben. Dieser VoIP Anbieter kann auch ein Dummy sein und muss nicht funktionieren.
Neueste Beiträge
-
[Problem] 5690 wlan modul- Letzte: genuede
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte- Letzte: stoney
-
Hicom 3500
- Letzte: Robert Mayr
-
wireguard - Fritz.Box_2 hinter Fritz.Box_Master - Fritz!Box 7590 mit FRITZ!OS:7.59
- Letzte: KunterBunter
-
Be.IP hinter Fritzbox Fiber
- Letzte: KunterBunter
-
[Problem] FritzBox 7590 2,4GHz WLAN nur noch sehr sehr schwach
- Letzte: MarkFalk
-
Asterisk und bookworm
- Letzte: Manfred3
