Or, it hasn't acquired it yet because it hasn't passed through the Ethernet
hardware. So it'll read as the generic MAC address for "me" (0:0:0:0:0:1)
until it actually goes on the wire and comes back off again. This is
almost certainly what's happening in the outgoing packet.
In the case of the reply packet, which is an ICMP error message, the source
MAC address is all zeroes - this may simply be an indication saying "this
packet could have come from anywhere, please don't reply". The packet
causing the ICMP error message is detailed within the ICMP message itself,
and the host where the error originated is detailed in the IP header.
.... runs some tests on own hardware ....
OK, now I'm confused. I'm watching tcpdump of some perfectly ordinary
stuff going on between a 2.2.16 machine (helium, using eepro) and a 2.4.1
box (lithium, using via-rhine). Here's an NTP exchange:
10:01:51.113583 < 0:50:ba:aa:77:88 0:0:0:0:0:1 ip 90:
lithium.chromatix.org.uk.ntp > helium.chromatix.org.uk.ntp: v4 client strat
4
poll 6 prec -17 dist 0.019088 disp 0.036071 ref
helium.chromatix.org.uk@3191479248.131119996 orig 3191479248.135523006 rec
-0.004402999 xmt +62.985828995 (DF) (ttl 64, id 0)
4500 004c 0000 4000 4011 da7b c0a8 ef6b
c0a8 ef68 007b 007b 0038 1076 2304 06ef
0000 04e3 0000 093c c0a8 ef68 be3a 1bd0
2191 148f be3a 1bd0 22b1 a2a4 be3a 1bd0
2191 148f be3a 1c0f 1f10 ecb7
This packet is incoming to helium, and it shows the MAC address of lithium
along with the so-called "me" address I mentioned.
10:01:51.123585 > 0:0:0:0:0:0 0:aa:0:aa:7a:86 ip 90:
helium.chromatix.org.uk.ntp > lithium.chromatix.org.uk.ntp: v4 server strat
3 p
oll 6 prec -16 dist 0.015533 disp 0.026077 ref
dns.lancs.ac.uk@3191478910.586125016 orig 3191479311.121352002 rec
+0.002871999 xmt +0.003857000 (ttl 64, id 42171)
4500 004c a4bb 0000 4011 75c0 c0a8 ef68
c0a8 ef6b 007b 007b 0038 621a 2403 06f0
0000 03fa 0000 06ad 9458 0804 be3a 1a7e
960c 49ba be3a 1c0f 1f10 ecb7 be3a 1c0f
1fcd 24e1 be3a 1c0f 200d b270
This one is outgoing, and it contains helium's *OWN* MAC address, and the
all-zeroes one. I'm fairly sure NTP doesn't use broadcast, at least in my
configuration.
10:08:24.365128 M 0:0:94:61:aa:83 1:0:0:0:0:0 0004 50: snap atalkarp aarp
len 28 op 256 htype 256 ptype 0x9b80 halen 6 palen 4
aaaa 0300 0000 80f3 0001 809b 0604 0001
0000 9461 aa83 00ff 00a3 0000 0000 0000
00ff 00ad
This is an interesting one - it's a multicast packet from one of my Macs,
performing some obscure AppleTalk thing (AARP == AppleTalk Address
Resolution Protocol, so it's really not that obscure). Notice the
pseudo-MAC is different here than in the incoming NTP packet. The real
MAC, in the first MAC field, is that of the Mac sending the AARP query
(turns out to be the Quadra, after searching through the control panels on
the several Macs I have).
.... reconsiders situation ....
Looks like it could either be a bug, or an obscure feature which neither of
us have noticed yet. From the tcpdump manpage: "On ethernets, the source
and destination addresses, protocol and packet length are printed." This
may well be the case, but it doesn't match up with what's showing up in the
above traces, or in yours either.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi@cyberspace.org (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/