Window not seeing service but Liinux does with `avahi-publish` about mdns-sd

[dalepsmith]

Yes, it is working here at the office. Wired Ethernet. Subnet is 172.17.9.0/23 Sent from my iPhone... Beware of typos!

…

On Apr 25, 2023, at 9:54 AM, Dale Smith ***@***.***> wrote: I'll be in the office tomorrow (Wed 26) to retest.

[dalepsmith]

Yes. Here is a a log. The Debian Guest vm publishing a _foo._tcp service, the log taken on the Windows Host system.

debug-log.txt

[keepsimple1]

I tried this with a Raspberry Pi running Linux and then a Windows 11 machine. With the example query program I was not able to reproduce the issue. (i.e. it worked)

C:\Users\keeps\work\mdns-sd (main)>  cargo run --example query _http._tcp
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target\debug\examples\query.exe _http._tcp`
At 452.3µs : Received other event: SearchStarted("_http._tcp.local. on addrs [192.168.0.112]")
At 330.4719ms : Received other event: ServiceFound("_http._tcp.local.", "mdns-bug2._http._tcp.local.")
At 330.9278ms: Resolved a new service: mdns-bug2._http._tcp.local. IP: {192.168.0.109} TXT properties: TxtProperties { properties: [TxtProperty {key: "path", val: Some("/")}] }

Could you please try to run the example query on Windows and see if it can find the service? If not, is it possible to add a simple logger to capture the debug log?

Not sure what's happening, but it's probably related to ordering of received packets? Or maybe ordering of records in a packet?

There was an issue with the ordering of records in a packet before. Now it should be fine as we always check for PTR record first. There is one case when the records are separated into multiple packets and PTR comes in the later packets, we might have issue there. (btw, I'm looking into refactoring this part of code, so very interested in learning possible issues in its current form).

[dalepsmith]

I have not yet run the example query on Windows, but I will today (need to install Rust dev environment there). I now suspect the problem I'm is virtual machine / network iface related. The failing case is window machine on wifi at my home doing mdns browsing, and ti's failing to see the avahi-publish running in a Linux vm with the network iface in bridged mode. It *does* see publishes from other machine on my local net. Both via avahi-publish and by config files in /etc/avahi/services. When I have the same window machine in the office, it's wired into Ethernet, and then it *does* see the avahi-publish from the Linux vm. The vm is vmware workstation player running Debian Stable.

…

-Dale

On 4/19/23, keepsimple1 ***@***.***> wrote: I tried this with a Raspberry Pi running Linux and then a Windows 11 machine. With the example query program I was not able to reproduce the issue. (i.e. it worked) ``` C:\Users\keeps\work\mdns-sd (main)> cargo run --example query _http._tcp Finished dev [unoptimized + debuginfo] target(s) in 0.05s Running `target\debug\examples\query.exe _http._tcp` At 452.3µs : Received other event: SearchStarted("_http._tcp.local. on addrs [192.168.0.112]") At 330.4719ms : Received other event: ServiceFound("_http._tcp.local.", "mdns-bug2._http._tcp.local.") At 330.9278ms: Resolved a new service: mdns-bug2._http._tcp.local. IP: {192.168.0.109} TXT properties: TxtProperties { properties: [TxtProperty {key: "path", val: Some("/")}] } ``` Could you please try to run the example query on Windows and see if it can find the service? If not, is it possible to add a simple logger to capture the debug log? > Not sure what's happening, but it's probably related to ordering of > received packets? Or maybe ordering of records in a packet? There was an issue with the ordering of records in a packet before. Now it should be fine as we always [check for PTR record first](https://github.com/keepsimple1/mdns-sd/blob/3aab8d7f4614d4e53eefecb5b96687f53ed44e33/src/service_daemon.rs#L1325). There is one case when the records are separated into multiple packets and PTR comes in the later packets, we might have issue there. (btw, I'm looking into refactoring this part of code, so very interested in learning possible issues in its current form). -- Reply to this email directly or view it on GitHub: #106 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[dalepsmith]

Ok! Running the example query on windows shows the same thing.
Does not see services published from within the vm,
but does see service published on the local net.

The Linux the vm sees services published on the local net.
Other devices on the local net see the things published by the vm.

So the only failure is with with windows host and the linux guest.
On vmware. I don't remember this happening with openbox. But then I always used openbox wired.

Next I need to see if using a wired connection makes any difference.
-Dale

[dalepsmith]

query.txt
foo-query.zip
Attached is the example query console output and a zipped wireshark packet capture of the service being removed and then added.

It looks to me like the packet trace has the right stuff in it, but maybe there is something I'm missing...

[keepsimple1]

Thank you a lot for reproducing the issue and the captures. I didn't find obvious culprit yet. Will need to bring up a similar setup to try it out.

When I have the same window machine in the office, it's wired into Ethernet, and then it does see the avahi-publish from the Linux vm.

In this success case, is the vm network iface also in bridged mode, or not?

[dalepsmith]

Yes also in bridged mode. The vm config is identical. The difference is the host network connection. Could it be a difference in "trust"? Like Corporate lan allows packets that are blocked/filtered in my home wifi?

[keepsimple1]

I tried in a setup of Windows 11 (WiFi home network) and VMware player Debian 11.6 stable, with bridged network iface. But was not able to reproduce the issue. I plan to add a logger for example code so that it's easier to capture debug logs.

cargo r --example query _http._tcp
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target\debug\examples\query.exe _http._tcp`
At 410.7µs : Received other event: SearchStarted("_http._tcp.local. on addrs [192.168.70.1, 192.168.0.112, 192.168.138.1]")
At 48.877ms : Received other event: ServiceFound("_http._tcp.local.", "Service._http._tcp.local.")
At 49.1775ms: Resolved a new service: Service._http._tcp.local. host: debian-116.local. port: 8080 IP: {192.168.70.128} TXT properties: TxtProperties { properties: [TxtProperty {key: "path", val: Some("/")}] }

Btw, I was wondering if it's related to the fact you had another network (10.x.x.x) in query.txt. Will look into that part...

>cargo run --example query _foo._tcp
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target\debug\examples\query.exe _foo._tcp`
At 201.7µs : Received other event: SearchStarted("_foo._tcp.local. on addrs [192.168.1.245, 10.255.254.20, 192.168.244.1, 192.168.229.1]")
At 1.0052215s : Received other event: SearchStarted("_foo._tcp.local. on addrs [192.168.1.245, 10.255.254.20, 192.168.244.1, 192.168.229.1]")
At 3.0212461s : Received other event: SearchStarted("_foo._tcp.local. on addrs [192.168.1.245, 10.255.254.20, 192.168.244.1, 192.168.229.1]")
At 7.034332s : Received other event: SearchStarted("_foo._tcp.local. on addrs [192.168.1.245, 10.255.254.20, 192.168.244.1, 192.168.229.1]")
At 15.0611615s : Received other event: SearchStarted("_foo._tcp.local. on addrs [192.168.1.245, 10.255.254.20, 192.168.244.1, 192.168.229.1]")
At 31.0706769s : Received other event: SearchStarted("_foo._tcp.local. on addrs [192.168.1.245, 10.255.254.20, 192.168.244.1, 192.168.229.1]")
error: process didn't exit successfully: `target\debug\examples\query.exe _foo._tcp` (exit code: 0xc000013a, STATUS_CONTROL_C_EXIT)

[dalepsmith]

I'll be in the office tomorrow (Wed 26) to retest.

[keepsimple1]

I created a PR to add logging in the examples. Is it possible to run the query example with this logging support in your home network to reproduce the issue and collect the debug logs? (Or to find out what debug logs are missing?)

[keepsimple1]

It is odd that there are not PTR or SRV, TXT records received, but only an Address record received:

[2023-04-26T23:58:54Z DEBUG mdns_sd::dns_parser] read_header: id 0, 0 questions 1 answers 0 authorities 0 additionals
[2023-04-26T23:58:54Z DEBUG mdns_sd::dns_parser] read_questions: 0
[2023-04-26T23:58:54Z DEBUG mdns_sd::dns_parser] read_others: 1
[2023-04-26T23:58:54Z DEBUG mdns_sd::dns_parser] DnsAddress { record: DnsRecord { entry: DnsEntry { name: "192-168-1-103.local.", ty: 1, class: 1, unique: true }, ttl: 3600, created: 1682553534969, refresh: 1682556414969 }, address: 192.168.1.103 }

Is this address 192.168.1.103 belonging to the published service on Linux?

[dalepsmith]

That machine (today) is currently 192.168.1.166. Not sure what is was when I made the log. Ok, 103 is an Amazon Fire on the same network. Cute how the hostname is "192-168-1-103" (note the '-'s) It *must* be some kind of firewall settings in Windows. I just tried connected via Ethernet instead of WiFi and things are working perfectly. It's still odd that I get browse results from other devices on the subnet, but not from the vm on the same subnet. I guess that means we can close this issue. Thank you for helping me work through it! I wonder is there is some setting I can change?

[dalesmith3]

Closing

[keepsimple1]

It's a curious case. Thanks for spending time on this. If possible, we could try a couple of things (with the wi-fi error case):

1. wireshark: the previous wireshark capture seems to be on the VM? as the source IPv4 is 192.168.1.166 only. What if we do the capture on Windows side as well? and compare the difference from the VM capture?

2. Instead of avahi-publish, what if we run mdns-sd in vm to publish? RUST_LOG=debug cargo r --example register _foo._tcp.local. Service on the VM? and compare the debug log from Windows side?

For the firewall, I'm not an expert, and couldn't yet think of particular settings that would cause such behaviors.

(btw, no worries if you don't have bandwidth for this, just some thoughts)