72_FRITZBOX.pm ab Version 08.00.00

[passibe]

Ich dachte, dass liegt daran, dass ich die Cable als Repeater benutzte.

Nein, das läuft bei mir auch auf einen 401 hinaus (aber Invalid Action), siehe hier ganz oben: https://forum.fhem.de/index.php?topic=141872.msg1343426#msg1343426

Die Kabelbox wählt sich ja gerade nicht per PPPoE ein, deshalb gibt es bei "pppcon" auch nichts zu holen.
Weil die Abfrage in Zeile 6585 deshalb einen Error schmeißt, wird im darauffolgenden if die Variable $tryInfoUPNP = 1 gesetzt und das anlegen der Readings in den Zeilen 6606–6623 wird übersprungen; somit auch box_mac_Address, das nur dort angelegt wird. (Bitte korrigieren, wenn ich falsch liege, aber so lese ich das.)

Für die anderen Readings, die in den Zeilen 6606–6623 gesetzt werden, z.B. "box_last_connect_err", ist das nicht schlimm, die werden nämlich unten nochmal per UPNP abgefragt. box_mac_Address aber nicht. Da müsste das noch eingebaut werden. Nur die gibt es – soweit ich sehe – nicht über UPNP.

Am elegantesten wäre es deshalb eigentlich, wenn man die Abfrage zwischen Zeilen 6648 und 6712 auf TR-064 umstellt, ähnlich wie ich das in meinem Patch gemacht habe. Dort kriegt man nämlich alles, was Zeilen 6648–6712 aktuell machen auf einmal und zusätzlich noch die MAC-Adresse:

Code Auswählen Erweitern

get <NAME> tr064Command WANIPConnection:1 wanipconnection1 GetInfo

---
Service='WANIPConnection:1'   Control='wanipconnection1'   Action='GetInfo'
----------------------------------------------------------------------
$VAR1 = {
          'GetInfoResponse' => {
                                 'NewConnectionType' => 'IP_Routed',
                                 'NewDNSOverrideAllowed' => '1',
                                 'NewEnable' => '1',
                                 'NewPossibleConnectionTypes' => 'IP_Routed, IP_Bridged',
                                 'NewConnectionTrigger' => 'OnDemand',
                                 'NewExternalIPAddress' => '2a02:xxxx:xxx::xxx',
                                 'NewMACAddress' => '48:5D:35:xx:xx:xx',
                                 'NewUptime' => '2457037',
                                 'NewDNSEnabled' => '1',
                                 'NewName' => 'internet',
                                 'NewLastConnectionError' => 'ERROR_NONE',
                                 'NewDNSServers' => '2a02:908:2:b::1, 2a02:908:2:a::1',
                                 'NewRSIPAvailable' => '0',
                                 'NewConnectionStatus' => 'Connected',
                                 'NewRouteProtocolRx' => 'Off',
                                 'NewNATEnabled' => '1'
                               }
        };UPNP bräuchte man dann nur noch für die IPv6-Dinge in Zeilen 6720–6788.

die MAC der FritzBox kann man auch in den Readings mac_ finden

Ah, das habe ich jetzt auch gesehen, stimmt natürlich. Der Einheitlichkeit halber sollte box_mac_Address mE aber auch bei den Kabelboxen gesetzt werden (oder man entfernt es auch bei DSL, etc.).

---

Hm, ist das die richtige IPv4? Die IP kommt aus dem data.lua für die die Seite Internet/Online-Monitor/Verbindungsdetails.

An sich 192.0.0.2 das schon die "richtige" IPv4 für DS-Lite, denn das ist diejenige, die das CPE bei AFTR nutzt (siehe hier für Zitate aus der RFC).
Wirklich viel bringt das Reading also sowieso nicht, allenfalls könnte man einen Check einbauen, dass, wenn in der data.lua "dslite: true" steht, das Reading box_ipv4_Extern erst gar nicht gesetzt wird (dann übrigens auch nicht über NewExternalIPAddress, aktuell in Zeile 6709; scheint aber sowieso von der Abfrage aus data.lua überschrieben zu werden, sonst würde bei mir da nicht 192.0.0.2 stehen, sondern meine IPv6-GUA).

Hier mal ein Auszug meiner data.lua vom netMoni:

Code Auswählen Erweitern

"internet": {
    "box_type": "cable",
    "connections": [
        {
            "active": true,
            "medium_upstream": 52480,
            "downstream": 273920,
            "role": "single",
            "provider": "",
            "ipv4": {
                "ipv6_aftr": "2a02:xxxx::xxxx",
                "connected": true,
                "dns": [...],
                "dslite": true,
                "ip": "192.0.0.2",
                "since": 1747789732
            },
            "ipv6": {
                "ip_lifetime": {
                    "valid": 84420,
                    "preferred": 84420
                },
                "connected": true,
                "dns": [...],
                "ip": "2a02:xxxx:xxx::xxx/64",
                "prefix": "2a02:xxxx:xxx:xxxx::/59",
                "prefix_lifetime": {
                    "valid": 84420,
                    "preferred": 84420
                },
                "since": 1747789731
            },
            "shapedrate": false,
            "medium_downstream": 273920,
            "state": "connected",
            "name": "internet",
            "type": "cable",
            "upstream": 52480,
            "ready_for_fallback": false,
            "connected": true,
            "medium": "cable"
        }
    ]
},

[JoWiemann]

Hallo passibe,

bin jetzt etwas verwirrt. Zum Einen bestätigst Du den Fehler bei

Code Auswählen Erweitern

WANIPConnection:1 wanipconnection1 GetInfo zum Anderen verweist Du aber genau auf diese Änderung.

Grüße Jörg

[passibe]

Hi,

ich habe den Fehler von WANPPPConnection bestätigt – bei WANIPConnection funktioniert alles.

Du hattest ja in #175 zu WANPPPConnection gefragt:

Bei meiner 6660 läuft der Aufruf von

Code Auswählen Erweitern

get <name> tr064Command WANPPPConnection:1 wanpppconn1 GetInfo

Um das zusammenzufassen:
Kabelbox: kein WANPPPConnection, nur WANIPConnection

Deshalb müssen bei Kabelboxen alle Infos über WANIPConnection bezogen werden und nicht über WANPPPConnection.
Sonst bräuchte man auch nicht die doppelte Abfrage mancher Readings, $tryInfoUPNP (vorher $getInfo2cd) und Kommentare wie:

# TR064 with xml enveloap via SOAP request wanipconnection1
# will be done for FritzBox 6[4,5,6][3,6,9][0,1]

Zu box_mac_Address: Wenn die Abfrage von box_mac_Address nur in dem Teil drin ist, der WANPPPConnection abfragt, bringt das bei der Kabelbox nichts, denn WANPPPConnection ist leer (stattdessen müsste WANIPConnection abgefragt werden).

[JoWiemann]

Hi,

ich habe den Fehler von WANPPPConnection bestätigt – bei WANIPConnection funktioniert alles.

Wer lesen kann... Werde ich dann so umsetzen. Danke für den Tritt vors Schienbein.

Grüße Jörg