kbr / fritzconnection

Python-Tool to communicate with the AVM Fritz!Box by the TR-064 protocol and the AHA-HTTP-Interface
MIT License
303 stars 59 forks source link

Not working when using DHCP as internet connection #218

Open DanielWeeber opened 2 months ago

DanielWeeber commented 2 months ago

I recently changed from DSL to a DHCP provider. Since then fritzconnection is not working anymore.

I tested with this short script https://github.com/home-assistant/core/issues/114323#issuecomment-2033005126 from @mib1185

from fritzconnection import FritzConnection
from fritzconnection.lib.fritzstatus import FritzStatus

fc = FritzConnection(address="ip", user="admin", password="pw")
fs = FritzStatus(fc)

print(f"get_default_connection_service: {fs.get_default_connection_service()}")
print(f"has_wan_enabled: {fs.has_wan_enabled}")

Output:


get_default_connection_service: DefaultConnectionService(prefix='1', connection_service='WANIPConnection', postfix='1')
Traceback (most recent call last):
  File "/root/fritz/test.py", line 8, in <module>
    print(f"has_wan_enabled: {fs.has_wan_enabled}")
                              ^^^^^^^^^^^^^^^^^^
  File "/root/fritz/lib/python3.11/site-packages/fritzconnection/lib/fritzstatus.py", line 386, in has_wan_enabled
    return self.fc.call_action(self.connection_service, "GetInfo")["NewEnable"]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/fritz/lib/python3.11/site-packages/fritzconnection/core/fritzconnection.py", line 456, in call_action
    return self.soaper.execute(service, action_name, arguments)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/fritz/lib/python3.11/site-packages/fritzconnection/core/soaper.py", line 286, in execute
    return handle_response(response)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/fritz/lib/python3.11/site-packages/fritzconnection/core/soaper.py", line 268, in handle_response
    raise_fritzconnection_error(response)
  File "/root/fritz/lib/python3.11/site-packages/fritzconnection/core/soaper.py", line 191, in raise_fritzconnection_error
    raise exception(message)
fritzconnection.core.exceptions.FritzActionError: UPnPError:
errorCode: 401
errorDescription: Invalid Action
kbr commented 2 months ago

This error is forwarded from the router. According to the log provided at https://github.com/home-assistant/core/issues/114323#issuecomment-2033005126 you are using a FritzBox 7590 but switched from DSL to cable or fiber. The 7590 is a DSL model – did you connect the router to a separate cable/fiber-modem? In this case the FritzBox is not the device providing the WAN-connection.

DanielWeeber commented 2 months ago

Yes, but Deutsche Glasfaser only provides it like that. I use the Fritz!Box as a router though, you get the public ip via DHCP.

kbr commented 2 months ago

DHCP is used for cable/fiber connections, so the router in front of the FritzBox gets the public IP. That's not a problem, because a FritzBox can be savely placed behind another router providing the WAN access. But in this case trying to access WAN information from the FritzBox fails, because it is the wrong device and sends an "Invalid Action" as response.

From an application point of view (like the home-assistant fritz integration) this is a tricky situation: the service and action about WAN information is provided by the FritzBox because the box has a DSL-modem and can be a WAN device, but the action is not supported in case the FritzBox is not the WAN device.

DanielWeeber commented 2 months ago

As the device before the FRITZ!Box does not provide any NAT, hence why the FRITZ!Box does get the public IP I would define it as "WAN Connection". The device before the FRITZ!Box is more a Layer 2 device.

kbr commented 2 months ago

I see your point, but all at all the FritzBox is not the physical WAN-device (the builtin hardware is not used).

DanielWeeber commented 2 months ago

But should it throw an error though? It could just return false.

kbr commented 2 months ago

fritzconnection is not throwing but forwarding the error. That's a subtle difference. So the application (in general the calling code) can act accordingly upon the information that would otherwise be lost.

chemelli74 commented 2 months ago

HI @kbr, is there an API that can help determine this configuration ? So we can handle it properly ?

kbr commented 2 months ago

Hi @chemelli74 ,there is no API so far – you can either do the error-handling on the application side or we can add an API to the library like is_wan_device to indicate whether the device has wan-capabilities and/or is_active_wan_device checking whether the capabilities are in active use. That's my idea so far.

This could make sense as older FritzBoxes may get reused in networks as access points, providing wan-capabilities but no longer used this way. Or, as FTTH gets more common, placed behind a fiber-modem. However, either the error-handling or checking the state must be done by the application. Introducing an API, it would mainly be the question how to design this API the most useful way.

chemelli74 commented 2 months ago

I totally agree on your idea. Would be cool to have a "is_wan_device" That way we can manage all the known scenarios

mib1185 commented 2 months ago

I do not agree that a Fritz!Box isn't counted as a WAN device, if it is not using it's internal xDSL modem. Further the Fritz!Box does also have a dedicated WAN Ethernet port to be flexible in choice of the used WAN scenario and setup. A WAN device is that one, which provides the layer 3 connection between your LAN and the WAN (eq. a router with at least source/hide NAT for outgoing connections behind a public IP address). Even if there is another modem in front of it, a modem (per strict definition) is not active on layer 3, but only on layer 2 (you may want to call them a media converter).

Nevertheless, this is still no issue of the fritzconnection lib, since even the tr064 api definition provides common as also specific services for different supported WAN scenarios. I think this is a bug in the Fritz!OS firmware

kbr commented 2 months ago

@mib1185 : Thank you for the comment.

I've checked the sources and there is already a basic API in fritzstatus.py: these are the properties has_wan_support to report whether the device has a layer 3 service, and has_wan_enabled to get information whether there is an active WAN connection.

Meanwhile I've reactivated an older 4020 model that provides a WAN Ethernet port, but has no builtin modem. It reports has_wan_support as True and a call to has_wan_enabled with False. With no connection to the WAN port, that's exactly what to expect – no FritzActionError here.

Regarding this, for me now it feels strange that the 7590 behaves different according to the description given by @DanielWeeber and I tend to the argument of @mib1185 that there could be a flaw in Fritz!OS.

mib1185 commented 2 months ago

We already use has_wan_support and has_wan_enabled in HA to determine if we should create WAN related sensors (eq. sent bytes, max bandwidth, ...) and switches to toggle port-forwardings.

@DanielWeeber Unfortunately, I think the only way forward is, that you report this issue to AVM as a support case - at least they can say if it is "works as designed" or a bug which they should fix 🤞

DanielWeeber commented 2 months ago

Just wrote them a ticket. If I get any reply I will update this ticket here.

mib1185 commented 2 months ago

maybe you encounter the same known issue as mentioned in https://github.com/home-assistant/core/issues/114264#issuecomment-2074784457

liuk4friends commented 2 months ago

Same problem here. My Fritz!Box 7590 (firmware 7.57) is connected to another modem (192.168.1.254) that provides DSL connection to my home. The Fritz!Box 7590 (192.168.188.1) is acting as a router and as a DHCP server for every device at home (some connected by wire and some withwi-fi).

I can't activate the Home Assistant integration and I get the error: UPnPError: errorCode: 401 errorDescription: Invalid action

My system log can be consulted at this link: https://pastebin.com/kUviEXHG

If I understand correctly, my situation, like that of whoever opened this thread, is due to a limitation of the current firmware and we have to wait (and hope) for the ticket opened by @DanielWeeber to lead to an update.

Screenshot 2024-04-28 alle 20 14 57
mib1185 commented 2 months ago

best you can do is to also open an own ticket, so AVM get's noticed, that this issue affects more people 👍

liuk4friends commented 2 months ago

best you can do is to also open an own ticket, so AVM get's noticed, that this issue affects more people 👍

I'm happy to do it but can you help me? I would need the link to the support page and the text to include in the ticket

mib1185 commented 2 months ago

maybe @DanielWeeber has some hints about reporting such issues to AVM?

VEEC023 commented 1 month ago

Problem is fixed in the latest Labor Software: FRITZ!OS: [7.90-113042 BETA]

kbr commented 1 month ago

@VEEC023 : Good news, thank you.

liuk4friends commented 2 weeks ago

Problem is fixed also in the latest Fritz!OS 7.59 for Fritz!Box 7590

DanielWeeber commented 5 days ago

Can confirm its working again