Connectshares works with IP address, but not with name

[Member ahoppin]

Hi, I’m relatively new to Antix, so I’m still quite ignorant, but learning.

In line with that, a big thanks to Dolphin Oracle for an outstanding video production illustrating Connectshares basics, especially use of the command line. That’s gotten me on the road.

However, I have a non-fatal problem with Connectshares.

The situation:

CONNECTING MACHINE:

Antix 64 bit 19.3 live, ROX/Icewin

REMOTE MACHINES:

1. Puppy 5.2.5 (Linux 2.6.33.2), Samba 3.5.6 – workgroup = OFFICE, machine = PUPPY
2. Windows 2000 – workgroup = OFFICE, machine = WIN2K

To make it simpler I’ll mention only the first remote system above, as the other behaves similarly.

If I specify

REMOTE=192.168.1.111
WORKGROUP=OFFICE

in ~/.config/connectshares/puppy.conf

then

$ connectshares puppy.conf

works perfectly, and the requested shares are mounted.

However, if I specify

REMOTE=PUPPY
WORKGROUP=OFFICE

then

$ connectshares puppy.conf

returns “Unable to contact PUPPY.”

In puppy.conf, I’ve tried both lower and upper case in all combinations for both the system name and the workgroup. No luck.

I’ve tried adding SAMBAOPT=vers=1.0 to the config file, but that also made no difference.

I’d like to get Connectshares working with samba names if possible.

Has anyone run into this problem, and solved it?

Thanks for the help!

[Member dirkd]

Helpful

Up

0

::

Have you tried to issue the command ‘ping puppy’ in a terminal? If you again get a message that host or name or service or whatever is unknown, you should try to use the ‘fully qualified name’, that means, with the domain name included. Example: to locate my Antix21 computer (called dokux) on the network from an mx-21 computer (called mx21), if I issue the command

$ sudo ping dokux
ping: dokux: Name or service not known

but if I try:

$ sudo ping dokux.local
PING dokux.local (192.168.1.10) 56(84) bytes of data.
64 bytes from DokuxWifi.lan (192.168.1.10): icmp_seq=1 ttl=64 time=0.065 ms
64 bytes from DokuxWifi.lan (192.168.1.10): icmp_seq=2 ttl=64 time=0.275 ms
64 bytes from DokuxWifi.lan (192.168.1.10): icmp_seq=3 ttl=64 time=0.064 ms
64 bytes from DokuxWifi.lan (192.168.1.10): icmp_seq=4 ttl=64 time=0.086 ms

My guess is that you have to use the fully qualified name in the ‘REMOTE=’ line in puppy.conf

Another workaround is to edit the file /etc/hosts (as root) and add a line

192.168.1.111 puppy

Then just puppy suffices for both ping and connectshares. However you have to adjust the hosts file each time your IP address changes.

[Member ahoppin]

Helpful

Up

1

::

Thanks for the suggestion! I’ve never heard of using .local before. Unfortunately it doesn’t make a difference. Ping responds with “Name or service not known.” Connectshares can’t talk to puppy.local and PUPPY.local either. Foo.

Also tried adding smb:// and smbc:// (that is, smb://puppy and smb://puppy.local) with no better results.

It’s a puzzle.

It appears that CUPS is going to be another hurdle, since my printers are all on yet another machine, but I’ll deal with that later.

EDIT: CUPS wasn’t so bad after all. Installed smbclient. Added the lines

client min protocol = CORE
client max protocol = SMB3

under local in /etc/samba/smb.conf – now CUPS can see the printer server.

Smbclient can query all the other Samba and Win machines on the net by Netbios name. However, Connectshares and ping still demand IP addresses.

• This reply was modified 1 year, 4 months ago by ahoppin.

[Member dirkd]

Helpful

Up

1

::

Well, I noticed since that it didn’t work in the other direction, and now I’m a bit confused myself.

But have you tried the /etc/hosts approach? If you work with fixed IP addresses (which I can only recommend, and is easy to do on your own home network) it’s the easiest way to make host names known to your machine.

Anyway, you should always try a ping first: it’s quick, it’s easy, and if a ping doesn’t work, more complicated things like file sharing won’t work either. Behind the curtains your machinge always works with IP addresses, and there are multiple ways to translate hostnames to IP addresses: a simple hosts file, something called mDNS, or a full-fledged DNS server. (Sorry if I’m stating the obvious).

[Member ahoppin]

Helpful

Up

0

::

Sorry, I’m confused now (my natural state). I don’t know what you mean by “it didn’t work in the other direction.”

Thanks for the /etc/hosts suggestion! That would handle the situation cleanly for the fixed machines on the network.

Except maybe for other Antix machines. I may be missing something, but I’ve looked at Connman and I can’t see a way to configure it for a static IP address.

Maybe Ceni can do a static IP? Haven’t tried it yet.

Also, laptops wander in and out on the net here, always DHCPing.

As a workaround, I may be able to cook up something homemade with findshares and mount.cifs.

Thanks again for all the help!

[Anonymous]

Helpful

Up

0

::

Not sure if this could serve, but hope so…

If I understand correctly, you connect to the remote machines using Samba. In the -limited- experience I have had with Samba, whenever having the issue of only being able to connect with IP address and not with NetBIOS (DNS?) name, it was due to two main reasons:

–Remote machine (the “server”) not running the nmb(d) service
–Connecting machine (the “client”) using WiFi and not Ethernet; but this seen on Windows machines at least

I already read this is not the case, but just for note, regarding the second case, some Windows machines did and some others didn’t. I never sorted out deeply the problem; as little as I can remember, it seemed to be something weird related to some driver settings on registry, or something like that…

Well, hope this can be of some help. Unfortunately haven’t tried with a Linux client yet…

[Member ahoppin]

Helpful

Up

0

::

Ctcx, thank you for the contribution. I’ll have to carry out further study on that as I know nothing about nmb(d).

Networking has always been my stumbling block. To me it’s a black box with internals and secret handshakes beyond my ken, and it keeps getting more arcane as security becomes stricter. I probably just need to take the time to really study it.

Thanks again to you and Dirkd for the help. I’ll flail away at this problem for a while longer, and will post an update if I find a solution.

All contributions, suggestions, thoughts, and ideas are welcome.

[Member dirkd]

Helpful

Up

0

::

@ahopping: What I meant with ‘the other way’: I can find my Antix21 machine by name from MX21 by adding .local, but I can’t find MX21 from my Antix machine, with or without .local. I was convinced that running the avahi demon (which you can install with synaptics) was enough for this to work, but it seems I’m wrong about that: both MX21 and Antix21 come with Avahi installed and running. Need to research that.

Something you may try to implement fixed IP’s: it can be done with Ceni. I avoid Connman: although it works for many, here in my setup it causes problems. But I have configured fixed IP’s for all devices on my network on my router, which acts as dhcp server. It’s a feature called ‘Reservations’, or ‘Reserved IP addresses’ or something similar. I bet that at your home too, the router doubles as dhcp server, assigning IP addresses when a device connects to the network. The router typically has an IP address 192.168.x.1 (x=0 or 1), and has a built in web server to configure it: just type http://192.168.1.1 in a browser address bar and you should see it. It may ask for a password, which will be written on the router box somewhere.

Then search in the menu’s for ‘Reservations’ or so, and you can assign an IP to each device on the network. It can be a puzzle to identify the devices listed on the router, but you only have to do it once. Then, technically, your computers don’t have a fixed IP, but in practice they always get the same address from the router by DHCP. This way your laptops should behave just fine, and you can have a fixed /etc/hosts file on your network.

[Member Robin]

Helpful

Up

0

::

ahoppin wrote:

I’ve never heard of using .local before.

The subnet name can vary, depending on what your dns/dhcp server assigns to it. E.g. when connecting to one of the (at least in our country) wide spread “Fritz!Box” Routers for Cable/ADSL/Fiber internet access, you’ll get assigned the appendix “fritz.box” by default.

$ sudo arp -a
fritz.box (192.168.178.1) auf 5a:a8:6d:07:9e:b2 [ether] auf eth1
antix1.fritz.box (192.168.178.16) auf <02:8b:e0:15:a3:87 [ether]> auf eth1
antix2.fritz.box (192.168.178.19) auf <5e:00:c1:70:ae:0d [ether]> auf eth1

This way you can find out what the true fully qualified network names in your networking neigbourhood are. (The very first entry in my example is the router itself)

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

[Member dirkd]

Helpful

Up

0

::

I tried this myself. On the Antix machine I get

$ sudo arp -a
? (192.168.1.54) at 08:00:27:b6:d5:3a [ether] on wlan0
_gateway (192.168.1.1) at 30:91:8f:14:e3:aa [ether] on wlan0
nasty (192.168.1.25) at 00:11:32:86:e7:88 [ether] on wlan0

The question mark represents the mx21 machine, but Antix has no idea about its hostname. On the mx21 machine:

$ sudo arp -a
[sudo] password for dd: 
mymodem.lan (192.168.1.1) at 30:91:8f:14:e3:aa [ether] on eth0
DokuxWifi.lan (192.168.1.10) at 34:c9:3d:02:83:7a [ether] on eth0

Trying to ping the mx21 machine from antix21, with the .lan suffix: no joy 🙁

$ sudo ping mx21.lan
ping: mx21.lan: Name or service not known

[Member ahoppin]

Helpful

Up

0

::

dirkd:
> I can find my Antix21 machine by name from MX21 by adding .local, but I
> can’t find MX21 from my Antix machine, with or without .local.

It sounds as if your situation might actually be worse than mine. Here findshares sees the other machines, but connectshares can’t talk to them.

> MX21 and Antix21 come with Avahi installed and running.

I had never heard of avahi, so I looked it up. Seems that it’s at least a step-sister of systemd and pulseaudio, since it was fathered by Lennart Poettering. Poettering, systemd, and pulseaudio are all bad words in this house, so I’m going to be vewy vewy cautious about avahi.

Sorry to get into religion here, don’t mean to start any fires! I know that a fair lot of folk are fine with Poettering, or at least agnostic about him and his software. However, just my opinion, I’m not, and ! systemd is a big reason that I’m pursuing Antix.

> I bet that at your home too, the router doubles as dhcp server, assigning
> IP addresses when a device connects to the network.

You win that bet, you betcha.

Actually, I don’t know of a router that doesn’t do DHCP, but I’m woefully behind the times on hardware – yet another reason that I’m nosing round Antix.

I have read of reservations. However, my old reliable Linksys WRT54GL routers don’t seem have it (them?) or anything similar. I keep threatening to flash at least one of them with dd-wrt, so if dd-wrt has such a feature, maybe I’ll do the DHCP server router first.

Robin:
> sudo arp -a

I never thought of that. I’ve only used arp to flush out unknown IP addresses for anonymous devices lurking on the network.

Your Fritz Box seems a bit more forward than my WRT54GL. On my live testing copy of Antix 21, sudo arp -a returns

_gateway (192.168.1.1) at xxxx [ether] on eth0

And that is all.

However, ps -ef | grep avahi returns

avahi 3802 1 0 10:32 ? 00:00:00 avahi-daemon: running [antix1.local]
avahi 3803 3802 0 10:32 ? 00:00:00 avahi-daemon: chroot helper

So there’s dirkd’s antix1.local, I guess?

Say, briefly off topic: What’s the deal with this sudo (I assume) message I just got: “We trust you have received the usual lecture from the local System Administrator”? Do I detect the noxious aroma of condescension from some officious developer?

It reminds me of when my town here put up new signs at the town limits saying “Welcome to Littleminds. Behave yourself.” Boy did they get an earful at the next council meeting, and not just from me. The signs came right down. As far as I know, however, the removed signs weren’t inserted where some upstanding citizens suggested that they should be.

More religion, I guess, sorry. I’ll try to do better.

dirkd:

> Trying to ping the mx21 machine from antix21, with the .lan suffix: no joy

Perhaps that’s no surprise, since MX seems to be hiding its name, at least from arp. But again I warn that I’m a networking nitwit.

Dirkd, is your MX box running Samba? If so, have you tried using connectshares from your Antix box to mount your MX box’s Samba shares?

[Member dirkd]

Helpful

Up

0

::

Hi ahopping, Robin has clearly shown the way to go, I think. I found out that apparently something was wrong with the wifi configuration on my main (Antix21) machine. I would never have guessed. But seeing these question-marks in the arp report in stead of host names, I decided to redo the configuration with Ceni. Not totally painless, but now arp reports host names as it should. These hostnames are the same as on my router, partly automatically generated, some of them edited afterwards for easy identification. As such they are not always the ‘official’ hostnames, e.g. as indicated in a typical bash prompt. On my Antix machine:

$ sudo arp -a
[sudo] password for dd: 
PhilipsTV-WiFi.lan (192.168.1.31) at 80:30:49:42:43:87 [ether] on wlan0
mx21.lan (192.168.1.54) at 08:00:27:b6:d5:3a [ether] on wlan0
nasty (192.168.1.25) at 00:11:32:86:e7:88 [ether] on wlan0
mymodem.lan (192.168.1.1) at 30:91:8f:14:e3:aa [ether] on wlan0

‘nasty’ doesn’t show an extension, because it’s included in my hosts file. The others aren’t and get a .lan extension.

$ sudo ping mx21.lan
PING mx21.lan (192.168.1.54) 56(84) bytes of data.
64 bytes from mx21.lan (192.168.1.54): icmp_seq=1 ttl=64 time=0.095 ms
64 bytes from mx21.lan (192.168.1.54): icmp_seq=2 ttl=64 time=0.073 ms
64 bytes from mx21.lan (192.168.1.54): icmp_seq=3 ttl=64 time=0.097 ms
64 bytes from mx21.lan (192.168.1.54): icmp_seq=4 ttl=64 time=0.178 ms

And as you can see, I can now ping my MX21 machine by name.

I haven’t yet tried connectshares in my current setup. I have no doubt it would work with IP’s, as it does with you. But I thought it was useless experimenting with hostnames as long as I saw problems while pinging. It’s a bit late now, but I’ll do some tests tomorrow and will let you know the outcome. I dabbled with connectshares long ago, it worked too, but I found it not entirely satisfactory. Since then I mount important shares using /etc/fstab. These shares are all folders on a NAS that I use mainly for streaming media. I find this method very easy and flexible.

Are you still interested in configuring fixed IP’s with Connman? I found out where the settings for that are hidden in Connman’s user interface this afternoon.

While we’re gossiping about Poettering: coincidentally I just came across one of his posts in a forum this week, for the first time ever. That one post was enough to feel a dislike for the guy. He came across as an arrogant prick (can I say this on the forum?) from the first line he wrote, which was – totally needless – insulting to the person who he reacted to. That doesn’t mean his software can’t be high quality. I lack the expertise to judge that. But systemd seems to me a whoooole and a whoooole lot more complicated than this Runit system that I never had heard of before and I’m using now for the first time. And I generally prefer the simple, even primitive if need be, to the complicated. Also, I trust the judgment of the Antix team in this matter. They have delivered a first rate product without systemd, so it’s clearly not needed.

[Member ahoppin]

Helpful

Up

0

::

dirkd:
> I found out that apparently something was wrong with the wifi configuration on my
> main (Antix21) machine. I would never have guessed.

Any idea what was wrong? I mean, the setup was working otherwise, right?

And what did you change to fix it?

> I decided to redo the configuration with Ceni. Not totally painless

I had a look at Ceni just now. It doesn’t look impossible, but it definitely looks more daunting than Connman, especially to a newbie. Some users might be put off by its text-mode UI.

I’m still puzzling over why changing your local machine’s setup allows that arp command to fetch more info from a remote machine. There’s my net-nitwittitude again.

> I thought it was useless experimenting with hostnames as long as I saw problems
> while pinging.

Aye. I looked at the connectshares script. One of the first things it does is ping the requested server.

> I mount important shares using /etc/fstab.

That sounds like a smart choice, especially for shares on a machine with a fixed IP address.

> Are you still interested in configuring fixed IP’s with Connman? I found out
> where the settings for that are hidden in Connman’s user interface this afternoon.

I’m all ears! Eh, all eyes? Whatever, yes, please, I’m interested.

> [Poettering] came across as an arrogant prick (can I say this on the forum?)

You just did. 🙂

> from the first line he wrote, which was – totally needless – insulting to the person who
> he reacted to.

I’d call that “vile and narrow minded.” I’d say “his loss,” but given the way systemd and pulseaudio have metastasized, it’s our loss.

> systemd seems to me a whoooole and a whoooole lot more complicated than this Runit system …

It sure does! Systemd reminds me of a micromanaging supervisor. Not only is such a supervisor annoying and tiring to work for, he makes his own job more difficult. On t’other hand, SysV and the others are like managers who trusts their employees and delegate everything, then sit back and watch the business go.

I’ve probably missed something, but when I first read about systemd some years back, it struck me as a solution in search of a problem. With init, when you need something else done, you write another daemon or utility. That’s worked fine for decades. (Hotplugged devices, for example.) Why expand and recompile an already massive micromanaging manager when you can just write a page or two of new code?

> [The Antix team] have delivered a first rate product without systemd, so it’s clearly not needed.

No argument there! My hat’s off to them too.

Without wanting to get too specific, I see in the systemd / alternatives battle some parallels to politics. A small, top-down authoritarian minority can often defeat a majority weakened by its factions. The way for that majority to fight back – and sometimes win – is to form one or more coalitions.

The systemd bludgeon seems to have splintered our old friend SysVinit into several other inits. A few examples – runit, openrc, dinit, s6. I’m far from an expert, but I wonder if there might be greater strength in a non-systemd coalition that pulled some or all of these together. Eh? What was that? Something about herding cats? :-\

[Member dirkd]

Helpful

Up

0

::

What did I change? At first it was not clear to me either, just went through Ceni again. But in hindsight it’s obvious: this time I included my router as a DNS server. I can’t check this anymore, but I’m certain that I didn’t do so the first time around, I must have restricted myself to the google servers. Of course google doesn’t know about mx21.lan! Hence the question marks for the hostnames in the arp report. Now that every host on my lan looks at the router for the names of connected computers, everything is hunky dory. I tested connectshares just now, with hostnames in stead of IP’s. Worked like a charm.

First I made a samba share [test] on mx21.lan, writable by everyone. Then I configured connectshares on an Antix21 system.

REMOTE=mx21.lan
SAMBA=y
WORKGROUP=Workgroup
SHARESUSER=test
CREDAUTO=
CREDNAME=
CREDPASS=
SHARESGUEST=
SAMBAOPT=
NFS=
SHARESIPDNS=
NFSOPT=

Running connectshares mounted the ‘test’ folder on mx21.lan as /mnt/mx21.lan/test on mx21.lan/ (after asking for credentials for the user dd). Disconnectshares worked too. So no problems left.

Here’s how you can mount a share ‘media’ on the host ‘nasty’ in fstab:

//nasty/media /mnt/nasty/media cifs username=dd,password=*******,vers=1.0,iocharset=utf8,sec=ntlm 0 0

(Everything on a single line.) The mountpoint /mnt/nasty/media must be an existing folder. On my machine, this folder is owned by root, and universally writable, but these permissions can certainly be relaxed.

Yet another way to access a share, on the fly so to speak, is typing its url in zzzFM’s address bar, as shown in the attached image. Of course you have to know the exact share name of the folder involved. The only thing missing in zzzFM really, is the ability to browse the remote host for shares.

To instruct Connman to use fixed IP’s, you click the button [Configuration] on the tab ‘Details’. Then, in the IPv4 area, you can choose ‘manual’ in the ‘method’ dropdown list. See the 2nd attached image.

Attachments:

1. 

   zzzFM.jpg
   

2. 

   connman.jpg
   

[Member ahoppin]

Helpful

Up

0

::

> included my router as a DNS server.

Aha! I’d expect DHCP to tell the OS to use the router as its DNS, but something different happens here, and it’s my fault.

Long story, but I have the Linksys main router’s WAN port connected to a mobile (cellular) router – a Mofi 4500. The Linksys is set for DHCP to the WAN, so it’s handing out the Mofi’s IP address when a client asks “what DNS?”.

This setup has worked fine for me since June of this year.

But since the upstream Mr Mofi has no truck with anyone but Ms Linksys, it knows naught of Ms Linksys’s downstream LAN progeny.

So the idea of introducing Mr Antix to Ms Linksys as DNS provider seemed mighty promising.

I used Connman as you suggested (many thanks!), configuring a static IP address, and also asked it to set the Linksys as DNS.

After a couple of false starts, the process went smoothly. DNS resolution worked and ping found various URLs on the internet. However, dang it, ping still can’t find the local Samba shares!

arp -a finds them exactly as before, with only the IP addresses, and ? where the name would otherwise be.

So, connectshares still won’t work with share names, only IP addresses.

Maybe it’s something different about the Linksys.

On the other forepaw, I now have a working static IP, so that’s progress, for which I thank you heartily! Your screenshots REALLY helped.

I hate to sound defeated, but I think it’s time to write off connectshares. There’s always a Plan B, and here it’s to write up my own shell script to list the shares and get their IP addresses with findshares and/or smbclient, then mount them with mount.cifs.

Thanks again for all the help! Y’all are fantastic.

[Author]

Posts