We have a new Linux club classroom and regularly have 8 machines or more running. Our new home is a shared occupancy business and has a Ubiquiti router which serves a wireless access point in our location. I want to be sure that I understand our network problem before I approach the network manager.
We have openssh-server installed and internet access available on the machines. We are able to ssh/scp between machines on the same third octet (84 OR 85 OR 86 OR 87).
Problem: We cannot ssh/scp between ALL of the machines in the classroom.
What I know: There are at least 4 third octet addresses in use at any given time.
Laptop internal wifi ip = 172.19.84.xxx
Adding 3 wifi dongles to the above machine. $ "ip a" lists all 4:
wl2 ip = 172.19.85.xxx
wl3 ip = 172.19.86.xxx
wl4 ip = 172.19.87.xxx
I assume that we cannot "cross over" the third octet with ssh/scp protocol. Correct?
May I assume that the access point/router is load balancing?
Is there anything that I should document or try?

You should look up subnets and subnet masks.
In this case the subnet mask will determine if you can DIRECTLY address each of those nodes. If you have something acting as a bridge or router that allows the traffic, you may be able to address them a bit less directly through that connection virtually transparently.

Can you provide the output of for one or two of the nodes?

1 members found this post helpful.

So there probably is some firewall rule that blocks or does not allow access between networks. I assume that the network is a /24 (255.255.255.0) and that the SSIDs are all the same.

So typically you put everyone on the same network; but for security reasons you could separate out like guests or orgs. That would be one reason.

The other is network design. Like your started with a /24 but you need to increase the number of clients. One is to redo the network to a /22 or larger (which would be 84-87, but another would be just add another /24, update the dhcp configuration and router which you would have to do anyway. But at least you would not have to figure out how to renew/boot all the clients when you reconfigure the network. The router might or might not allow traffic between the other networks and that would be your problem.

That does not actually follow from the evidence provided, although it is certainly possible. Simple subnetting in an unusual pattern chosen by the network admin may account for the behavior observed. More information is needed to determine the case.

The most common format for a subnet is the network determined by the leftmost or higher order bits and the node address by the remaining, rightmost, or lower order bits. This is the format that is the most common case, and that can be shorthanded into the address/maskbits format. It is not even close to the only possible subnetting pattern.

I suspect this case is not that involved, but we can determine that with a bit more network information. The broadcast addresses or subnet masks will certainly help.

I have seen a secured public network where each connected node received a unique and very small network, so that ALL traffic between nodes was blocked unless explicitly allowed by a rule at the router. That is not a common case, but fit the security requirements at that site. Since this is a shared site, the network manager may have implemented a plan to isolate and segregate traffic to prevent cross traffic interception and monitoring.

Naturally the quickest way to find out would be to ask. If we do not want to do that, then looking at the network definitions you receive on connection is a bit more detail should prove illuminating.

Of course, today, the blasted thing is working. I don't know if the manager changed something but I suspect that. I will provide the output requested.
ip -4 address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
altname wlp3s0
inet 172.19.84.159/24 brd 172.19.84.255 scope global dynamic noprefixroute wlo1
valid_lft 80466sec preferred_lft 80466sec
4: wlx502b73e0375f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 172.19.84.215/24 brd 172.19.84.255 scope global dynamic noprefixroute wlx502b73e0375f
valid_lft 86380sec preferred_lft 86380sec
5: wlx1cbfcef3e3e8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 172.19.84.100/24 brd 172.19.84.255 scope global dynamic noprefixroute wlx1cbfcef3e3e8
valid_lft 82887sec preferred_lft 82887sec

I have 6 other machines logged in that I would have expected to have at least one or more third octet differences. All have 172.19.84.xxx. I will mark this solved no later than the 24th, when everyone will be present to test.
Thanks for all offers of assistance.

All good. The network manager said the they reduced the size of the network.