Re: [WIRELESS-LAN] Apple product antenna strength vs other?

[David Logan]

Tim -

Have you examined the performance data the AP collects about each client
connection which is stored in the Mobility Conductor (fka MM)?

What does the Client Health metric tell you about each device?

Are you aware of the CLI commands you can execute on the MM/AP to look at
VERY detailed client connectivity characteristics?  Don't remember the
exact syntax, but it's in the neighborhood of ap debug client table and ap
debug client stats.  For example, you can pull debug stats on the Apple
devices that will show how many packets Tx/Rx at specific WiFi data rates
that the AP supports.  You can look at retry frames.  etc.

-- David

On Fri, Jun 4, 2021 at 10:18 AM Tim Tyler  wrote:

> Wifi experts,
>
>
>
> We are running Aruba MM with two controllers on 8.7.3.  Our AP’s are
> mostly AP-225’s.
>
> I have had complaints from one of our tech rooms that they were getting a
> poor signal.  I finally got around to testing that room out.  The location
> of the AP to this room is in an adjacent room.  When I test with Windows
> PC’s and Droid phones, the signal and performance is just fine.  When we
> tested with Macs and iphones, the signal strength was amazingly weak for
> all of them.  We tested with two Macs and two iphones as well as multiple
> PC’s and Android phones.  Only the Apple devices had weak signals.  Have
> any of you experienced a weaker antenna performance with your Apple devices
> on your campuses?
>
>
>
> If I put an AP in the room, the Apple devices are fine.  But I am
> surprised I would have to do this.  I would not have expected Apple devices
> to have weaker antennas.
>
>
>
> I did check in Airwave to make sure at least one of the Macs was still
> connecting to the same AP.  Any thoughts from anyone?
>
>
>
>
>
> Tim Tyler
>
> Network Engineer
>
> Beloit College
>
>
>
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email address and forward the email reply.
> Additional participation and subscription information can be found at
> https://www.educause.edu/community
>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] [EXTERNAL] [WIRELESS-LAN] Cisco 8540 Code Recommendation, Based on Stability?

[David Logan]

Curious if the high mem utilization correlates to client count?  (Both
assoc and unassoc)

On Wed, Jun 2, 2021 at 11:38 AM Jonathan Oakden 
wrote:

> Not sure as yet as we have been too busy to get this over to TAC at the
> moment since we identified the problem and came across this bug ID at the
> end of last week. It’s certainly the closest match we can find.
>
> We can see that most of our 2801 APs sit at around 30-50% memory
> utilisation, however around 6% of them (about 320) are currently above 60%
> which is unusual. These appear to be climbing steadily at around 3-4% per
> week as though there is a memory leak.
>
> We first spotted this when we got reports from students in a residence
> saying they were connected to wifi but nothing was working. Looking at the
> AP it was sat at 95% memory utilisation. Rebooting the AP restored service.
> However, we then looked at nearby APs and could see them climbing as well.
> It doesn’t appear to be all our APs but some unknown subsection of them.
>
> We only went to 8.10 as we had bought some 9105 APs.
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Lee H Badman <
> 00db5b77bd95-dmarc-requ...@listserv.educause.edu>
> *Date: *Wednesday, 2 June 2021 at 16:30
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] [EXTERNAL] [WIRELESS-LAN] Cisco 8540 Code
> Recommendation, Based on Stability?
>
> That one’s interesting because it shows affected code is 8.5(140.0), and
> only one case... is TAC agreeing it’s the same bug? Just curious.
>
> Lee Badman (mobile)
>
>
>
> On Jun 2, 2021, at 11:23 AM, Jonathan Oakden 
> wrote:
>
> 
>
> We are on 8.10.151 for the last couple of months here at Loughborough
> University in England. We think we are being hit quite badly by this bug:
>
> https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvp31778
>
> with around 6% of our 2802i APs being currently affected.
>
> It’s a really annoying bug too as to the user they appear to be connected
> to Wi-Fi but they have no network activity at all. Also the APs seem fine
> from a monitoring perspective unless you are either carefully monitoring
> their memory usage, or they get so far out of memory that they appear to
> lose their registration with the controller.
>
> As such, I really can’t recommend 8.10.151.
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Lee H Badman <
> 00db5b77bd95-dmarc-requ...@listserv.educause.edu>
> *Date: *Wednesday, 2 June 2021 at 16:06
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] [EXTERNAL] [WIRELESS-LAN] Cisco 8540 Code
> Recommendation, Based on Stability?
>
> Thanks, Jason and Dennis.
>
>
>
> *Lee Badman* | Network Architect (CWNE#200)
>
> Information Technology Services
> (NDD Group)
> 206 Machinery Hall
> 120 Smith Drive
> 
> Syracuse, New York 13244
> 
>
> *t* 315.443.3003  * e* lhbad...@syr.edu *w* its.syr.edu
>
> Campus Wireless Policy:
> https://answers.syr.edu/display/network/Wireless+Network+and+Systems
>
> *SYRACUSE UNIVERSITY*
> syr.edu
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Jason Mallon
> *Sent:* Wednesday, June 2, 2021 10:58 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] [EXTERNAL] [WIRELESS-LAN] Cisco 8540 Code
> Recommendation, Based on Stability?
>
>
>
> We are currently running 8.10.151 and have been for quite a few months
> with no issues as of yet.  Only two issues as of right now are a certain
> devices not being able to connect, working with TAC on those.  8.10.130 and
> 8.10.142 are covered in bugs.
>
>
>
> Thanks,
>
> *Jason Mallon* | Network Engineer III
>
> 
>
>
>
> OIT
> The University of Alabama
> jemal...@ua.edu
>
> 
>
>
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Lee H Badman <
> 00db5b77bd95-dmarc-requ...@listserv.educause.edu>
> *Date: *Wednesday, June 2, 2021 at 9:40 AM
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *[EXTERNAL] [WIRELESS-LAN] Cisco 8540 Code Recommendation,
> Based on Stability?
>
> Hi all,
>
>
>
> After a tumultuous series of code versions, awhile back we settled on
> 8.5.151.0 and hung on to it like grim death because it was very, very
> reliable.
>
>
>
> Given that 8.5 code goes end-of-support at end of 2021, combined with
> latest rounds of announced vulnerabilities, I’m looking for recommendations
> in the 8.10 train based on wanting stability above all. We have 3800s 

Re: [WIRELESS-LAN] Washlava

[David Logan]

I was curious so poked around.   Somewhat off-topic, and FWIW - Washlava
appears to be a really small startup, so.

https://www.crunchbase.com/organization/washlava

https://www.linkedin.com/company/washlava/people/




On Thu, Apr 29, 2021 at 8:24 AM Lee H Badman <
00db5b77bd95-dmarc-requ...@listserv.educause.edu> wrote:

> Curious if anyone can speak about the Wi-Fi and network requirements for
> Washlava laundry machines? I’m assuming they are WI-Fi only, but can find
> little of technical substance out on the web. I’m assuming they are
> PSK-only, etc but curious for those supporting them if they have been
> difficult to support as client devices, any wonky requirements or
> behaviors, etc.
>
>
>
> Thanks,
>
>
>
> Lee Badman
>
>
>
> *Lee Badman* | Network Architect (CWNE#200)
>
> Information Technology Services
> (NDD Group)
> 206 Machinery Hall
> 120 Smith Drive
> Syracuse, New York 13244
>
> *t* 315.443.3003  * e* lhbad...@syr.edu *w* its.syr.edu
>
> Campus Wireless Policy:
> https://answers.syr.edu/display/network/Wireless+Network+and+Systems
>
> *SYRACUSE UNIVERSITY*
> syr.edu
>
>
>
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email address and forward the email reply.
> Additional participation and subscription information can be found at
> https://www.educause.edu/community
>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] WPA3/OWE as campus solution?

[David Logan]

So - truly thinking out loud...

1. To Tim's point on lack of identity, the unstated requirement that could
be chosen to be fulfilled or not - there would need to be post-connect,
post-activity monitoring such that "bad activity" could be detected,
mitigated, prevented.  Anybody and any device within throw range of the
WLAN could connect and do whatever they want, within the bounds of
monitoring and enforcement at L2/L3/L7.  IRL - none of your doors have
locks, but you could choose to implement security cameras if someone you
don't know comes in to take the TV.

2.  It certainly suggests creating "network segments of one" to ensure that
the ability for a bad actor with a connected device cannot recon nor
exploit the other local connected devices, systems, apps, protocols.
 Suggests all local traffic would have to be firewalled or proxied, or else
the "network segment of one" architecture is unenforceable.

2a.   OR - it suggests a "don't care what happens between non-IT sanctioned
systems" - i.e. if a bad actor on a moderately sized
broadcast domain/subnet co-opts an attached non-IT device (like a smart TV)
and "does something bad" - that's OK.  This then suggests that *consequences
*of consumer IT product vendors implementing poor embedded software
systems/exploitable protocols would trickle down to the end-user and back
out to the consumer IT vendor.

2b.  Also suggests that if the local network segments are not policed using
firewalls of some sort, then the local IT-managed systems (if there ARE
any) - definitely need to be up to date on patch management and support and
vendor-product-software security.

-- Dave


On Fri, Apr 16, 2021 at 10:33 AM Lee H Badman <
00db5b77bd95-dmarc-requ...@listserv.educause.edu> wrote:

> Not sure how, or even if you’d need to depending on how it all worked. No
> plan here, just discussion..
>
>
>
> *Lee Badman* | Network Architect (CWNE#200)
>
> Information Technology Services
> (NDD Group)
> 206 Machinery Hall
> 120 Smith Drive
> Syracuse, New York 13244
>
> *t* 315.443.3003  * e* lhbad...@syr.edu *w* its.syr.edu
>
> Campus Wireless Policy:
> https://answers.syr.edu/display/network/Wireless+Network+and+Systems
>
> *SYRACUSE UNIVERSITY*
> syr.edu
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli
> *Sent:* Friday, April 16, 2021 10:23 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] WPA3/OWE as campus solution?
>
>
>
> How would you limit local services like printing, screen mirroring, media
> casting, etc?
> --
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Lee H Badman <
> 00db5b77bd95-dmarc-requ...@listserv.educause.edu>
> *Sent:* Friday, April 16, 2021 10:17
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject:* Re: [WIRELESS-LAN] WPA3/OWE as campus solution?
>
>
>
> Exactly- hance the notion of simplifying… relying on application security,
> 2FA etc for actual security while making simply connecting much, much
> easier.
>
>
>
> *Lee Badman* | Network Architect (CWNE#200)
>
> Information Technology Services
> (NDD Group)
> 206 Machinery Hall
> 120 Smith Drive
> Syracuse, New York 13244
>
> *t* 315.443.3003  * e* lhbad...@syr.edu *w* its.syr.edu
>
> Campus Wireless Policy:
> https://answers.syr.edu/display/network/Wireless+Network+and+Systems
> 
>
> *SYRACUSE UNIVERSITY*
> syr.edu
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli
> *Sent:* Friday, April 16, 2021 10:16 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] WPA3/OWE as campus solution?
>
>
>
> Just keep in mind that OWE does not have an identity layer.
> --
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Lee H Badman <
> 00db5b77bd95-dmarc-requ...@listserv.educause.edu>
> *Sent:* Friday, April 16, 2021 10:08
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject:* [WIRELESS-LAN] WPA3/OWE as campus solution?
>
>
>
> One more for you all- anyone contemplating ditching 802.1X for the BYOD
> side of your WLAN (not managed laptops and “business” clients) and
> simplifying with OWE/WPA3? Like… the open network that’s actually
> moderately secure leveraging the latest security 

Re: [WIRELESS-LAN] Rate Limits on Guest Wi-Fi

[David Logan]

Couple of technical comments:

1. Unless the rate-limiting was somehow incorporated into the WiFi AP and
doing funny WiFi / L4 protocol trickery for the enforcement mechanism to
achieve rate limiting, the transmit rate from the AP to the Client should
be as fast as the negotiated/determined WiFi TxRate is to the client and
from the client.   Vendors (like us at Aruba) have implemented features
that purposefully conduct such WiFi trickery to create "airtime fairness"
conditions or "preferential client" conditions.  But this isn't for
broadband/internet bandwidth consumption controls.

2.  Even if the upstream packetshaper is doing funny L3/L4/L7 protocol
things to reduce effective bandwidth consumption, each network link in the
topology will (should) transmit at fastest possible speeds.

3.  While there COULD be resulting consequences from an app/protocols
behavior that leads to more frequent packet transmissions on the network (
for example, more TCP ACKs being necessary due to more numerous TCP segment
transmissions) - these effects should be negligible, even on the WiFi
network


On Tue, Apr 13, 2021 at 3:57 AM Martin MacLeod-Brown 
wrote:

> That is an interesting question. I believe (perhaps wrongly) that rate
> limiting increases Wi-Fi inefficiency as you are then forcing the client to
> stay on the medium longer to transmit/receive data?
>
> We used to rate limit back in the day, but then removed all limits when we
> went to 802.11ac and didn’t notice any impact to the network…
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Curtis K. Larsen
> *Sent:* 13 April 2021 00:21
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* [WIRELESS-LAN] Rate Limits on Guest Wi-Fi
>
>
>
> Hello,
>
>
>
> Curious to know if any have removed or recently raised the rate limit on
> the Guest Wi-Fi network at your institution, particularly large
> universities or hospitals.  If you have taken that step how is it going?
> Also curious to hear what speeds you rate limit to if it is rate limited
> and how you came to that conclusion.
>
>
>
> Thanks,
>
>
>
> --
>
> Curtis K. Larsen
> *Wireless Network Engineer III*
>
> The University of Utah
>
>
>
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email address and forward the email reply.
> Additional participation and subscription information can be found at
> https://www.educause.edu/community
>
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email address and forward the email reply.
> Additional participation and subscription information can be found at
> https://www.educause.edu/community
>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] Wireless Segmentation and NAC

[David Logan]

> As mentioned on the page to download the NIST Zero Trust Network
> Architecture document
>
> "Zero trust focuses on protecting resources (assets, services, workflows,
> network accounts, etc.), not network segments, as the network location is
> no longer seen as the prime component to the security posture of the
> resource."
>
> https://csrc.nist.gov/publications/detail/sp/800-207/final
>
> The document itself says
>
> "Zero trust provides a set of principles and concepts around moving the
> PDP/PEPs closer to the resource. The idea is to explicitly authenticate and
> authorize all subjects, assets and workflows that make up the enterprise.”
>
> That is NIST-speak saying one of the principles of Zero Trust is to
> protect a resource as close as possible to the resource.  An example of a
> resource is information on a server etc.  NAC is the opposite, NAC is
> trying to protect a resource as far away from the resource as possible.
>
>
Respectfully, I don't believe the NIST document says or implies this.



*Clients are resources.   *

"All data sources and computing services are considered resources. A
network may be composed of multiple classes of devices. A network may also
have small footprint devices that send data to aggregators/storage,
software as a service (SaaS), systems sending instructions to actuators,
and other functions. Also, an enterprise may decide to classify personally
owned devices as resources if they can access enterprise-owned resources."

*The implementation of a ZTS architecture is up to the end-organization,
but can and should include network-layered security if the risk management
profile or Enterprise environment / complexity warrants it.*

[image: image.png]

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] Wireless Segmentation and NAC

[David Logan]

One more consideration for network design (especially L2, L3) and policy
enforcement architecture, somewhat relevant in this "segment the network?
And how?" portion of this thread:  the __performance effects/consequences__
of consumer IoT tech operating in the Enterprise setting (what I call
BYOT).

Here's a couple of examples:

All BYOT uses a combination of Bcast and Mcast for ease of installation,
peer product discovery and display/print/communications sharing use cases.
 Flatter networks with no Bcast/Mcast controls in place will propagate the
protocols, which in turn will make mobile devices WLAN radios "wake up"
more frequently than in an actual in-home location, driving battery life
down and causing weirdness for the apps that require these protocols on the
BYOT and/or mobile device.   This argues for some level of network
segmentation, likely beyond macrosegmentation and into microsegmentation.

VoIP architectures involving soft clients on BYOD/personal mobile devices
and locally hosted media gateways both cause and suffer from performance /
scalability problems when the underlying legacy network design forces
undesirable network and application behaviors.  For example, when a mobile
device calls another mobile device in the same "Enterprise" organization,
and those devices are associated with a network that prevents East-West
flows -- it will require the soft clients to use the (likely) DMZ hosted
VoIP Media Gateway to stitch together the call flow acting as a proxy.
 While these architectures seem to be waning in new deployments, they are
still widely deployed, and are frequently sized to support limited
inbound/outbound calling through the Media Gateway.  This, in turn, causes
individual call quality issues and media gateway capacity issues as
constant hairpinning occurs, mobile devices roam and need to rekey and
potentially re-IP, etc.  This argues for consideration of L2/L3/DDI design
as applied to BYOD, consideration of where East-West flows are required for
expected application behaviors / capacity / cost, in turn requiring
consideration for security policy and network-level enforcement.

-- David Logan
Aruba Networks, CTO office

On Mon, Feb 1, 2021 at 8:27 PM William Green 
wrote:

> I don't believe the network is the appropriate place for security to be
> applied, but witnessing the carnage... I believe there is a careful
> cost/benefit role.
>
> By n=1, I was clumsily referring to Terry Gray's Perimeter Protection
> Paradox-- wanting to get to a perimeter of 1 (or very few failing that).
>  From a client's perspective, it is more likely to be compromised stepping
> onto a large campus than staying at home.
>
> I haven't convinced myself, but think seriously about the following to
> help clients.  Setting aside the science DMZ exception case... First, if
> only doing stateful inspection, there are not the combinatorials that occur
> with  firewall rule sets.  In the case of most end user device, simple
> stateful inspection without additional restriction is probably 90% or more
> of any network isolation/security benefit.  Stateful inspection won't
> likely be coming to access layer switches real soon, but perhaps in a
> decade.  Second, on our campus most traffic is north/south now (very little
> east/west).  Where the north keeps going off to the cloud.  At our border,
> we deploy devices doing full-cone (but could perform stateful at the same
> rate) where Moore's Law has advanced things quite a bit.  Latency through
> them is under a millisecond at our scale (not perceptible in the general
> case, and given most is going north to the cloud not really detectable).
> Third, if one were to trust no devices (about where I am), then why not
> tunnel all packets from their origination through such a device.  Not to
> protect servers or enforce policies, but to protect the clients.  Hardware
> tunneling capabilities are showing up on access switches, and in the next
> turn of the silicon likely at more reasonable prices.  The same is needed
> for wireless (since that's were most devices are).  Sending all traffic
> northward for inspection is susceptible to east/west performance issues and
> increasing failure domains.  But if almost everything is already going
> north that failure domain is already being exercised.
>
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email address and forward the email reply.
> Additional participation and subscription information can be found at
> https://www.educause.edu/community
>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] 2.4Ghz channel designations

[David Logan]

This has been an entirely entertaining thread.  (Not to diminish the
original poster’s sincerity)

Also, hearing the consultant’s logic would either be thought provoking or
thoroughly entertaining BS.  Perhaps both!

On Wed, Aug 26, 2020 at 12:25 PM GT Hill  wrote:

> I knew someone was going to go there Lee. :-)
>
> On Wed, Aug 26, 2020 at 11:23 AM Lee H Badman <
> 00db5b77bd95-dmarc-requ...@listserv.educause.edu> wrote:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Perhaps his name is Channel McFly, and he’s looking to raise a Ruckus.
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>>
>> *On Behalf Of *Dan Lauing
>>
>>
>> *Sent:* Wednesday, August 26, 2020 12:21 PM
>>
>>
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>>
>>
>> *Subject:* Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] 2.4Ghz channel
>> designations
>>
>>
>>
>>
>>
>>
>>
>> I have never heard of that before. That is extremely interesting.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Aug 26, 2020 at 11:18 AM SWARTZ, POLA 
>> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Amen
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Smile,*
>>
>>
>>
>>
>>
>>
>> *Pola Swartz*
>>
>>
>> *WAN/Wireless Infrastructure Manager*
>>
>>
>> *Department of Technology Services*
>>
>>
>>
>>
>>
>>
>> *780 Grant St., Denver, CO 80203
>> *
>>
>>
>>
>> 
>>
>>
>>
>> 
>>
>>
>>
>> 
>>
>> #p
>> 
>>
>> 720-423-3603 | c
>>
>> 303-905-9520
>>
>> | dpsk12.org 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>>
>>
>>
>> 
>> 
>> 
>> 
>>
>>
>>
>>
>>
>>
>> Students First . Integrity . Equity.
>>
>> Collaboration. Accountability . Fun
>>
>>
>>
>>
>>
>>
>> *Never out smart your common sense...*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>>
>> on behalf of Brady J. Ballstadt 
>>
>>
>> *Sent:* Wednesday, August 26, 2020 10:15 AM
>>
>>
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>>
>>
>> *Subject:* [EXT] Re: [WIRELESS-LAN] 2.4Ghz channel designations
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Find a new consultant.
>>
>>
>>
>>
>>
>> Brady Ballstadt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:*The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of John Rodkey
>>
>> 
>>
>>
>> *Reply-To: *The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>>
>>
>> *Date: *Wednesday, August 26, 2020 at 11:13 AM
>>
>>
>> *To: *"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>>
>>
>> *Subject: *[WIRELESS-LAN] 2.4Ghz channel designations
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> For many years I have consistently used channels 1, 6, and 11 as
>> non-overlapping channels wherever 2.4Ghz is deployed.  I have a consultant
>> who is suggesting
>>
>> using all 11 channels in our high density dorm situations, arguing that
>>  signal interference will affect throughput less than the delays from
>> protocols where the 3 channels are within hearing distance of each other.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> This doesn't make sense to me.  If you in your situation have found using
>> all 11 channels to be an effective solution vs the 3 channel
>> non-overlapping approach,
>>
>> could you explain to me why you made that choice, and what your
>> on-the-ground experience is with this configuration?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Thank you!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> John Rodkey
>>
>>
>>
>>
>>
>>
>> Director of Servers and Networks
>>
>>
>>
>>
>>
>>
>> Westmont College
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Verification*: Unsure if this is a legitimate email to an email list?
>> Make sure it is
>>
>> recorded at *https://my.westmont.edu/it_emails
>> *
>>
>>
>>

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[David Logan]

Pondering... that implies that a heavyweight roaming event could change the
MAC.

 If true, that implies the WiFi roaming architecture considerations is even
more critical unless change of MAC doesn’t matter to the overall system
design and app behavior (I.e multimedia activity while physically roaming)

On Fri, Jul 31, 2020 at 9:54 AM Jake Snyder  wrote:

> It should change the next time it associates.
>
> Sent from my iPhone
>
> On Jul 30, 2020, at 1:02 PM, GT Hill  wrote:
>
> 
>
> From what I understand it will keep the same MAC longer if it passing
> traffic at that 24 hour mark.
>
> GT Hill
>
> On Thu, Jul 30, 2020 at 1:44 PM Rios, Hector J <
> hector.r...@austin.utexas.edu> wrote:
>
>> I’ve done several tests on an iPhone 7 and there have been instances
>> where the phone retains the same private MAC addr longer than 24 hours. Has
>> anyone else done more testing?
>>
>>
>>
>> Hector Rios, Wireless Network Architect
>>
>> The University of Texas at Austin
>>
>>
>>
>>
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Enfield, Chuck
>> *Sent:* Friday, July 10, 2020 4:14 PM
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>>
>>
>>
>> Ahh.  I glossed right over the 24-hour part.  That’s much less
>> distressing, but I’m going to have a beer anyway.
>>
>>
>>
>> Thanks Tim.
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli
>> *Sent:* Friday, July 10, 2020 5:04 PM
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>>
>>
>>
>> But why would that change anything? A user on campus for a football
>> game is there for less than 24 hours. The MAC address changes per ESSID,
>> every 24 hours. I don’t understand what changes here for that use case?
>>
>>
>>
>> It really only impacts mid to long term guests. So I guess in your
>> example, parents weekend may be the one that is affected. But even then,
>> dropping the lease times would solve the problem. I believe many wireless
>> vendors recommend a visitor lease time of 1-8 hours.
>>
>>
>>
>> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Date: *Friday, July 10, 2020 at 17:01
>> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>>
>> Tim,
>>
>> With Covid, any lease time would not be an issue. But how big were your
>> home football events / tailgate parties / parent weekends at Brandeis? I’m
>> focusing more on the impact of those events on the guest side of things.
>>
>> Brad
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv [
>> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> ] *On Behalf Of *Tim Cappalli
>> *Sent:* Friday, July 10, 2020 3:53 PM
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> *Subject:* [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step
>> further...
>>
>>
>>
>> Agreed on IPv6, but even for IPv4, I imagine most folks are running short
>> leases on a visitor network, so I don’t really think much changes here. If
>> your leases are 12 hours or less, there should be no impact.
>>
>>
>>
>> tim
>>
>>
>>
>> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Date: *Friday, July 10, 2020 at 16:51
>> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>>
>> Maybe a good use case for IPv6
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv [
>> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> ] *On Behalf Of *Enfield, Chuck
>> *Sent:* Friday, July 10, 2020 3:49 PM
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> *Subject:* [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step
>> further...
>>
>>
>>
>> Uhg.  Didn’t even think about that.
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Eric LaCroix
>> *Sent:* Friday, July 10, 2020 4:48 PM
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>>
>>
>>
>> We’re all going to need to check the TTL on DHCP leases… some of our
>> scopes will get eaten alive otherwise.
>>
>>
>>
>> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of "Floyd, Brad" <
>> bfl...@mail.smu.edu>
>> *Reply-To: *The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Date: *Friday, July 10, 2020 at 3:42 PM
>> *To: *"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a