[MacTUG] Macs vs Minuwet

[Mike Patterson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Group,
Sorry, this is long.  You can skip it if issues regarding wireless
authentication and authorization on Macs don't interest you.

I've been told that at a previous MacTUG meeting, it was decided[0] that
since MinUWet was placed into enforcement mode, the Mac wireless
experience has become worse.  I'd like to address this.

I'm not certain how it's possible for MinUWet to cause issues with Macs.
 While there is a MinUWet client for Macs, the only platform which is
required to run it is Windows.  From a client perspective, what should
happen with a Mac is this:
1 connect to the uw-wireless SSID
2 get an IP address
3 fire up web browser
4 authenticate in the captive portal
5 redirect to https://minuwet.uwaterloo.ca
6 minuwet website determines that you're on a Mac, using a combination
of the user-agent string and a piece of Javascript that runs on the client
7 client is placed in post-minuwet mode.

It works the same for Linux and other non-Windows hosts.  Windows hosts
get asked to run the MinUWet client in what would be step 5a.  There is
nothing about this process that should be hostile to Macs, or any other
non-Windows platforms.  If anything, Windows users have a complaint that
they're underserved, but we all know why we're targeting their platform.

I assume that the consensus (about poorer performance for Macs on
wireless) came about as a result of the issues on the 25th of May.  What
happened then, and has been happening since, is nothing to do with Macs,
or even MinUWet per se.

As some of you may know, the issues of the 25th were related to a
network routing loop that caused the backend systems to have delayed or
interrupted communications with the wireless controllers.[1]  In other
words, the issue affected all wireless users equally.

I know there were some issues today as well (morning of the 8th of June)
and I am, quite frankly, mystified.  I changed something that shouldn't
have had any effect and the complaints slowed, but that could just be
because people gave up altogether, I don't know.  :)  I do know that
Monday mornings seem worst, and we're doing the best we can to keep an
eye on things, but debugging this sort of problem is rather difficult,
particularly with incomplete information.

All of this being said, I would be *extremely* interested in evidence
that Mac performance has been suffering wrt wireless.  I don't want to
seem to be a pain about this, but what evidence would be required would
be things like traffic captures (preferably full-content) along with
ntp-sycned timestamps, userids used, and MAC addresses.  We need to be
able to correlate logs on several different systems in order to find any
cause.

[0] - perhaps 'decided' is a bad word to use, but I'm not sure what fits
better.  Group consensus?  A majority, vocal minority?  Without having
been there I can't say.
[1] - for further information on how the backend works, you can refer to
my presentation slides from the IST PD seminar I gave a couple of months
ago: http://ist.uwaterloo.ca/~mpatters/Presentations/Wireless40.pdf .  I
realize that this presentation is a bit light on technical detail.  I do
have more detailed docs but they're terrible and not really suited for
public dissemination.  Contact me if you'd like to see them anyway.

Thanks,

Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkotlqYACgkQrqw9H9F0mCTZPgCdEs8hD4Dk9MI1PxoJFXL4JKjj
+noAnjXIsYlGBbs70L3Vcpua9zjlhhOY
=pU+Q
-----END PGP SIGNATURE-----