ext_326266 (![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png)
mustangracer.livejournal.com) wrote in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png)
techrecovery2011-10-06 09:02 pm
mustangracer.livejournal.com) wrote in techrecovery2011-10-06 09:02 pm
(no subject)
I work with credit card terminals.
One of our "UBER IMPORTANT" (Head up ass!) client calls with an issue hitting an SSL address, keeps failing. I do some basic troubleshooting and tell them I will double check something with the device maker.
They have 2 models of devices that are identical except one is PN #AAA and one is PN#AAB. I have both of those in my inventory so I try to recreate the issue. No dice. Everything works fine here.
Must be their network (they have a jacked up setup). Of course, they say "NO WAY! OUR NETWORK IS UBER! Our IT guy is a god and you are dumb!"
So, they decide that they need to send me the "broken" equipment.
I plug it in. Nope. Doesn't work on my network either. Defective?
Since we didn't sell this specific piece O crap to them...I tell them to get a hold of the device reseller and troubleshoot it.
2 days - crickets.
I email them to see how they want their doorstops shipped back and the EVP has a holy hissy fit on me.
"Why didn't I do more? Why didn't I call their reseller and figure it out??"
Like you assholes are my only client and this isn't costing my company money that we will never get from you.
I take another look. Date's wrong in the device memory.
It's gone back to 2001.
DHCP. SSL certificates expired 11/22/2001.
God they are morons. Who doesn't fix the date/time on something before they even play with it?
Change date/time - renew/release the IP.
Huh, image that. SSL cert date of 10/06/2011 - works fine...
One of our "UBER IMPORTANT" (Head up ass!) client calls with an issue hitting an SSL address, keeps failing. I do some basic troubleshooting and tell them I will double check something with the device maker.
They have 2 models of devices that are identical except one is PN #AAA and one is PN#AAB. I have both of those in my inventory so I try to recreate the issue. No dice. Everything works fine here.
Must be their network (they have a jacked up setup). Of course, they say "NO WAY! OUR NETWORK IS UBER! Our IT guy is a god and you are dumb!"
So, they decide that they need to send me the "broken" equipment.
I plug it in. Nope. Doesn't work on my network either. Defective?
Since we didn't sell this specific piece O crap to them...I tell them to get a hold of the device reseller and troubleshoot it.
2 days - crickets.
I email them to see how they want their doorstops shipped back and the EVP has a holy hissy fit on me.
"Why didn't I do more? Why didn't I call their reseller and figure it out??"
Like you assholes are my only client and this isn't costing my company money that we will never get from you.
I take another look. Date's wrong in the device memory.
It's gone back to 2001.
DHCP. SSL certificates expired 11/22/2001.
God they are morons. Who doesn't fix the date/time on something before they even play with it?
Change date/time - renew/release the IP.
Huh, image that. SSL cert date of 10/06/2011 - works fine...
no subject
Especially when SSL is choking. That's usually the first thing out of my brain when an SSL connection craps out -- date/time skew on the client fooling it into thinking the SSL cert is expired (or in the future, which will break it too). I can only imagine what a mess they'd make of Kerberos .. "what does it mean, "clock skew too great"? .. :p )
no subject
no subject
no subject
But seriously? If you are going to get all high and mighty with my tech skills...check the f'ing DATE on the device first!
no subject
I have clients that make stupid mistakes like that. They get one freebie, and then the next time they get a bill for my minimum charge, which is $525.
no subject
$50.00 to perform the fix.
$4500.00 for knowing how to perform the fix.
--------
$5000.00
no subject