Profile cover photo
Profile photo
Phil Benchoff (N3PB)
129 followers
129 followers
About
Phil's posts

Post has attachment

Post has attachment
Small fixup of recent Dilbert.
Photo

Post has attachment
A little IPv6 from +Lifehacker.

Post has attachment
Here is a slide from "IPv6 in the DREN III acquisition" by Ron Broersma, 10 Jun 2014.  "Our #1 rule: if we can't get to the company or product website via IPv6, we won't consider such products."
Photo

Post has attachment
This comes from a building renovation on campus.  Only one of my coworkers could identify it.  Most of them laughed when I explained what it was.
Photo

Post has attachment
This showed up on Twitter today.  I thought, "Certificate authorities are kind of messed up, but this might be a bit excessive."  Oh, right, there's a state abbreviated CA too.
Photo

Post has attachment

Since it's throwback Thursday....
$user says he cannot download a particular file.  Sure enough, the download stops at the same place every time we try.  I download the file to a host outside our network with no problem but it stops at the same point downloading from that host to our network.  Slice and dice the file with dd and we get a 1k portion that will not download.  A quick look with xxd shows a block of \xb5 characters.  Sure enough, we cannot download a file of more than 70 bytes of \xb5.  (Oddly enough, x5b is no problem.)  +Eric Brown figures out that there is a framing error for every one of those packets on one of our links.  The same data coming in any other link is fine.
The only reason I had to believe that something like this is even possible is that I have seen it before.  Twenty or so years ago, we had a packet that would not cross our FDDI ring in one direction.  After a week or so of hair pulling, we figured out that a packet could not be received by one of our routers.  Cleaning the fiber optic connector fixed it.  (Cisco AGS+.  Chip was suspected to loose timing on certain bit patterns and dirty connector pushed it over the edge.)
We don't know exactly what's going on with the circuit in question, but I would never believe a small packet just won't go if I had not seen it before.  For once, ancient knowledge put us ahead in the diagnosis of a problem.

ping -p b5 -s 88  -c 100 x.y.z.net
[...]
--- x.y.z.net ping statistics ---
100 packets transmitted, 55 received, 45% packet loss, time 99068ms
rtt min/avg/max/mdev = 35.554/36.533/38.681/0.733 ms

$ ping -p 5b -s 88  -c 100 x.y.z.net
[...]
--- x.y.z.net ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99139ms
rtt min/avg/max/mdev = 35.571/36.476/39.362/0.768 ms

Post has attachment
This article http://www.ijs.si/time/temp-compensation/ says that temperature has a significant effect on the stability of a computer clock oscillator.  Here is a plot of ambient temperature versus frequency offset for a Beaglebone Black running NTP.  The board was not in a case.  I have put it into a cardboard box to see what happens, but it's pretty clear some temperature compensation would help.  This server does not have a local reference clock, so the time isn't all that good anyway.
Photo

Post has attachment
IPv6: It's Not New.  It's Now.  (downloadable images from ARIN)
Wait while more posts are being loaded