Not working on asuswrt/merlinwrt

[siborg]

Thanks for the module it's excellent and it does what is says on the tin! It works fine on my desktop but fails to work in python3 environment on my home router (running asuswrt/mertinwrt) with entware. The module installs fine with easy-install but when trying to run the simple on/off switch operation it fails the mac discovery with the following errors:

Traceback (most recent call last):
  File "/opt/bin/spoff", line 3, in <module>
    displays = S20("192.168.1.89")
  File "/opt/lib/python3.5/site-packages/orvibo-1.1.1-py3.5.egg/orvibo/s20.py", line 137, in __init__
  File "/opt/lib/python3.5/site-packages/orvibo-1.1.1-py3.5.egg/orvibo/s20.py", line 187, in _discover_mac
orvibo.s20.S20Exception: Couldn't discover 192.168.1.89

The actual script I am running is trivial:

``

!/opt/bin/python3

from orvibo.s20 import S20, discover displays = S20("192.168.1.89") if displays.on == False: print("Switching monitors extension on") displays.on = True else: print("Switching monitors studio extension off") displays.on = False ``

It probably has to do with the platform:

Kernel is 2.6.36.4 and is is running on arm-hf

[HankB]

I do not think this has anything to do with the router but something to do with the OS. It works fine on my laptop running Manjaro but has the same problem running (IIRC) Linux Mint. Or maybe that's Ubuntu Mate. (Same laptop, dual boot.) It also runs on my file server running Debian Jessie.

I'm working on the same functionality using Go and it has the same problem so it's not even a language issue but probably relates to the network stack or a library shared between Go and Python. The discovery function depends on UDP broadcast so when I get around to it, that's the first place I'll look.

On Wed, Dec 7, 2016 at 7:30 AM, siborg notifications@github.com wrote:

Thanks for the module it's excellent and it does what is says on the tin! It works fine on my desktop but fails to work in python3 environment on my home router (running asuswrt/mertinwrt) with entware. The module installs fine with easy-install but when trying to run the simple on/off switch operation it fails the mac discovery with the following errors:

Traceback (most recent call last): File "/opt/bin/spoff", line 3, in displays = S20("192.168.1.89") File "/opt/lib/python3.5/site-packages/orvibo-1.1.1-py3.5.egg/orvibo/s20.py", line 137, in init File "/opt/lib/python3.5/site-packages/orvibo-1.1.1-py3.5.egg/orvibo/s20.py", line 187, in _discover_mac orvibo.s20.S20Exception: Couldn't discover 192.168.1.89

The actual script I am running is trivial:

!/opt/bin/python3 from orvibo.s20 import S20, discover displays =

S20("192.168.1.89") if displays.on == False: print("Switching monitors extension on") displays.on = True else: print("Switching monitors studio extension off") displays.on = False

It probably has to do with the platform:

Kernel is 2.6.36.4 and is is running on arm-hf

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/happyleavesaoc/python-orvibo/issues/8, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLOfqIpngzfiGBAfC7BspT8JLjAVkC4ks5rFrT7gaJpZM4LGl88 .

-- '03 BMW F650CS - hers '98 Dakar K12RS - "BABY K" grew up. '93 R100R w/ Velorex 700 (MBD starts...) '95 Miata - "OUR LC" polish visor: apply squashed bugs, rinse, repeat Beautiful Sunny Winfield, Illinois

[happyleavesaoc]

Make sure your firewall allows you to receive UDP broadcasts on port 10000. That's the most likely reason for failure.

[siborg]

I will double check. I am actually having problems running it on the firewall/router. However, with directly attached interfaces on the LAN, it should not matter. If it tries broadcast on all interfaces(including WAN) then the firewall possibly might be the issue.

[siborg]

I can confirm it is the firewall. Although I cannot disable it as it is my home router. I have modified lines 75 and 292 in s20.py within the egg package to use my LAN broadcast address rather than 255.255.255.255. After this modification, the code runs without an issue.

[happyleavesaoc]

Good to know. A more robust change would be to have discover take a broadcast address (defaulting to 255.255.255.255). That way it would be flexible for either use case. I'd welcome a PR that did that (along with a note in the readme).

[siborg]

I am not really a programmer. Just got a bit of intuition that's all but I'll see what can be done. No promises though.

[HankB]

Finding broadcast addresses in Python (and w/out hacks such as having to edit /etc/hosts) is not so trivial. It turns out that someone has written a module that can do that. The module is 'netifaces' and I am wondering how the 'boss' here would feel about adding that dependency to this project?

I also found another cool thing (totally unrelated to this issue) about the Orvibo. If you google the name it uses to identify itself you can find a data sheet for the WiFi chip (High Flying) and that names a bunch of AT commands. There is one you can use to alter the default ID. My Asus router adds these IDs to it's DNS lookup tables and I can then access these devices by name instead of IP address. (I don't have the link handy - main development machine is down at the moment.)

[happyleavesaoc]

If I got a PR that used netifaces to discover the appropriate broadcast address, I'd certainly merge it.

[siborg]

I think it could be implemented in a much simpler way. You can either use private IP address classes (as per RFC1918) and their appropriate netmask (so for Class A 255.0.0.0.0, Class B 255.255.0.0 and for Class C 255.255.255.0) or, keep 255.255.255.255 but add an optional netmask parameter to the s20 class.