Connectshares works with IP address, but not with name

[Member Robin]

Helpful

Up

0

::

ahoppin wrote:

Linksys is set for DHCP to the WAN, so it’s handing out the Mofi’s IP address when a client asks “what DNS?”

Ms Linksys needs to answer all the local requests herself to make it work.

ahoppin wrote:

introducing Mr Antix to Ms Linksys as DNS provider

No. The other way around. Think hierarchical in networking topology always.
So Ms.Linksys has to be the DNS provider for your local network, set up to forward all queries she can’t answer herself to Mr.Mofi.

You’ll have to run a local DNS server on Ms.Linksys along with the DHCP server. On Ms.Linksys you’ll have to set Mr.Mofi as Gateway and upstream DNS, to which all unresolved queries will be forwarded. It can’t work when making Mr.antiX act as a local DNS (without fully configuring it and set it up to act like that), and this is the reason for which you see the question marks and can’t ping a name that has to be resolved. Where should Mr.antiX know from, which network domain name you want/have to use? Ms.Linksys does know all this. So she is the one who has to act as a DNS here. (Mr. Mofi himself has to send all the DNS requests he receives via Ms.Linksys and which he can’t answer himself to a public DNS, either the one driven and assigned by your ISP or any other trustworthy manually set DNS you like to use. What you do write in its configs is a question of personal preferences.)

Only if you correct your basic network structure you’ll be able to flawlessly connect all the devices. This is true not only for connectshares, you’ll run into the same trouble when writing your own script the way you like it best.

So do yourself a favour and make the basic ping between networking devices run using its network names (i.e. including correct name resolution), before starting with running higher network connection protocols in your network.
As long you are in the same (sub)domain, you even don’t need to add the fully qualified network name when pinging, sudo ping mx21 instead of sudo ping mx21.lan should do the job if your network is set up correctly.

(Surely, you could run a true DNS on your antiX machine also, configuring it to take over this role completely in your network. Then you’d have to set the network name suffix (i.e. your local domain name) as needed within its configuration, and broadcast it as primary DNS in your LAN, configuring it as gateway to Mr.Mofi and setting Mr.Mofi as upstream DNS. But what should all this trouble be good for, while you have Ms.Linksys running?)

Windows is like a submarine. Open a window and serious problems will start.

[Member ahoppin]

Helpful

Up

0

::

Robin:
> Ms.Linksys has to be the DNS provider for your local network, set up to forward all
> queries she can’t answer herself to Mr.Mofi.

That makes sense.

I’ve configured Antix to use static IP address and DNS, with DNS at 192.168.1.1 – that’s the Linksys. Confirmed it with the contents of /etc/resolv.conf.

The other machines currently on the net are also set to static DNS at the Linksys.

Do I need to do anything else to make the Linksys the DNS server?

—–

If I run arp -a on freshly booted live Antix – static DNS on the Linksys – it returns only

_gateway (192.168.1.1) at xx:xx … [ether] on eth0

Nothing at all about any Netbios names anywhere.

If I then run findshares, it locates the Netbios machine names and shares, just as it did before.

After I’ve run findshares the first time, arp -a says something different:

_gateway (192.168.1.1) at xx.xx … [ether] on eth0
? (192.168.1.117) at xx:xx … [ether] on Eth0
? (192.168.1.155) at xx:xx … [ether] on Eth0
? (192.168.1.111) at xx:xx … [ether] on Eth0

So running findshares is changing something.

BUT – still no Netbios names, according to arp. And no pings by netbios names.

I read up a little on Netbios. If I understand it right, there are 4 levels of Netbios name resolution:

1. The client’s cache
2. The client’s LMHosts file (that’s on Win; no idea what Samba’s equivalent might be)
3. A WINS server (no such thing exists on my net, as far as I know)
4. Broadcast message to all machines on the net

Maybe #4 is what findshares is doing. Just a wild-donkey guess.

ALSO: Apparently some routers can implement either a Netbios master browser, or, less often, a WINS server.

I see nothing about either one of these in the Linksys config menus, so I don’t think it has either capability.

However, if Netbios name resolution can be done by broadcast message, I don’t see why the router would have to provide either WINS or master browser service. Unless Antix just isn’t able to do that.

This is all quite puzzling.

[Member dirkd]

Helpful

Up

0

::

I’m not surprised that you don’t see hostnames in the arp report, when using fixed IPs. Remember that these hostnames were delivered by the router (hence the suffix .lan). But when you use fixed IP’s, the router must not even be contacted when booting up, since the host knows its own IP already (since it is configured as fixed). Hence the router doesn’t know the host’s name, and arp reports question marks. If you decide to work with fixed IPs you should also provide a /etc/hosts file, with the necessary host names (those that provide network shares).

I did the following experiment. I changed my mx21 host’s IP setting from DHCP to Static 192.168.1.100 (Manual). Then I issued some ping commands on mx21 itself. Before the change, it received 192.168.1.54 from the router, and its hostname was stored on the router as mx21.lan. Afterwards, when I ping mx21.lan, that name still resolves to the old address (since the router was not yet restarted), but the ping gives a ‘Destination host unreachable’ error (also expected: the old IP no longer exists on the network). The name mx21 (without extension) resolves to 127.0.0.1 (loopback address). However, I can now ping mx21.local, which resolves to the correct IP 192.168.1.100 (that DIDN’T work when using dhcp), presumably by the avahi software. Issuing arp -a showed the correct .lan names from all the other hosts on the network that use the dhcp server on the router, and the old (now illegal) hostname mx21.lan, with the old IP. The new IP however is not listed, and neither is mx21.local.

When I issue arp -a from the ANTIX machine, mx21 is listed twice: once with the old (illegal) IP as mx21.lan and once in the guise of a question mark with the new, correct, static IP. It all makes sense I think.

[Member Robin]

Helpful

Up

0

::

You are simply riding the wrong horse: You want DNS, not NetBIOS or WINS

ahoppin wrote:

Nothing at all about any Netbios names anywhere

This is expectable, since only Windows uses this windows specific protocol. NetBIOS is something you won’t want to set up as your default name resolution method in mixed style networking (MacOS, Linux and Windows machines present in the same network). NetBIOS is something you can use in “windows-only” networking, as long as no other client shows up. From the moment you deal with different OS in a network, use simply DNS instead. The windows machines can handle this properly.

Probably your Ms. Linksys is a lady of doubtful reputation (as you yourself denoted: she is a MS, standing here not for Miss, but for Microsoft obviously). She can possibly only handle “windows-only” networking. Some of the linksys are known to suffer from that strategic business decision of the router manufacturer, to design it windows-exclusively. Neither a WINS server nor a NetBIOS master browser are suitable in mixed networking.
So you possibly won’t get happy with this device. If this turns out to be true for your device you’ll have to run an additional true DNS 24/7 somewhere in your network. For a first reading: Why some routers dont include dns.

There is nothing antiX (or any other linux) could change on this situation. If there is actually no local DNS server present in your LAN, antiX can’t guess the networking host names of your devices and the local domain name, since there are none. There are only NetBIOS names for windows-exclusively networking. Seems you are locked in within windows world by your router.

ahoppin wrote:

Do I need to do anything else to make the Linksys the DNS server?

Use a device not designed “Windows-exclusively”, or replace its firmware by a version capable of handling universal local DNS, if the manufacturer provides this for your device. Then all your problems caused by missing name resolution in your network will vanish as if by magic.

As a workaround you could edit the hosts files on all your devices (yes, also windows knows about this file), so they contain all the (then mandatory static) IPs correlated to the device names present in your network. Try “man hosts” in a console window for further reading.
You’ll find the hosts file in Windows at:
c:\windows\system32\drivers\etc\hosts
And on antiX and any Linux as well as on any MacOS at:
/etc/hosts
You can edit these hosts files using a simple text editor. But be aware, this is a dirty old-school workaround only for a non functional default networking setup in your LAN. On a correct router/server side setup you won’t even need to use static IP, since your router should know about a feature assigning the same IP always to a specific networking device when using DHCP.
Further reading: wikipedia entry on hosts file

To put it in a nutshell: You need host names and a local domain name, not Windows NetBIOS names and a Windows WORKGROUP, and also you need to have a true DNS running. Only after these basics are met in your LAN you may start to set up SAMBA for emulating the Windows specific protocols on Linux (or MacOS) machines in a second step.

Windows is like a submarine. Open a window and serious problems will start.

[Member ahoppin]

Helpful

Up

0

::

Robin, Dirkd, many thanks. This clarifies quite a bit.

The superuser thread that Robin posted also helped considerably. It sounds like flashing the main router with dd-wrt is the key here.

[Member dirkd]

Helpful

Up

0

::

There’s still a chance to might not need to. If I tell two different mx21 clients to request a dhcp address from the router, but NOT to use the router as DNS (but, e.g., google 8.8.8.8 in stead), they can still find each other with the suffix .local (although they are invisible in the arp report). I presume that is because both run the avahi service. If one of them uses the router for DNS, then it becomes unreachable with .local (but visible with .lan), probably because avahi swithces off the name finding, in order not to mess up local DNS traffic. In your case, it’s possible this doesn’t work with the POPOS client, but you could test this setup by pinging the antix host FROM the popos client. If antix can be found by name, you could easily install the avahi service on popos (which is also a Debian derivative). That way all the linux hosts can be found by name. I haven’t run any experiments yet with windows hosts, but I have a feeling they will be found by name without much trouble.

[Member ahoppin]

Helpful

Up

0

::

Thanks again, Dirkd. That sounds like something to try as I gradually switch more machines over to other OSes.

The box now running Puppy Linux (not Pop-os, sorry for any confusion on that) is the one that I’ve been exploring other OSes for, including Antix. It still needs to be able to talk to 2 old special-purpose machines running Windows 2000 and Windows 98.

At the moment it looks like a different router, or different router firmware, may be the sensible fix.

[Member ahoppin]

Helpful

Up

0

::

Thanks again to all who posted here. I found a simple solution to this problem – let Antix be the Samba hub for the other machines.

Adding the lines

server min protocol = CORE
server max protocol = SMB2
client min protocol = CORE
client max protocol = SMB2

to /etc/samba/smb.conf allowed every machine on the LAN, Windows and old Linux, to browse Samba shares on Antix.

Note that I’m using only Windows 98 and Windows 2000, nothing later. The above fix might cause problems with later versions of Windows, or at least compromise security with them. Use at your own risk.

I’m far from a networking expert, but my guess is that Samba 4.13.13 in Antix couldn’t negotiate a protocol with the old clients until it was limited by the protocol statements. Smbclient on the old Puppy 5 box reported that “protocol negotiation failed.”

I suspect that Samba’s developers didn’t test with old Windows versions, maybe because they’re not commonly available any more, and hardly anyone still uses them anyway.

CUPS PRINTING BONUS: The Win98 machine hosts a couple of ancient printers. Adding the above client protocol lines to /etc/samba/smb.conf also got Antix CUPS working with those printers.

[Forum Admin SamK]

Helpful

Up

2

::

Connectshares does not provide a name resolution service (DNS), one must already exist in order that Connectshares can make use of it.

Simplified Overview of a Domestic Set Up
LAN system names do not appear in a global DNS. To overcome this, both global and local name resolution services are needed.

A global DNS handles everything on the outside of the router/firewall/switch (R/F/S) i.e. the world.
Because the R/F/S unit it always powered up, world name resolution is always available via a global DNS. The R/F/S often defaults to using the DNS specified by the ISP. Some offer the ability to specify a global DNS of the user’s choice.

A local DNS handles everything on the inside of the R/F/S i.e. the LAN.
Many home units do not provide a DNS for the LAN and therefore name resolution is unavailable within it.

A Potential Way Forward
An often used method of providing name resolution for LAN systems is to install a DNS package on a system that is always powered up and running (usually some form of server hardware). In that way the LAN name resolution service is always available. One benefit of this method is the local name resolution service is available to Windows and Linux systems in the LAN and is independent of the configuration of apps such as Samba and NFS. It is available to all programs that can utilize a name resolution service.

It might be worth looking at an app named dnsmasq. It is a tiny download from the repo. Additionally is uses negligible amounts of CPU/RAM/disk-space. It is is easy to set up via a single config file. It is good fit with the antiX philosophy.

Outcome
The result is Connectshares is able to make use of the LAN name resolution service and thereby works with either a server ip address or a server name.

If wanted Connectshares can also:
• Automatically mount remote shares at antiX login or on request,
• Automatically unmount shares at logout or on request,
• Make shares available to all apps and file managers without being tied to a specific file manager,
• Make shares available in both GUI and Console (text only) environments,
• Connect to shares on remote servers that use versions 1.0 and 2.1 or higher of the CIFS/SMB protocol,
all without the cumbersome error prone method of editing fstab or typing commands.

As always, it’s your system, your choice.

[Member ahoppin]

Helpful

Up

0

::

Sam, dnsmasq sounds brilliant! Thanks for the suggestion. It should help as I switch more of the Linux machines on the LAN over to antiX.

Nfs looks like another possibility for that case, but I haven’t looked into it much yet.

For now, letting the sole antiX box be the ‘hub’ is working well.

PS – I tried smb4k and had mixed but encouraging results. I may go back to that at some point, though it seems like a 100-kiloton flyswatter.

[Member PPC]

Helpful

Up

0

::

Just another perspective on the problem of connecting to a shared folder – I’ve been developing a script that scans the network for shared folders and allows you to select to which one you want to connect to. For now it only works for shares that use smb > v.1. , it’s available here: https://www.antixforum.com/forums/topic/script-to-automagically-mount-a-samba-shared-folder-in-antix/page/2/#post-79130
I consider this script to be connectshare’s younger, fully GUI brother- it works more like what I remember from accessing a shared folder on Windows. For now, users have to always enter the credentials to access the shares, future versions may save the credentials and allow automatic log-in to the chosen share… It’s not what you want, but it may be an alternative way to get similar results…

P.

[Member ahoppin]

Helpful

Up

0

::

Thanks, PPC! I downloaded your script and will study it. I’ll need to tweak it a bit, since I presently have no machines aside from the antiX box that support anything past SMB1. I also use Thunar, and tend to be kind of opinionated about file managers. I’m not a big fan of the Pcmanfm / Zzzfm family, or of Roxfiler, for that matter. Nevertheless, this looks promising.

[Member olsztyn]

Helpful

Up

0

::

ahoppin wrote:

I’ll need to tweak it a bit, since I presently have no machines aside from the antiX box that support anything past SMB1.

I was myself looking for SAMBA option parameter to specify SMB 1.0 in this script. On antiX Connectshares the parameter to specify SMB version is SAMBAOPT=vers=1.0 in Connectshares.cfg. And this worked great accessing my SMB 1.0 NAS servers.
However for smbclient used in the script developed by PPC I am still not clear what is the syntax for corresponding parameter.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member ahoppin]

Helpful

Up

0

::

Again I’m far from an expert on this, but I think that the command line flag that should work is -m, and the value would be either NT1 or SMB2.

smbclient -m SMB2

However, that doesn’t work for me. It may be related to this bug :

https://bugzilla.samba.org/show_bug.cgi?id=14939

This command did the job :

smbclient --option="client min protocol = CORE" --option="client max protocol = SMB2"

If that fails, you might try replacing SMB2 with SMB3 or NT1.

You may find it easier to enter the options that you find are successful in the [global] section of /etc/samba/smb.conf – for example

[global]
client min protocol = CORE
client max protocol = SMB2

FWIW, with the CORE / SMB2 options above, I can connect successfully to both Windows 2000 and Windows 98 servers.

[Member olsztyn]

Helpful

Up

0

::

ahoppin wrote:

This command did the job :

Thanks much. I will play with these options. Since this is for the script PPC wrote, I will need to familiarize myself with the code. Particularly that also SMB 1.0 shares should be reflected in the list in order to select them…
Thanks and Regards…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Author]

Posts