Whoops! It turns out that I forgot to change my DNS hosting after my move of my domain to my new registrar. It turns out that the new guys don’t actually do DNS hosting (at least, not in an obvious way), which is astounding for a company in the domain name business. Anyway, thanks to the free DNS hosting provided by zoneedit.com, we’re back up and running.
You’d think I’d have remembered to fix this, since I used to run a company that sold DNS hosting. Sigh…
The folks at Network Solutions either do underhanded and annoying things when talking to customers from customer service, or the representatives are just not very good at their jobs.
I called NetSol today to try to complete the transfer of a domain name to another registrar. I’m tired of paying $30+ per year for something that should be nearly free, and regardless, is 1/5 the cost elsewhere. I asked the polite individual on the other end of the line for my authorization code. She asked me why I wanted to transfer, and (like an idiot) I said it was due to cost.
She proceeded to tell me that she couldn’t complete the transfer without her customer service department calling me back tomorrow between 9:15 and 5:00 Eastern. I am booked in meetings almost all day tomorrow, so I was annoyed but I accepted it. I did ask her, though, why she bothered to ask me why I wanted to transfer if she knew full well that she couldn’t help me at all. She said something like "They tell me I have to ask these questions."
I decided to try again. This time when the rep asked my why I was transferring, I said "because I want to." She obviously didn’t have this on the script, so she essentially asked if it was because of price. I said that it was not, and that it had more to do with wanting to try other services. She had my auth code sent over 30 seconds later.
Folks, this is what kills reputations. Customer service should be there for, you know,
The whole domain business is questionable to me, and I’m sure they all pull this crap. Still, I’m willing to shop around to see if anyone else even pretends to be helpful. No more NetSol for me.
One more tangent while we’re reminiscing about the Good Old Days. There’s a major power outage going on in San Francisco right about now, which may be the result of human error, to put it nicely 
It’s funny how this stuff still happens despite oaths to the contrary by data center providers. But it does!
A few years ago, my company had a lot of equipment co-located at a Switch & Data facility. They are (were?) a nationally recognized, relatively well respected data center company, and the location we were at had all of the modern trimmings: nice cages, dual utility power, a monstrous diesel generator, tons of A/C, controlled access, yada yada…
One day, predictably enough, both utility power circuits went down. The batteries kicked in and the diesel started to spin up. It got halfway up to operating RPM, but there it stayed. The local Switch team converged on the site and tried to get into diesel room. Only – it was locked!
But it wasn’t locked! You see, when the gigantor humungous diesel fired up, it started sucking tons of air. The wasn’t sufficiently ventilated, as it turned out, although nobody ever would have known, because they always tested with the door open (since they were in there watching anyway).
So there they were, with the diesel running way under operating RPM because it couldn’t get enough air, and they couldn’t get in to the room to diagnose it, because the door opened out and it was therefore vacuumed shut!
They wound up having to break the door down (not easy with a heavy commercial door and jamb), and hours later, the site came back online.
Data centers are a pain. Try to have at least three.
I just received my copy of Network Routing: Algorithms, Protocols, and Architectures a couple of days ago, and I’ve been making my way through it slowly but surely. This book covers computer networking theory and practice, with a strong bias toward IP-based networks. Lots of people in the network engineering world really only understand end systems – network drivers, host configuration, host security, and so forth. Even when I was studying for my CCIE certification several years back, I was mostly studying configuration and debugging of network routing, rather than the principles that govern it.
I had the opportunity to take a couple of grad classes from Professor Deep Medhi, the book’s first author, and I always enjoyed the content. At that point in my career, I was running an ISP and studying for my CCIE cert, and he seemed at the time to be the only CS professor I’d ever met who actually understood IP networking.
So, if you have an interest in the theory that goes into the practice, this is a great book. It’s written at a graduate level, and it’s very light on introductory material (if you manage to learn IP by reading Chapter 1, I’d like to meet you!), but if you’re an IP network professional, you should be well prepared to absorb this book.
If you have an NDIS driver that calls NdisMRegisterDevice(), be aware of how installing under a Vista UAC elevation affects your device object’s symlink.
As Ken discusses at length, objects created by users are created, by default, in a session-local namespace. So, consider the NdisMRegisterDevice() documentation:
SymbolicName
Pointer to an NDIS_STRING type containing a Unicode string that is the Win32-visible name of the device being registered. Typically, the SymbolicName has the following format: \\DosDevices\\SymbolicName.
If you follow this advice, your driver will create its symbolic link in whatever session happens to be current. During boot-up, the right thing will happen, but during initial installation of your driver, it will be created in the namespace of whoever is doing the installing. On downlevel operating systems, this was OK too, since the person who is most likely to be running the Win32 app to connect to the device is also the user who did the installing.
But under Vista, things are different. To do the installation, users are prompted to elevate, and the link creation ends up happening in the wrong place.
The solution is to follow the advice in the WDK topic Local and Global MS-DOS Device Names:
A driver that must create its MS-DOS device names in the global \DosDevices directory can do so by creating its symbolic links in a standard driver routine that is guaranteed to run in a system thread context, such as DriverEntry. Alternatively, the global \DosDevices directory is available as \DosDevices\Global; drivers can use a name of the \DosDevices\Global\DosDeviceName to specify a name in the global directory.
So, since binary-compatible drivers (9x) are a thing of the past, and since virtually every caller of NdisMRegisterDevice() will be in a user’s context during installation (until the first reboot), it’s safest to change to always using \\DosDevices\\Global\\<devicename>.
Anyone who has implemented a VPN has probably had to deal with MTU issues (unless you use a managed service). We’ve had code in our products for years to handle various MTU-related cases, and I’m going through some of it now. In double-checking our implementation, I took a peek at the relevant RFC, RFC 1191. In the introduction can be found this wonderful prediction:
It is expected that future routing protocols will be able to provide accurate PMTU information within a routing area, although perhaps not across multi-level routing hierarchies. It is not clear how soon that will be ubiquitously available, so for the next several years the Internet needs a simple mechanism that discovers PMTUs without wasting resources and that works before all hosts and routers are modified.
Woulda been nice…
At any rate, this is one of those IP features that is often handled incorrectly by firewalls. If you don’t allow Datagram Too Big messages (ICMP Type 3, Code 4) through, you are effectively killing performance (or even connectivity) for any paths with a Path MTU of less than your NIC’s MTU.
This is becoming more important: tunnel interfaces are proliferating, and as security consciousness increases, we’re only going to see more of this. For non-TCP-based tunneling protocols (IPSec, PPTP, GRE, L2TP, L2F, …) the carried packets are interface MTU minus overhead, so if you add, say, 100 bytes of overhead per packet, you wind up with a tunnel interface MTU of only 1400 bytes. Unless you want to have tons of frags, you have to listen for and handle Path MTU messages.
There are two common symptoms to path MTU problems:
bigpackets in a session, such as (for example) when a terminal services client is painting the desktop.
So, if you’re an implementor of a firewall (or similar), pay attention to proper handling of Path MTU messages. And if you’re an end user and notice any of these symptoms, try removing firewalls and NAT devices and see if the problem disappears. It could be due to dropped PMTUD messages.
Ken has a good write-up of a feature
we found while working on a customer’s SMB networking issue: SMB is incompatible with (overload) NAT.
This is amazingly broken, and seems to me like an excellent opportunity for a DoS in a terminal server environment. Regardless, Ken’s walk-through of his debugging procedure is worth a read.
After donating a nontrivial amount of my Thanksgiving weekend to studying, I am pleased to report that I passed my re-certification exam and am still CCIE #5444.
I had complained about a few books previously; now I have some empirical data to help me better evaluate them. First, let me say that I was pleasantly surprised with one Cisco Press book, Network Security Principles and Practices by Saadat Malik. Things got a little unclear when he got deep into crypto, but otherwise, this is hands down the best of the books I read this weekend.
The rest of the books were not… good. Having taken the exam, I stand by my estimate from my last post that the official exam guide addresses, at best, 25% of the subject matter. Without discussing specific exam items, I can tell you that I saw very detailed questions from a wide range of topics, including Token Ring, BGP, Ethernet, IP addressing, and lots of other non-security-specific topics, virtually none of which were covered (or at least covered adequately) by any of the books or RFCs I read.
As bad as the books were, I am pleased to report that the exam is great, from a technical perspective. For the most part, the questions were difficult, precise, and intelligently crafted. There were some very difficult crypto questions, and it was obvious that the writers of those items were waaaay more comfortable with the subject matter than any of the book authors. And we’re not just talking protocols, either – there were actual algorithm questions.
Overall, I’m happy with the certification. It’s expensive and is a bit diluted compared to the 90’s, but it still seems to me to be the best one out there. And, best of all, it’s done for another two years. Just in time, too; I’m behind on some (network) driver stuff.
Pop quiz: would I still be happy with the exam content if I had not passed?
I have finally started studying in earnest for my CCIE re-certification. I’m taking the Security specialization exam (which makes more sense for me, considering what I do for a living). I looked at the exam blueprint, and (surprisingly?) not much has changed since last time.
I decided to try actually ordering a book, since they keep raising the price of the exam. The one I got was marketed as the official exam guide from Cisco Press. I got that book last week, and yesterday I opened it up to see what it was like.
Wow. It is bad. No, it’s terrible. Seriously. I can’t imagine how it got published; the author clearly didn’t remember much of what he apparently once knew, detail-wise, and he didn’t bother to go back and look things up. Furthermore, the book appears to have had no editor, as there are various grammar and spelling bugs and even, in one case, a blatant margin note from the author to the effect of is this right?
I’ve taken a lot of tests in my life, for certifications and otherwise, and cisco’s CCIE exams are among the hardest. I can tell you that this book will prepare you for maybe 25% of the questions. I feel bad for anyone who shells out $300 for a test after preparing by reading this book.
Anyway, the worst stuff by far is the crypto stuff. It really appears to me that nobody knows this stuff, at least at Cisco Press. There are minor problems everywhere – things like MD-5 is difficult to decrypt
. Another Cisco Press book posed the following question: What is the only way to defeat a man-in-the-middle attack?
– with the absolutely stunningly insightful answer Cryptology
.
Maybe I’m just being too picky, but I think I’m not, for two reasons: 1) This particular security exam is supposed to be among the most difficult and detailed of security exams, and the kind of sloppiness in this book will make you fail, and 2) security is Very Hard Stuff, and security pros need to know their subject matter cold. Security mistakes resulting from getting it almost right
can be devastating.
At a quick glance, Wikipedia seems to be more accurate than most of these books (but proceed with caution down that path), but if you really want to grok security, from a crypto standpoint anyway, read Applied Cryptography by Bruce Schneier. Twice.
Speaking of recent Passthru changes, there’s a not-so-recent set of changes to the Passthru INFs in the XP+ DDKs. If you originally did your IM INFs before that time, it’s time to re-check them. In particular, there were changes around the CopyInf directive.
Speaking of which, I mailed Johan Marien at Microsoft today to let him know that I think the Passthru sample should be made redistributiable, since so many IM drivers are based on it directly. If you agree, you might want to drop him a note in support. Or, leave a comment here and I’ll forward everything on to him.
UPDATE: Thomas Divine points out in the comments that there are known bugs in 3790 Passthru, and also that there is a redistributable version available at wd-3.com. See his comment for details.