search

christgau / wsdd

A Web Service Discovery host daemon.
MIT License
814 stars 98 forks source link

Server appears in network neighborhood, but cannot connect (unless it is an IP address) #104

Closed octogonz closed 3 years ago

octogonz commented 3 years ago

If I invoke this command:

$ wsdd.py  -i eth1 -n SERVER -w WORKGROUP -4

...then the "SERVER" computer appears under the "Network" view in Windows Explorer. But when I try to browse its shares, Windows says it cannot access the share. 👎

Whereas if I invoke this command:

$ wsdd.py  -i eth2 -n 192.168.3.201 -w WORKGROUP -4

...then the raw IP address is shown in Windows Explorer, and everything works fine. 👍

Without running wsdd.py, I can also manually enter \\192.168.3.201\MyShare in the Windows Explorer address bar, and that works as well. (And obviously if I add SERVER to my drivers/etc/hosts file on the Windows computer, that works too.)

It seems that wsdd.py is not communicating correct IP address to Windows. (?)

How to diagnose this problem? The Samba logs don't show no activity even with log level = 3, as if the client never tried to connect.

I also tried using the -W option for wsdd.py which dumps the SOAP packets. And I do see <wsd:XAddrs>http://192.168.3.201:3702/2f838418-e833-46ef-997a-613d1b515cd9</wsd:XAddrs> but that is referring to the port used by wsdd.py. I can't figure out where in the protocol it tells Windows how to find Samba. (?)

christgau commented 3 years ago

If I invoke this command: ...then the "SERVER" computer appears under the "Network" view in Windows Explorer.

That's everything wsdd should do...

But when I try to browse its shares, Windows says it cannot access the share. 👎

... and this is out of wsdd's scope.

Whereas if I invoke this command ...then the raw IP address is shown in Windows Explorer, and everything works fine. 👍 Without running wsdd.py, I can also manually enter \\192.168.3.201\MyShare in the Windows Explorer address bar, and that works as well. (And obviously if I add SERVER to my drivers/etc/hosts file on the Windows computer, that works too.)

You already pointed out the main issue: You need a working name resolution (see https://github.com/christgau/wsdd/issues/57#issuecomment-689730116). This is apparently not the case. Therefore you also see no traces in the Samba log.

It seems that wsdd.py is not communicating correct IP address to Windows. (?)

Wsdd does not communicate any IP address to Windows that is related to Samba. It just says 'Hi, I'm a host and if we talk to each other a little more, I will tell you that I am a "Computer" device in the network and my (resolvable) name is [whatever wsdd was configured for]'

I also tried using the -W option for wsdd.py which dumps the SOAP packets. And I do see <wsd:XAddrs>http://192.168.3.201:3702/2f838418-e833-46ef-997a-613d1b515cd9</wsd:XAddrs> but that is referring to the port used by wsdd.py. I can't figure out where in the protocol it tells Windows how to find Samba. (?)

The XAddr(s) are used to exchange metadata about the device. When Windows find our that the host is a 'computer' by contacting the XAddr(s), it implies the host offers SMB, presents it in the network view and if you double click, it tries to resolve the name and connects to the SMB port.