can a laptop "discover" its siblings on the same wifi LAN
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
can a laptop "discover" its siblings on the same wifi LAN
I have several closely related laptops (and desktops &c) that join and leave the same wifi LAN. Is there some way that a laptop can reach out onto a LAN and "discover" others that are "closely related?"
It is okay for each workstation to run some software prepared to respond to a suitable inquiry. Some sort of "I found ___" or "___ was here" cache might have value, too.
It is not okay for any workstation to act as a central store (local DNS) or other clearing house for who is around. Also, I don't want workstations to ask any sort of central repository.
It seems that this might be a use for some sort of LAN-based network broadcast "I'm here!" or "Anyone else here?" followed by a suitable reply and some scripting to make appropriate notes.
It would be s-wonderful, s-marvelous if there is already some app suite or daemon that does this sort of thing.
After some reading, AVAHI seems to be exactly what I'm looking for, see Avahi Project Page for more details.
I want each workstation to "publish" a list of "services" that are available to the LAN in such a way that its siblings can browse for and use those services.
That seems to be the whole intent of the AVAHI project.
Sadly, I see a lot of chatter about folks wanting to disable and remove AVAHI so I need to explore if that is due to a lack of need, a desire to reduce workstation background overhead, or component defects.
Hee, HEE, hee, hee ... I'll report back as I learn more.
Additional comments from folks who know about AVAHI would be welcome and appreciated.
The Address Resolution Protocol, or 'ARP' plays a role in learning and remembering names and addresses and where they reside on a given ethernet. See ARP -- An Overview for more details. As described in the article, ARP is pretty low level: ethernet broadcast of an IP address -- essentially asking "Does any host who gets this broadcast own the named IP address?" A router using Proxy ARP recognizes ARP requests for hosts on the "other side" of the router that can't reply for themselves. The router answers for those addresses with an ARP reply matching the remote IP address with the router's Ethernet address (in essence, a lie).
Given two workstations, 'wilma' and 'fred' on the same LAN, that want to interact, there is quite a dance.
Once each workstation has an IP address (usually using DHCP) things happen:
each workstation must inquire then learn the IP address of the other
for convenience, a human-readable name might be nice to have
each workstation must inquire then learn about services and resources provided by the other
for each interesting service or resource, a workstation must take appropriate actions to connect with and make the remote services and resources available locally
It appears that Avahi handles a major part of this dance. With no other workstations on the LAN,
my local workstation reports:
Code:
avahi-browse -at
+ wlan0 IPv4 Officejet 6500 E710n-z [0ECB6E] PDL Printer local
+ wlan0 IPv4 Officejet 6500 E710n-z [0ECB6E] Internet Printer local
+ wlan0 IPv4 Officejet 6500 E710n-z [0ECB6E] Web Site local
+ wlan0 IPv4 Officejet 6500 E710n-z [0ECB6E] _scanner._tcp local
+ wlan0 IPv4 Officejet 6500 E710n-z [0ECB6E] _http-alt._tcp local
+ wlan0 IPv6 kaywine Remote Disk Management local
+ wlan0 IPv6 kaywine [64:80:99:4e:67:28] Workstation local
+ wlan0 IPv4 kaywine Remote Disk Management local
+ wlan0 IPv4 kaywine [64:80:99:4e:67:28] Workstation local
Notice that there are details from the workstation itself and for a network printer. The printer appears to be an all-in-one with both printing and scanning services. According to the little I've read so far, I should be able to access any avahi-equipped workstation by name using "{hostname}.local".
Sadly, I see a lot of chatter about folks wanting to disable and remove AVAHI so I need to explore if that is due to a lack of need, a desire to reduce workstation background overhead, or component defects.
I think a lot of people think that disabling avahi will give them some sort of security advantage; that is, if you don't publish that some service is available, no one will try to exploit it. This is probably an excessively optimistic assessment of the virtues of obscurity.
Certainly, you don't lose a big percentage of your network bandwidth with it (ok, ok, over a network with a reasonable bandwidth to start with) and it shouldn't be a big drain on cpu resources with a modern cpu, so you probably won't gain a noticeable amount of performance from disabling it, unless you need to guarantee sub-millisecond real time response - which, I suppose you might, if you are running the network for a trading floor, but for everyone else, it will be irrelevant. Doesn't hit the average response time in any noticeable way, but in the one-in-a-thousand, or one-in-a-ten-thousand case when there is a contention, it probably is technically measurable, but that's not the same as noticeable to a normal user.
Mostly, the way Avahi is used is that the servers announce the services have available (eg, 'I have a printer'), but there is no reason that this can't be used by workstations, I just don't know how much messing around there is to get this going, and, what you have to do at an application level to ensure that the announced list is always correct.
In my case, having a network name that everyone can see and use it a huge step forward
over: what is my IP, tell you -- what is your IP, tell me -- edit /etc/hosts or similar -- la-dee-dah. At least AVAHI lets me enter {hostname}.local into services like web browsers, FTP clients, SSH clients, NFS clients and so on. (I'd like something other than "dot-local" but that is just me.)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.