> It might be us
It is.
> The thing that seems odd to me, and please correct me if I'm wrong, is why
> does the Cisco neighbor with the Livingston if the password checksum was
> incorrect?
Some packets are bogus, some are not.
Here is an example of a bogus packet. We took two Portmasters and put them
on their own network with nothing else on it. I attached my laptop to the
network to run tcpdump. Sorry, I didn't bother to attach a different
vendor's equipment, so you can't blame it on them. What follows is an
example packet and an explanation of it. The gist of the matter is, ComOS
is setting the checksum field to zero on some packets, but not all. It is
interesting to note that the OSPF spec. requires the checksum field to be
zero when MD5 auth is used. This is also happening with simple
password, though, and therein lies the problem.
18:43:24.160548 206.158.4.36 > 224.0.0.5: OSPFv2-hello 48: backbone [|] [ttl 1]
4500 0044 23aa 0000 0159 e2ef ce9e 0424
e000 0005 0201 0030 ce9e 0424 0000 0000
0000 0001 6f73 7066 7061 7373 ffff fff0
000a 0201 0000
Let's take it apart.
4500:
Ip version 4, header len is 5 32-bit words, TOS = 0
0044:
total len = 44 bytes
23aa:
packet ID
0000:
flags and frag. offset
0159:
TTL = 1, protocol = 59 (ospf)
e2ef:
header checksum (at least they get this one right)
ce9e 0424:
src IP address
e000 0005:
dst IP address
0201:
OSPF version 2, packet type 1 (HELLO)
0030:
packet len
ce9e 0424:
Router ID
0000 0000:
Area ID = 0
**********************************************
********RED ALERT RED ALERT RED ALERT ******
**********************************************
0000:
CHECKSUM...the Portmaster set the checksum to ZERO!!!!!
0001:
Auth. type = 1 (simple password)
Figuring out the rest of the packet is left as an exercise for the reader.
(Like our OSPF password?)
pbd
-- Going to church does not make a person religious, nor does going to school make a person educated, any more than going to a garage makes a person a car.