search

christgau / wsdd

A Web Service Discovery host daemon.
MIT License
841 stars 99 forks source link

v0.6.4 on Ubuntu not discovered by Windows 10 across VLAN #99

Closed toxic0berliner closed 3 years ago

toxic0berliner commented 3 years ago

I'm not finding another issue that matches so I submit mine : I have v0.6.4 running on ubuntu 20.04 installed from repository found in the README.md here.

On my windows10 machine (10.0.30.109) when I hit refresh in the explorer on the Network page, since I disabled netbios, it uses WS-Discovery but it fails to display my ubuntu host (named "printer", 10.0.10.111).

Between these machines I do have an opnSense firewall with an udp broadcast relay working between the 10.0.30.0/24 and 10.0.10.0/24.

Looking at network trafic captured on my windows host, I do see the multicast discovery going out, and even a response coming back, but windows somehow never decides to fetch anything on tcp port 5357...

Here is my full network capture with the filter "udp.port == 3702 or tcp.port == 5357"

ID     Date          SrcIP        DstIP             Prot Len  SrcPort      DstPort     Data
885 2021-04-07 14:33:56,836323  10.0.30.109 239.255.255.250 UDP 666 60795   3702    <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof"><soap:Header><wsa:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</wsa:Action><wsa:MessageID>urn:uuid:12c0e9f2-182b-4458-afab-926713f99b0d</wsa:MessageID></soap:Header><soap:Body><wsd:Probe><wsd:Types>wsdp:Device</wsd:Types></wsd:Probe></soap:Body></soap:Envelope>
886 2021-04-07 14:33:56,841159  10.0.10.111 10.0.30.109 UDP 1289    3702    60795    <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof" xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/10" xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07"><soap:Header><wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</wsa:Action><wsa:MessageID>urn:uuid:48e1c1ae-97ae-11eb-a67c-75bbd9ac5714</wsa:MessageID><wsa:RelatesTo>urn:uuid:12c0e9f2-182b-4458-afab-926713f99b0d</wsa:RelatesTo><wsd:AppSequence InstanceId="1617804429" SequenceId="urn:uuid:48e1c1af-97ae-11eb-a67c-75bbd9ac5714" MessageNumber="5" /></soap:Header><soap:Body><wsd:ProbeMatches><wsd:ProbeMatch><wsa:EndpointReference><wsa:Address>urn:uuid:61380006-5962-5e13-8511-fbbdcb3c852f</wsa:Address></wsa:EndpointReference><wsd:Types>wsdp:Device pub:Computer</wsd:Types><wsd:MetadataVersion>1</wsd:MetadataVersion></wsd:ProbeMatch></wsd:ProbeMatches></soap:Body></soap:Envelope>
887 2021-04-07 14:33:56,899360  10.0.10.111 10.0.30.109 UDP 1289    3702    60795    <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof" xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/10" xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07"><soap:Header><wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</wsa:Action><wsa:MessageID>urn:uuid:48e1c1ae-97ae-11eb-a67c-75bbd9ac5714</wsa:MessageID><wsa:RelatesTo>urn:uuid:12c0e9f2-182b-4458-afab-926713f99b0d</wsa:RelatesTo><wsd:AppSequence InstanceId="1617804429" SequenceId="urn:uuid:48e1c1af-97ae-11eb-a67c-75bbd9ac5714" MessageNumber="5" /></soap:Header><soap:Body><wsd:ProbeMatches><wsd:ProbeMatch><wsa:EndpointReference><wsa:Address>urn:uuid:61380006-5962-5e13-8511-fbbdcb3c852f</wsa:Address></wsa:EndpointReference><wsd:Types>wsdp:Device pub:Computer</wsd:Types><wsd:MetadataVersion>1</wsd:MetadataVersion></wsd:ProbeMatch></wsd:ProbeMatches></soap:Body></soap:Envelope>
888 2021-04-07 14:33:57,068009  10.0.30.109 239.255.255.250 UDP 666 60795   3702    <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof"><soap:Header><wsa:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</wsa:Action><wsa:MessageID>urn:uuid:12c0e9f2-182b-4458-afab-926713f99b0d</wsa:MessageID></soap:Header><soap:Body><wsd:Probe><wsd:Types>wsdp:Device</wsd:Types></wsd:Probe></soap:Body></soap:Envelope>

Looking at my firewall logs, there are no dropped or rejected rules matchng, in fact I do have allow any from 10.0.30.0/24 in place...

So I'm quite puzzeled as to why this is not working.

From the windows 10 machine and using firefox I can even get an error 500 from the ubuntu machine on port 5357 (because GET is not supported because firefox is not meant to do WS-discovery, but network connectivity is there in fact !)

I've checked and this Windows 10 machine is able to detect other Windows10 machines on the 10.0.30.0/24 network, never got it to detect on 10.0.10.0/24 sadly...

I have started a windows 10 VM on the 10.0.10.0/24 VLAN and in fact, it does discover the ubuntu "printer" host running wsdd...

So it's probably something to do with subnets and my firewall, but I can't figure out what : udp-broadcast-relay seems to work as expected, I explicitely enabled rules as described in README.md, I opened way too many in fact I think...

If someone could help me find out what is blocking the discovery process here that would be great !

Thanks in advance !

Well, when I compare the 2 responses, one response from wsdd that is not discovered and one from a windows VM that is properly discovered, the windows VM responds to the same messageid (<wsa:RelatesTo>urn:uuid:d38a5613-0009-4f84-9c3b-df0884f1a942</wsa:RelatesTo>) with the same data, except in the Probematch it adds <wsd:XAddrs>http://10.0.30.113:5357/5031b9ad-0af2-4f30-b8fc-f635c4bc9307/</wsd:XAddrs> and uses metadata version 4 instead of 1.

Maybe wsdd should add XAddrs with 10.0.10.111:5357 to it's answer... Somehow it's not.

Answer from correctly discovered windows10 VM: 

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
               xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
               xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery"

               xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof"

               xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07">
    <soap:Header>
        <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
        <wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</wsa:Action>
        <wsa:MessageID>urn:uuid:72609e36-b5c6-4b7d-a4d9-1e242eac3bdb</wsa:MessageID>
        <wsa:RelatesTo>urn:uuid:d38a5613-0009-4f84-9c3b-df0884f1a942</wsa:RelatesTo>
        <wsd:AppSequence InstanceId="9"
                         SequenceId="urn:uuid:af063743-b0de-486a-b40a-90fc7a6133e0"
                         MessageNumber="6"/>
    </soap:Header>
    <soap:Body>
        <wsd:ProbeMatches>
            <wsd:ProbeMatch>
                <wsa:EndpointReference>
                    <wsa:Address>urn:uuid:5031b9ad-0af2-4f30-b8fc-f635c4bc9307</wsa:Address>
                </wsa:EndpointReference>
                <wsd:Types>wsdp:Device pub:Computer</wsd:Types>
                <wsd:XAddrs>http://10.0.30.113:5357/5031b9ad-0af2-4f30-b8fc-f635c4bc9307/</wsd:XAddrs>
                <wsd:MetadataVersion>4</wsd:MetadataVersion>
            </wsd:ProbeMatch>
        </wsd:ProbeMatches>
    </soap:Body>
</soap:Envelope>

Answer from wsdd that is not discovered : 

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
               xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
               xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery"
               xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex"
               xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof"
               xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/10"
               xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07">
    <soap:Header>
        <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
        <wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</wsa:Action>
        <wsa:MessageID>urn:uuid:c34101c4-97ba-11eb-a67c-75bbd9ac5714</wsa:MessageID>
        <wsa:RelatesTo>urn:uuid:d38a5613-0009-4f84-9c3b-df0884f1a942</wsa:RelatesTo>
        <wsd:AppSequence InstanceId="1617804429"
                         SequenceId="urn:uuid:c34101c5-97ba-11eb-a67c-75bbd9ac5714"
                         MessageNumber="25"/>
    </soap:Header>
    <soap:Body>
        <wsd:ProbeMatches>
            <wsd:ProbeMatch>
                <wsa:EndpointReference>
                    <wsa:Address>urn:uuid:61380006-5962-5e13-8511-fbbdcb3c852f</wsa:Address>
                </wsa:EndpointReference>
                <wsd:Types>wsdp:Device pub:Computer</wsd:Types>
                <wsd:MetadataVersion>1</wsd:MetadataVersion>
            </wsd:ProbeMatch>
        </wsd:ProbeMatches>
    </soap:Body>
</soap:Envelope>
christgau commented 3 years ago

I've checked and this Windows 10 machine is able to detect other Windows10 machines on the 10.0.30.0/24 network, never got it to detect on 10.0.10.0/24 sadly...

I have started a windows 10 VM on the 10.0.10.0/24 VLAN and in fact, it does discover the ubuntu "printer" host running wsdd...

Just to be sure. If you run two Windows machines, one on each VLAN A and B respectively, you are also not able to discover them. Thus, you essentially have the same situation as with wsdd?

There has been a lengthy discussion in #85 on a VLAN setup. The discussion ended with the conclusion that Windows generally does not accept WSD replies from a non-local network, i.e. a network that the receiving host is not attached to. This makes sense since the protocol is intended for usage in local networks. Your observation would confirm that again.

Well, when I compare the 2 responses, one response from wsdd that is not discovered and one from a windows VM that is properly discovered, the windows VM responds to the same messageid (urn:uuid:d38a5613-0009-4f84-9c3b-df0884f1a942</wsa:RelatesTo>) with the same data, except in the Probematch it adds http://10.0.30.113:5357/5031b9ad-0af2-4f30-b8fc-f635c4bc9307/</wsd:XAddrs> and uses metadata version 4 instead of 1.

The metadata version is something the WSD host decides for and it does not need to be same across different hosts.

Maybe wsdd should add XAddrs with 10.0.10.111:5357 to it's answer... Somehow it's not.

It is a decision of the WSD implementation to include the transport address (XAddr) in a ProbeMatch message or not. One can include the address to speed up the discovery process but it is not a requirement.

toxic0berliner commented 3 years ago

Thanks for the quick reply! I fear indeed that you are right and windows is simply ignoring this as it's from a network it's not attached to. Discovery works between windows and wsdd when on the same network, and when on different networks, well neither wsdd not another windows 10 is being discovered...

So there's no bug here.

I'm disappointed in windows and will try to find some other solution... Netbios did work in the past...

I found lots of references to a ws-discovery proxy in the documentation but no actual implementation... I was hoping it would allow to get one step further and call a resolve on the proxy, but not even sure windows 10 would try the next step in 5cp when it'll see that the xaddr is not in the current network...

christgau commented 3 years ago

So there's no bug here.

Alright! I take that one and close the issue 😉

I found lots of references to a ws-discovery proxy in the documentation but no actual implementation...

Yes, indeed. I am also not aware of a working implementation.