Of course, it was my fault.
When BOT House died, I swapped out the hard drive to EXP V's box, leaving everything pretty much the same. I gutted the corpse of BH and scattered the parts to the winds.
Today I'm dicking around with the new, improved EXP V. Even though it's off the laptop now, I'm still getting herky jerky sessions. So I do a tcpdump while playing to see if it's some kind of network issue. Sure enough, every time you're stuck in a doorway or whatever there is a sudden burst of udp packets, then it stops and goes back to normal game rhythm. I start thinking NIC drivers and I realize I have no idea what's in this thing. I do an "lspci" and discover it's a Broadcom NIC.
Same as the laptop.
I dig around in my parts pile and pull out an old reliable RTL8139. I put it in EXP V, disable the built-in Broadcom, bring up the box and BANG.
Duplicate IPv6 address.
It was the old BH NIC. I had hard-coded it to its EUI-64 address because, well, it just seemed like The Right Thing To Do. Now, I'm stuck with that (or I have to perform a lot of work I don't want to do).
And, As Fate Would Have It, it seems that Duplicate Address Detection is broken in a lot of IPv6 implementations. Check the RFC if you don't believe me. It's not entirely my fault. The stack SHOULD (as they say in RFC-speak) have pulled another address out of its ass, but it didn't.
But I changed the NIC's MAC address and that fixed that the next time the box was booted.
Now, EXP V seems to play better. Blaming it on AMD was obviously wrong, but in glorious 20/20 hindsight I realized I did this (disable the on-board NIC in favor of an RTL8139) on EXP IV as well. In fact I've had notorious bad luck with built-in NICs and Linux with just about every box that's crossed my path in the last ten years.
Maybe UT just works best on legacy hardware.
good information
ReplyDelete