Output of extport range is truncated in show command

[bug-ware]

Hello,

port forwardings may expose multiple external ports in a range which are mapped to a range of internal ports starting with the given intport. This means while intport is only one integer, export may be a range, e.g.,

8 yes Service 0.0.0.0:5058-5059 TCP 192.168.178.99:5058

I propose to change the column output of show command: techo --begin "4r 4 23 20 4 25" instead of techo --begin "4r 4 26 17 4 25"

What about enabling/disabling/etc such port forwardings? I think an extport range will not be handled/accepted by the script, but throws an error. Is it needed to change this, too, and what does the FritzBox expect to get in the TR64 call: a range or the first port of the range?

Thanks and best regards!

[MarcusRoeckrath]

Hi,

to change the width of the columns is a possibility. Because the eislib restricts the output to 80 chars, I have to decide, which part have to be truncated. Maybe it is a better idea to give the port more place.

If you want to see the complete output, you have to call the TR-064-Funktion, which is possible with this script:

1. Create Files for each TR64-Function on your fritzbox:

fbtr64toolbox.sh createsoapfiles

This will create around 500 files depending on typ and firmware version of your box.

2. Run the function with the script:

To read out a port mapping there exists three functions:

igd2desc.xml.igd2connSCPD.xml.GetGenericPortMappingEntry_2 (1) tr64desc.xml.wanpppconnSCPD.xml.GetGenericPortMappingEntry_1 (2) tr64desc.xml.wanipconnSCPD.xml.GetGenericPortMappingEntry_1 (3)

The first one should work on all types of fritzboxes, the others on fritzboxes connected via PPPoE (2) or via IP network (3) to the internet.

Because these control files needs an input (number of the mapping in the fritzbox port mapping list), you can call the control files in the following way:

fbtr64toolbox.sh mysoaprequest --SOAPparameterlist "number,"

(see descriptions in the control file; number should be 7 in your case) which gives complete SOAP response on the console.

Adding "--SOAPsearch all" filters the output in a better readable way.

I dont think, that TR64 functions for port mapping allow ranges!

In https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanipconnSCPD.pdf look at page 6, where the data type of externalport and internalport is described: ui2 (1-65535)! There is no way for me to deal with a range. If you test and proof, that the AVM documentation is not correct, I can enable ranges for the port value. If you are familiar with script programming, you can change or disable the parameter check temporarily.

A word to deleteing port mappings: Maybe since firmware 7.2x the fritzboxes TR64 protocol isn't handling deletion correct, causing weird mapping in the web interface.

Better enabling or disabling a mapping via TR64 instead of deleting an existing port mapping.

It seams that TR64 does not give all possibilities which are existing in the web interface.

Marcus

[MarcusRoeckrath]

Hi,

to test, if adding a port mapping with ranges will work, you can use

igd2desc.xml.igd2connSCPD.xml.AddPortMapping_2 (all connection types) igddesc.xml.igdconnSCPD.xml.AddPortMapping_1 (all connection types) tr64desc.xml.wanipconnSCPD.xml.AddPortMapping_1 (ip connection) tr64desc.xml.wanpppconnSCPD.xml.AddPortMapping_1 (ppp connection)

The parameter for the port forwarding ha to e given in the control file directlx or via --SOAPparameterlist "value,value,...," on the command line in the same sequence they appear in the data lines of the control file.

Marcus

[MarcusRoeckrath]

Hi,

techo --begin "4r 4 23 20 4 25" instead of techo --begin "4r 4 26 17 4 25"

Whats with this settings:

techo --begin "4r 4 26 20 4 22"

Marcus

[MarcusRoeckrath]

Hi,

I looked into the port forwaring page of the fritzbox web interface.

There you can define a port range for the local target while on tr64 this seams to be reported on the remote ports.

It seams that tr64 and web interface are not congruent anymore and it has to be tested whether port forwardings could be configured via tr64 on newer firmwares (7.2x+?).

Marcus

[bug-ware]

Hello,

techo --begin "4r 4 26 20 4 22"

well let's do the math for IPv4: 4x(3 digits) + 3x a point + colon + 5x digits for the port = 21. So yes, this should be fine.

Best regards.

[bug-ware]

I looked into the port forwaring page of the fritzbox web interface. There you can define a port range for the local target

I can confirm that in my GUI you can enter the port range for the local port and the external range is calculated with giving only the first port. You can see the used external range, when editing a port range entry. The behaviour is the same for two boxes with with version 7.29.

while on tr64 this seams to be reported on the remote ports. Yes, this is true for me as well.

It seams that tr64 and web interface are not congruent anymore and it has to be tested whether port forwardings could be configured via tr64 on newer firmwares (7.2x+?).

Well, I can't say if they are not congruent. Both ways to report assume that the range is on both ends: int. and ext. Otherwise it won't work anyway. Since the range seems to be always linear and continuous, I think in principle both ways express the same information, isn't? I would assume, the creation with TR64 would be done like it is reporting.

In https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanipconnSCPD.pdf look at page 6, where the data type of externalport and internalport is described: ui2 (1-65535)!

But as you cited, both expect a single value, right? Did it happen, that the documentation was just wrong?

[MarcusRoeckrath]

techo --begin "4r 4 26 20 4 22"

well let's do the math for IPv4: 4x(3 digits) + 3x a point + colon + 5x digits for the port = 21. So yes, this should be fine.

New version uploaded.

Marcus

[MarcusRoeckrath]

Hello,

Am Montag, 21. August 2023 20:02 schrieb bug-ware:

I looked into the port forwaring page of the fritzbox web interface. There you can define a port range for the local target

I can confirm that in my GUI you can enter the port range for the local port and the external range is calculated with giving only the first port. You can see the used external range, when editing a port range entry. The behaviour is the same for two boxes with with version 7.29.

while on tr64 this seams to be reported on the remote ports.

Yes, this is true for me as well.

It seams that tr64 and web interface are not congruent anymore and it has to be tested whether port forwardings could be configured via tr64 on newer firmwares (7.2x+?).

The problem is, on which part, internal port or external port, does the tr64 functions expects a range.

While it reports a range, other than the web gui, on the remote site this could assumpt that, if a range is supported as parameter, the external parameter of the tr64 function should accept a range.

I`m not using port forwardings so that I can't test them.

It's your turn to test.

To use ranges with the script for extport and intport you have to deactivated the checkings:

Change the if clauses in lines 2054 and 2068 to

if [ -n "${1}" ]

and try if the functions works fine when entering things like 234-235 or so.

Or use the mysoaprequest command as described above in this thread.

In https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wan ipconnSCPD.pdf look at page 6, where the data type of externalport and internalport is described: ui2 (1-65535)!

But as you cited, both expect a single value, right? Did it happen, that the documentation was just wrong?

Maybe avm have never corrected the documentation when enhancing the features of various firmwares.

Using --verbose or --debugfb (lots of debug output) on command line paramter will give us detailed output which you can email me.

-- Gruß Marcus

[MarcusRoeckrath]

It has to be tested, whats happen if a range is given for both, local and remote port.

[MarcusRoeckrath]

After testing I can say that the official documentation is correct and TR-064 function AddMapping does not allow port ranges for ExternalPort or InternalPort. The documentation from the upnp standardization committee says also that this parameters are unsigned integers.

If you want to enable/disable a port range you have to set up each forward seperately.