Closed Luni-4 closed 1 month ago
Ah ok, now I can see the communication issue, thanks for telling me how to improve messages!
Well, I will use quotes this time, I hope it will be much clearer
Is your phone even configured to resolve addresses via mDNS lookup?
Yes, it can. My Android version supports that.
can you ping - from your phone - your WIndows and MacOS workstations on the .local domain?
Yes, because I 've run a server on my laptops (Linux, Windows, and MacOS) which implements the mdns-sd crate and I can access, from my phone, to the main server page using the .local
domain.
Can you ping your desktop from the phone by using its .local suffixed name?
The hostname of one of my laptop is konki
. If I ping konki.local
from my phone, I can reach that out.
Can you run avahi-browse -a from your phone or better yet - avahi-resolve?
I've installed Service Browser which implements Bonjour
underlying in order to reply to your question and posted the results as images in addition to the corresponding log
@Luni-4 Argh OK, I should have read this link as to what your Android phone actually implements. They don't have an "mDNS responder", not even an "mDNS queryer" but implement the simplest of all hacks which is called a "one-shot query".
We don't (yet) support in
edge-mdns
replying to those types of queries. It might not be too difficult to add support for this.
Ahh I see now, thanks for your investigation! It would be fantastic to access a C3
even from a smartphone if it would be deemed interesting :)
But in any case, let me know what the outcome of trying to ping your workstations is as well.
Yep, the answer should be in my previous message
Is your phone even configured to resolve addresses via mDNS lookup?
Yes, it can. My Android version supports that.
Only with a "one-shot" query - at least according to their documentation - which we don't support yet, but I'll do a quick fix shortly.
can you ping - from your phone - your WIndows and MacOS workstations on the .local domain?
Yes, because I 've run a server on my laptops (Linux, Windows, and MacOS) which implements the mdns-sd crate and I can access, from my phone, to the main server page using the
.local
domain.
But this should not be necessary, as per my last message. Again - MacOS has a built-in mDNS queryer and resolver (because Bonjour was invented by Mac)
Windows also adopted bonjour out of the box long ago.
Can you ping your desktop from the phone by using its .local suffixed name?
The hostname of one of my laptop is
konki
. If Iping konki.local
from my phone, I can reach that out.
That's what I wanted to know, thanks!
Let's hope it is really the fact that we don't implement a one-shot query, although - if that was the case, we should've seen in the logs of your c3
that is is contacted by your phone (the "reply to" message). And I don't see that at all? :(
Can you run avahi-browse -a from your phone or better yet - avahi-resolve?
I've installed Service Browser which implements
Bonjour
underlying in order to reply to your question and posted the results as images in addition to the corresponding log
Right. Once you do that, the c3 is discovered. BUT, it is discovered by another mDNS resolver, this "Service Browser" thing. And it is somehow not discovered by your "ping" command which uses the underlying one-shot thing...
@Luni-4 OK, I've extended the code to support "one-shot" queries so you can give it another try, but I'm not holding my breath. The fact that we don't see your phone at all in the c3 logs is not a good indicator...
Only with a "one-shot" query - at least according to their documentation - which we don't support yet, but I'll do a quick fix shortly.
Yep, exactly.
But this should not be necessary, as per my last message. Again - MacOS has a built-in mDNS queryer and resolver (because Bonjour was invented by Mac)
Windows also adopted bonjour out of the box long ago.
Ah, sure, as I said I was testing, that's why I've run a personal server, but ok, solved.
That's what I wanted to know, thanks! Let's hope it is really the fact that we don't implement a one-shot query, although - if that was the case, we should've seen in the logs of your
c3
that is is contacted by your phone (the "reply to" message). And I don't see that at all? :(
I cannot understand this part. Can you explain me better the we should've seen in the logs of your c3
statement?
Right. Once you do that, the c3 is discovered. BUT, it is discovered by another mDNS resolver, this "Service Browser" thing. And it is somehow not discovered by your "ping" command which uses the underlying one-shot thing...
Exactly, but my test was to verify whether another mDNS resolver could discover the C3
. If it hadn't worked, it would have been useless going forward, in my opinion. But ok, solved.
@Luni-4 OK, I've extended the code to support "one-shot" queries so you can give it another try, but I'm not holding my breath. The fact that we don't see your phone at all in the c3 logs is not a good indicator...
Thanks a lot! I do not have more time for today, I will try that in two days
That's what I wanted to know, thanks! Let's hope it is really the fact that we don't implement a one-shot query, although - if that was the case, we should've seen in the logs of your
c3
that is is contacted by your phone (the "reply to" message). And I don't see that at all? :(I cannot understand this part. Can you explain me better the
we should've seen in the logs of your c3
statement?
An mDNS resolver like the edge-mdns
thing you are running on the c3 is not simply broadcasting all its data. It only does that once, when it is started (as per the mDNS protocol).
After that, it starts to actively listen on the broadcast addresses if other peers are asking questions. And if they do, then it is re-broadcasting, but is re-broadcasting answers to exactly the questions asked and not all its data (again, according to mDNS).
Now, a one-shot query is a trick where your phone is sending its questions to the standard mDNS bradcast addresses (as we do), but then - because it is not sending them from port 5353 - we are supposed to answer to it "privately", with unicast rather than broadcast. But because it is asking its questions on the broadcast addresses - even though we were not replying to it privately, we should've still seen a
I (43657) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:some-very-large-ephemeral-port
line in the log of the c3, where some-very-large-ephemeral-port != "5353".
... but we don't see that. :(
@Luni-4
Good news. I re-installed "Termux" on my Android, and with the "one-shot" patch I pushed,
If I type:
ping mypc.local
The ping works.
and in the logs I see:
[2024-10-09T19:11:31Z INFO edge_mdns::io] Replying privately to a one-shot mDNS query from [::ffff:192.168.10.199]:46205
HOWEVER: You really have to FIRST start the c3, and only then do the ping mypc.local
command.
If you first try to ping (as I did), the ping will fail (c3 is not running). If you then run the c3 and try to re-ping, the ping will AGAIN fail, because - apparently - the Android implementation is so simple, that it caches the failure.
I had to literally restart my phone to flush this cache...
@Luni-4
Good news. I re-installed "Termux" on my Android, and with the "one-shot" patch I pushed,
If I type:
ping mypc.local
The ping works.
and in the logs I see:
[2024-10-09T19:11:31Z INFO edge_mdns::io] Replying privately to a one-shot mDNS query from [::ffff:192.168.10.199]:46205
@ivmarkov
Yeah! I can reproduce me too! Thanks a lot!
Here's the log:
I (4187) foo_esp: About to run an mDNS responder for our PC. It will be addressable using mypc.local, so try to `ping mypc.local`.
I (4207) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (47387) edge_mdns::io: Re-broadcasting due to mDNS query from [::ffff:192.168.178.1]:5353
I (47387) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (47397) edge_mdns::io: Re-broadcasting due to mDNS query from [::ffff:192.168.178.1]:5353
I (47397) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (107497) edge_mdns::io: Re-broadcasting due to mDNS query from [::ffff:192.168.178.1]:5353
I (107497) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (121827) edge_mdns::io: Replying privately to a one-shot mDNS query from [::ffff:192.168.178.115]:43318
HOWEVER: You really have to FIRST start the c3, and only then do the
ping mypc.local
command.If you first try to ping (as I did), the ping will fail (c3 is not running). If you then run the c3 and try to re-ping, the ping will AGAIN fail, because - apparently - the Android implementation is so simple, that it caches the failure.
I had to literally restart my phone to flush this cache...
Ugh, I had to restart my phone as well. Is it possible to find a workaround for this bad problem in your opinion?
There's another problem, if I stop cargo run
with CTRL-C
and then launch cargo run
again, I cannot ping mypc.local
from my phone anymore, even if the previous pings had worked perfectly. If Android caches the failure, it should also cache the success.
@Luni-4 Good news. I re-installed "Termux" on my Android, and with the "one-shot" patch I pushed, If I type:
ping mypc.local
The ping works. and in the logs I see:
[2024-10-09T19:11:31Z INFO edge_mdns::io] Replying privately to a one-shot mDNS query from [::ffff:192.168.10.199]:46205
@ivmarkov
Yeah! I can reproduce me too! Thanks a lot!
Here's the log:
I (4187) foo_esp: About to run an mDNS responder for our PC. It will be addressable using mypc.local, so try to `ping mypc.local`. I (4207) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353 I (47387) edge_mdns::io: Re-broadcasting due to mDNS query from [::ffff:192.168.178.1]:5353 I (47387) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353 I (47397) edge_mdns::io: Re-broadcasting due to mDNS query from [::ffff:192.168.178.1]:5353 I (47397) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353 I (107497) edge_mdns::io: Re-broadcasting due to mDNS query from [::ffff:192.168.178.1]:5353 I (107497) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353 I (121827) edge_mdns::io: Replying privately to a one-shot mDNS query from [::ffff:192.168.178.115]:43318
HOWEVER: You really have to FIRST start the c3, and only then do the
ping mypc.local
command. If you first try to ping (as I did), the ping will fail (c3 is not running). If you then run the c3 and try to re-ping, the ping will AGAIN fail, because - apparently - the Android implementation is so simple, that it caches the failure. I had to literally restart my phone to flush this cache...Ugh, I had to restart my phone as well. Is it possible to find a workaround for this bad problem in your opinion?
You can work on the Android code-base and figure out a more intelligent caching policy! Applying common sense, I don't see a way to fix this on the mDNS responder side. :-)
There's another problem, if I stop
cargo run
withCTRL-C
and then launchcargo run
again, I cannot pingmypc.local
from my phone anymore, even if the previous pings had worked perfectly. If Android caches the failure, it should also cache the success.
This is not what I see on my end:
ping
is not running) and then run it again, and then do ping the mDNS responder, ping worksWhich proves that that Android IS caching the success too. It is another topic if the "failure" is indeed caching forever (success caching seems to expire after 5 minutes or so).
You can work on the Android code-base and figure out a more intelligent caching policy! Applying common sense, I don't see a way to fix this on the mDNS responder side. :-)
Ok, this is what I wanted to figure out. You cannot find a workaround for this problem on the edge-mdns
side in any way, you just have to fiddle with Android settings or contribute to the Android codebase. Solved this question from my side.
This is not what I see on my end:
* If I stop the mDNS responder (while `ping` is not running) and then run it again, and then do ping the mDNS responder, ping works * More importantly: If I assign "mypcl.local" to be 127.0.0.1, then run the responder, and the first ping resolves it (to 127.0.0.1), subsequent pings **continue** to work even if the responder is stopped.
Which proves that that Android IS caching the success too. It is another topic if the "failure" is indeed caching forever (success caching seems to expire after 5 minutes or so).
Ok, for the second observation, but your first observation does not work on my side right now. Anyway, this is not a problem. I can implement a mDNS resolver on my Android application and use that to resolve the address, so I do not need to directly use Android stuff.
For me, we can close this issue now, since it works everywhere. I still have Wi-Fi problems right now, but they are more related to esp-idf-svc
than this repository. Thanks a lot for your help and your explanations, very appreciated! :)
@ivmarkov
Is it possible to publish a new edge-mdns
version after all of these changes?
Yes - in a couple of weeks or so.
My issue could be caused by my lack of experience and knowledge, so sorry in advance if that's the case.
I can build the
mdns-responder
example onesp32c3
, but I cannot flash and run it because I'm getting the following error repeatedly:This is my
Cargo.toml
:This is my
config.toml
:This is my code:
Thanks in advance for your help!