Cookie Notice

As far as I know, and as far as I remember, nothing in this page does anything with Cookies.


On the Uselessness of Campus Tech Support, or "Go Away, Kid. You Bother Me."

In time, this story will be one I think about and laugh.

I am not there yet.

There is a student-led group whose charter is to find interesting people with interesting stories, coach them a bit, and have them tell those stories to a larger audience. If you think you know what I'm talking about, you're probably right. And I'm their web/tech guy. In general, this is a bit of a "fixer" role: "You want to tell the world about something? You want an image on the web page? Got it. Done."

I went to our website before a meeting two weeks ago, preparing to fix some of our donor pages and set a link for ticket sales, and found it wouldn't load. Both on my Windows 7 laptop and my Android phone. I went to the admin console on the hosts' site and that worked, but the page wouldn't load. Nor could I connect via FTP. Traceroutes went so far, then died out. And, while traceroute was further than other people took it, there were other people in the group who could not connect to our website.

I called tech support, and the engineer said "works for me".

I turned off my phone's wifi and connected via 3G, and it came up just fine.

And I felt so stupid, because I should've tried that first.

And I felt powerless, because now this meant I had to engage campus Tech Support.

I work fairly regularly with the computing group on campus, mostly in the Big Iron corner of the department, and, when I can address an email to Larry and write "Hey, Larry? Our VM is down, and my boss wants it up", Larry is uniformly intelligent, prompt, professional and helpful, and my problems are uniformly respected and solved. (There is no actual "Larry", but the people who whose names I could use are good people who I don't want to include in a spittle-flecked rant such as this.)

But, when I submit a trouble ticket, I know I'm going to have a bad time.

For reasons I'll get to later, I say that Tech Support is batting .0030. I gave them a 90% chance of dropping the ticket without any interaction at all, and a 75% chance, if I get a reaction, of being turfed to someone inexplicable.

At the end of this process, this is what I can say:
  • At home, over wifi, everything works just fine.
  • On the phone, over 3G and 4G data networks, everything works just fine.
  • At various places with wifi around town, everything works just fine.
  • Over the wired campus network, everything works just fine.
  • Using the primary campus VLAN, which uses the same DNS server, it doesn't work.
  • Using the VLAN connecting to a large telephone company, everything works just fine. (I found this out very late, and this is why I consider this "solved" but not solved.)
  • Using a VLAN created so that academics from other institutions can use our network with their credentials, it doesn't work.
  • Replacing the DNS server provided via DHCP with Google DNS doesn't work.
  • Flushing the DNS cache doesn't work.
  • While I am 100% shut out, with my mobile gear, there are other people who are not, using similar gear.
  • Last time I had reason to work on this on campus, around Thanksgiving, everything worked just fine.
I found this problem in a building dedicated to an engineering discipline, and rechecked and sent the trouble ticket in a building used by the Computer Science department, so of course, when I got turfed, they sent me to the deal with the agricultural colleges' tech support team. 

They told me to try to flush the DNS cache. Then, when they learned that I was trying to connect to a server hosted by a commercial entity with a personal laptop, they declared "We're not here for fixing your computer, we're here to fix university equipment. Go Away, Kid. You Bother Me."

This is reasonable. I get that. And, I get that right now, there are networking people who are working 12-hour days because they're short-staffed.

There are two reasons I object to that argument.

First is, as I explain above, the problem is localized to the campus' VLAN. When I try to connect with the same access points but with the phone company VLAN, it works. When I try to connect with the campus wired network, it works. This means the problem is not:
  • Campus DNS
  • The server
  • My laptop
  • Software on my laptop
What remains? 

Second is, there's a pattern of behavior, of using this excuse to get out of fixing their network.

Example 1: There was supposed to be wifi in my lab. There was no wifi in my lab. Trouble ticket. My netbook. "Go Away, Kid. You Bother Me." I tweet a picture of my netbook physically touching the antenna but with the local VLAN not showing. One of the nice guys named Larry saw it and talked to the networking people. A tech came out. I recall the access point having scorch marks on it when he replaced it, but I might be embellishing the story in my mind.

Example 2: My old Android phone could connect to wifi, but once the connection was up, nothing would happen. Trouble ticket. My smart phone. "Go Away, Kid. You Bother Me." I download full IP tools, and eventually determine that, by the netmask, the IP address they gave me was not on the same network as the gateway. I conjecture that they didn't change the netmask when they grew the size of the DHCP pool, and I sent in the solution. A week later, my phone worked on their network.

The pattern, to me, is clear. They don't want to listen to their users, and you have to narrowly define the issue, to the point of true solution — "The access point is dead", "The networking configuration is crazy wrong" — before they will act. In this case, it's further into the networking stack than I can even think through. Most of the time I see "This is the protocol; Give me this configuration data and it works like thing that works well, but when you get something wrong, it's like a brick wall", so when it gets so specific — no protocols going from this one machine (and maybe others) to this other machine (and maybe others) will work, but in general, all is okay" — I'm out of my depth. My suspicion is that there's an unroutable internal local machine related to the VLAN that shares an unroutable private address with an unroutable machine at the hosting company, but that doesn't quite hold water and I have no way of testing that.

I have a "solution": Never use the university VLAN. This goes with my second "solution": Never submit a trouble ticket. It isn't the first "solution" I've had to use because the campus Tech Support has been so unhelpful, but as I don't have a real solution, I don't have any idea what's going on with things, so even if they were listening, I wouldn't have anything to say.

I'm the fixer. I'm supposed to make things work, and I'm lost. I don't have a solution, and they wouldn't listen if I had one. I think that's what angers me the most.

No comments:

Post a Comment