<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The U networks have an interstitial page that requires you sign in before using… could your DNS be trying to override their settings and keeping you from getting to the <a href="http://login.umn.edu">login.umn.edu</a> domain (or whatever it is - when hockey season starts next month {!!!!!!} I will know the exact login script)?<div><br></div><div>--</div><div>Ryan<br><div><div><div>On Sep 3, 2013, at 7:58 PM, Michael Moore <<a href="mailto:stuporglue@gmail.com">stuporglue@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I do have two colleagues here who have a lot of difficulty with recent<br>
Ubuntu installs (13.04) on various wireless chipsets they have tried.<br>
<br>
One of said colleagues has spent quite a lot of time troubleshooting it<br>
and has come to believe that gnutls cares more than it probably should<br>
about the certificate order it receives while trying to validate the<br>
certificate chain and eventually gives up, but he doesn't have complete<br>
evidence for this yet.<br></blockquote><div><br></div><div>This would apply only to the UMN Secure network, correct? I think the UMN and UMN Guest networks are unsecured. <br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In the past couple of days, I have heard from both of them that they have<br>
had more success and stability on wifi if they disable 802.11n and rely<br>
instead on 802.11g. You might give that a try...<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Me personally - I run Fedora 19 on campus daily and have a good stable<br>
wifi connection on UofM Secure using a RealTek RT2800 chipset in a little<br>
USB dongle ($12 Panda Wireless). My machine's built-in Broadcom BCM4311 is flaky to say the<br>
least, but does sort of work about half the time (hence I use the dongle instead).<br>
My current kernel is 3.10.7, but I haven't had to do anything special to<br>
get UofM Secure connected in years (since around when that wiki page first<br>
turned up). It should be PEAP/MSCHAPv2 as you already know.<br>
<br>
When last I ran Debian unstable about 4-5 months ago, I didn't yet have<br>
the RT2800 dongle and had generally a unreliable connection. It had been<br>
some degree of flaky for me through every Fedora release on various Intel<br>
and Broadcom chips back as far as I can remember.<br>
<br>
So if you can, try to disable 802.11n and see if that helps.<br></blockquote><div> </div></div><br><div>Weird. I've got an Intel Centrino Advanced-N 6205.
It works everywhere else, but I'll try anything. I've saved instructions
to disable 802.11n locally and I'll try it tomorrow. <br></div><div> </div>I've also got a Ralink 802.11g dongle of some sort I'll try out. <br><br></div><div class="gmail_extra">Thank you,<br>Michael Moore<br>
</div></div>
_______________________________________________<br>TCLUG Mailing List - Minneapolis/St. Paul, Minnesota<br><a href="mailto:tclug-list@mn-linux.org">tclug-list@mn-linux.org</a><br>http://mailman.mn-linux.org/mailman/listinfo/tclug-list<br></blockquote></div><br></div></div></body></html>