On 12/08/2022 09:46, NY wrote:
>
> "Theo" <
theom...@chiark.greenend.org.uk> wrote in message
> news:bmu*Kj...@news.chiark.greenend.org.uk...
>
>> It seems that Microsoft removed network browsing from SMB2, so you
>> have to
>> know the name of the server to connect to it. It's possible the router
>> manufacturers stuck with SMB1 for that reason. Unsurprisingly, that has
>> come home to bite them.
>
> I wonder if that's why I've never managed to make a Linux computer
> access SMB shares on a Windows PC. The converse works fine: Windows
> accessing Linux shares (or Windows-Windows or Linux-Linux). It may be a
> problem with logging on: I don't give my shares a password and therefore
> connect anonymously without specifying a Windows username / password.
>
> It's a shame that Linux doesn't seem to implement name-to-IP lookup as
> thoroughly as Windows does, so a URL that points to a hostname of a
> local computer on the LAN works fine if the web client is running on
> Windows, but you need to specify the IP address if browsing from Linux,
> Android or iPad. For this reason, I always configure my router to
> allocate fixed addresses to any computers that run web servers for
> configuration by web (*). The shared ..json file of all Firefox's
> bookmarks that I use to update FF on all devices periodically, has to
> refer to local computers by IP for this reason.
>
> It's the difference between
http://my_pc:9981/ and
>
http://192.168.1.10:9981/
>
> You'd think that any computer would use DNS to query the DNS server and
> name/IP client table in the router, but it seems that either this
> doesn't work with the various routers I've used or else browsing on
> non-Windows uses NetBIOS or some other name service instead.
>
> Some time I'll have to look on Wireshark and see what a Linux PC is
> doing when you browse to a URL containing a local computername.
> Sometimes I have been able to browse to a URL by name on Linux, which
> suggests that it is using a local table which may or may not have been
> emptied and refilled after a reboot, rather than always doing an
> explicit broadcast name query "who has hostname ABC?".
>
> (*) Address reservation: still use DHCP, but the router's DHCP server
> knows *always* to give the same IP to a given MAC. Much less error-prone
> than setting a static address at each relevant "server" computer: you
> can temporarily move a computer to a different network and it will still
> work, even if the fixed name-IP mapping is broken, whereas a static
> address might be in the wrong subnet (or collide with the IP) on the
> temporary network.
Nearly all the above points have been addressed, separately or together,
in previous posts to ngs that you subscribe to.
First rule, disable Windows Homegroups, because like much of Windows
default networking, this arrangement has security issues. Instead, use
userid/password combinations to log on to shares on other machines.
To make the above choice as painless as possible, ensure that any user
that wants to login in to any PC and access a share on any other PC has
the same userid/password combinations on both PCs, and that both PCs are
in the same Workgroup.
That's about it for Windows to Windows sharing, but there are some
gotchas, especially if Microsoft Security Essentials is installed on a
Windows 7 or later PC, and its shares need to be accessible from a pre
W7 PC, or perhaps it's actually pre Vista, I'm not sure. A registry
tweak may then be needed.
I can give more detailed help on the above if required.
Windows <-> Linux is more complex, but basically similar rules apply.
You need to have Samba users on Linux PCs which have identical
userid/password combinations to those on the Windows PCs. Note that
that is Samba users, not just normal Linux users, and that potentially
that is three different places where a user has to remember
userid/password combinations, and the easiest way is to keep them all
the same.
That's the theory, but I find this doesn't work in Ubuntu, I still have
to sign in twice from its file manager to get to a Windows share, once
to gain access to the PC's list of shares, again to get into any
particular one. This seems to be some sort of maddening silly bug in
Ubuntu.
As far as DNS and computer name assignation and browsing goes, this
again has been covered many times ...
Most Windows PCs have something like "Enable NETBIOS over TCP/IP", or a
more modern default, enabled in their TCP/IP advanced settings. In an
average home situation, this means that the first PC to come up on the
LAN self-elects to become the Master Browser, and maintains a
translation list linking the names of PCs to their IPs. Thus name<->IP
translation can and does happen very effectively without any DNS, and in
such situations, local name resolution relies entirely on NETBIOS, while
WAN name resolution relies on DNS.
Linux PCs use a DNS client for both LAN & WAN, and, apart from
occasional distro specific problems, it usually works quite well.
However, unfortunately, many routers do not supply both LAN & WAN DNS
correctly. Often there are two choices in the configuration settings,
being a server or being a relay. If the former is chosen, the LAN has a
proper DNS service, but the WAN does not, while if the latter is chosen,
vice versa. The reason they have got away with this for so long is that
when the choice is of relay, LAN DNS is only seen to fail where there
Linux PCs, or increasingly nowadays with Linux based tablets and mobile
phones on it. If all you have on your LAN are Windows PCs, you will
never notice the lack of local DNS because its absence is covered by
NETBIOS.
To implement DNS as it should really be done on a router, where any name
not found on the LAN is passed upstream to a WAN DNS server so that both
are covered properly, it is often necessary to reflash the original
firmware with a replacement build from OpenWRT or DD-WRT, if such is
available.
--
Fake news kills!
I may be contacted via the contact address given on my website:
www.macfh.co.uk