I would encourage those with these open cases to join the EFT. Once you join,
you get to interface directly with the BU, with direct eyes-on from the
developers.
Jeff
From: The EDUCAUSE Wireless Issues Community Group Listserv
On Behalf Of Rios, Hector J
Sent: Wednesday, June 09, 2021 2:32
The log “chatter: lat_client_add(422): Failed to add client” is documented in
CSCvv78366. The release notes for 8.10.151 say that it is resolved, but it is
not. From the troubleshooting I’ve done, even on MR5, it appears this bug is
purely cosmetic. I have not had issues connecting to APs
Easiest way to prevent user-centric devices from actively using your headless
device network is to block your identity provider from the headless roles so
users can't sign in to resources.
From: The EDUCAUSE Wireless Issues Community Group Listserv
on behalf
> On Jun 9, 2021, at 8:59 AM, Michael Dickson wrote:
>
> I'm curious if anyone is doing anything to prevent/discourage 802.1x capable
> devices (laptops, tablets, smartphones) from connecting to the IoT network.
> We would prefer these things stay on eduroam and currently use device
>
I'm curious if anyone is doing anything to prevent/discourage 802.1x
capable devices (laptops, tablets, smartphones) from connecting to the
IoT network. We would prefer these things stay on eduroam and currently
use device fingerprinting to deny access to our "devices/IoT" (MAB)
network.
Mike
I took over from our previous wireless admin a few years ago and went through
an extensive project to consolidate and clean up our SSIDs. Every use case
seemed to have their own SSID multiplied by each site - it was a confusing mess
for everyone. After lots of research and consultation with
We haven't spun up MPSK yet, but we do have an SSID for MAC auth. Our 3
broadcasts right now are:
Auth
Gear
Visitor
The "Gear" network is for MAC auth, IoT, game consoles, etc. Users still don't
really know what "IoT" means, so we tell them its for all their "wireless gear".
Auth is
