linuxmint / linuxmint/warpinator
KeyError: 'netmask' during the device discovery
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 1.6k
- Forks
- 115
- PR merge metrics
- No merged PRs in 30d
Description
Distribution
6.13.5-artix1-1
Package version
1.8.8
Frequency
Always
Bug description
Warpinator is unable to discover remote devices. When it is ran in the debug mode, an error is shown:
Traceback (most recent call last):
File "/usr/lib/python3.13/threading.py", line 1041, in _bootstrap_inner
self.run()
~~~~~~~~^^
File "src/zeroconf/_services/browser.py", line 811, in zeroconf._services.browser.ServiceBrowser.run
File "src/zeroconf/_services/browser.py", line 730, in zeroconf._services.browser._ServiceBrowserBase._fire_service_state_changed_event
File "src/zeroconf/_services/browser.py", line 740, in zeroconf._services.browser._ServiceBrowserBase._fire_service_state_changed_event
File "src/zeroconf/_services/__init__.py", line 56, in zeroconf._services.Signal.fire
File "src/zeroconf/_services/browser.py", line 305, in zeroconf._services.browser._on_change_dispatcher
File "/usr/lib/warpinator/server.py", line 183, in add_service
if not self.netmon.same_subnet(remote_ip_info):
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
File "/usr/lib/warpinator/networkmonitor.py", line 151, in same_subnet
self.current_ip_info.ip4["netmask"]))
~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'netmask'
To be sure that this was the exact problem, I modified the same_subnet function, to early return with True - and was able to discover the android device.
Steps to reproduce
- Start remote Warpinator instance (in my case Warpinator client)
- Start local instance of Warpinator in debug mode.
- When the local instance of Warpinator discovers the remote device, a
KeyErroris thrown originating fromnetworkmonitor.py:151
Expected behavior
Device discovery works, and I am able to discover devices on my network.
Additional information
No response
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with networkmonitor.py:151 in same_subnet and inspect how current_ip_info.ip4 is populated. Reproduce the discovery failure in debug mode using a remote Warpinator instance, then trace the call from server.py:183 and verify device discovery completes without the KeyError.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100