Rebase PR #188 (Fixes for OS X) with resolved conflicts #270
Conversation
* Listen on respond_sockets in addition to listen_socket * Do not bind to respond_sockets in multicast mode Without either of these changes, I get no replies at all when browsing for services using the browser example. I'm on a corporate network, and when connecting to a different network it works without these changes, so maybe it's something about the network configuration in this particular network that breaks the previous behavior. Unfortunately, I have no idea how this affects other platforms, or what the changes really mean. However, it works for me and it seems reasonable to get replies back on the same socket where they are sent.
|
I think the failures are due to the respond sockets not being assigned port 5353. Now their assigned a random port by the OS and, when a question gets sent through them it's received by the listening socket from a source port different than 5353 and this condition (from https://github.com/jstasiak/python-zeroconf/blob/beff99897f0a5ece17e224a7ea9b12ebd420044f/zeroconf/__init__.py#L1388) elif msg.is_query():
# Always multicast responses
if port == _MDNS_PORT:
self.zc.handle_query(msg, None, _MDNS_PORT)doesn't trigger and a query gets ignored, which is followed by no answer being sent and the whole listener integration test crashes. It's time for me to reread RFC 6762 in regards to sockets, interfaces and port numbers. |
|
From RFC 6762: |
This is an attempt to still send packets with the correct source port yet not bind to INADDR_ANY so that the original use case of this pull request is taken care of.
It has some dirty log.debug changes too, I'll clean it up once it works. Also it's a tangled mess of tuples now, I'll also deal with that when there's time to do it.
When there is nothing to write, we don't need to warn about not making progress.
|
@estyrke (or is it @estyrke-axis?) can you test this branch? I massaged it to the state that passes the test suite on Travis CI and my manual tests on both Mac and Linux were successful. I'm actually thinking about removing the listening socket totally since we handle packets read from the respond sockets now, but I'll leave it for later. |
|
Hi @jstasiak, sorry for the late reply! I made the commits using my work email, but created the PR using my personal github account, I guess that's the cause of the mixup. Unfortunately, I haven't been able to test this branch in the original network where I had the problem, due to working from home at the moment. And to be honest, I don't even really remember what the specifics of the original problem were. This branch does work in my home network, but then again, so does the master branch... |
|
@estyrke-axis so I think I'll merge this as long as it doesn't break currently working usecases and, if in the future you discovered something's yet to be done, we can revisit this. |
|
This has been released in 0.28.0. |
No description provided.