MAC ffffffffffff

hmm, I know that this is a broadcast, but where does it come from? which host? which process?

You receive packets with a MAC-source ffffffff ??

It is possible to spoof the MAC-address by carefully constructing malformed packets and sending them across the network. In that case you won't be able to track the source down.

is there a way to tweak tcpdump or snoop to log just these packages?

datibbaW - I think you need additional options to tcpdump to get the info ahoffman is seeking (see below).

ahoffman - If your tcpdump is as nice as mine you can use:

tcpdump -l -n -e 'ether broadcast'

(the -l and -n are not necessary optons, but I like them.  The -e is what you really want to use in order to see link-level info)

in order to see all ethernet broadcasts, and to see the source MAC address (which I think you said you wanted).  Then just use your favorite inverse arp tool (i.e. rarp, arp -an, etc.) and you have the IP info.

All in all, I'd forget worrying about this (but I'll still take the pts hehe), unless you reeeeaallly want to give yourself a mind-numbingly granular, hands-on lesson in the different ways ethernet broadcasts are used, or are seeing abnomrally high levels of this sort of thing (ie.e abuse, DoS, etc)

Greetings to ahoffman - been a while.

Cheers,
-Jon

P.S.  Hey hey - I took a vacation from EE, and now I'm a topic expert.  Can't beat that.  

I'm familar with tcpdump and its option, just missed that for MACs. Thanks anyway.

Jon, arp cache is not updated when there was a broadcast, that's obvious 'cause it was a broadcast and not a directed connection.

The--Captain: could depend on the version of tcpdump i guess, cause the following command works as stated in the manual page.

# tcpdump ether dst 'ff.ff.ff.ff.ff.ff'
tcpdump: listening on eth0
...
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:33:59.299225 arp who-has 192.168.1.200 tell terminator

indeed - arp cache is not updated for broadcasts (what would be the point?) - I was just thinking that if you had the MAC address from a 'tcpdump -e' that you could potentially match it up in your arp cache to determine the IP of the perpetrator...

-Jon

datibbaW - indeed, my tcpdump will accept those arguments you specified.  I just found it quicker, more terse, and more revealing to use the arguments I specified.

-Jon

datibbaW, it did not exactly answer my question, but helped me to track down the MAC's source (good that I keept my /etc/ethers uptodate:)

Jon, hope you agree, datibbaW's answer was first.

I agree it was first - not sure I agree it was the 'most  correct' - how are you going to tell the src MAC without my argument?

In any case, don't sweat it - he needs the points more than I do.  Next time, point split

-Jon

> .. MAC without my argument?
see accepted answer.
But your suggestion works too, thanks (see split question in this TA)

So, you were able to see the src MAC without the '-e' argument?  If so, I am interested, as I thought '-e' was required to see this src MAC...

-Jon

It seems that when a computer sends a raw mac-frame tcpdump will print the source address; however, if the same computer sends an IP-frame tcpdump will print the source IP address which needs pinging and searching in the arp tables.

One way or another the -e argument is easier to use because it simply always shows the mac-src.

Jon: i'm not here for the points and i hope you were just kiddin.

Think nobody denoted somebody for just gathering points here (including me). My english is not perfect, but in all the years I participated at EE, I managed to figure out "points gatherer" and usefull answers. Years ago anybody answered instead of commenting, in the hope of "autograding", this behaviour has gone --in most TA-- and we, questioner and experts, can enjoy the discussions.
Enjoy, and enlarge upon this friendly policy :-))

Back to the question: Jon, datibbaW,
  the -e option seems to be necessary for the src MAC, otherwise these packets are not printed
This is at least on my Linux' and Solaris' tcpdump 3.4

Thank you all for giving me an answer which I should have found myself in the man-pages, shame on me ;-)

The only pts I need are to maintain my EE Pro, and I think that's covered regardless...

Sorry for the huge delay in response - email notifs only reach me about %50 of the time for some reason (the only way I noticed the additional responses here was because ahoffman recently pointed this out to me).

ahoffman - glad to hear I wasn't hitting the pipe too hard (as others have suggested hehe) when I was going on about the '-e' option...

>Jon: i'm not here for the points and i hope you were just kiddin.

I'm not here for them either, aside from my monthly EE PRo quota - EE Pro is not a solution panacea, btw, even though EE Pro members do not have to spend pts to access questions in the PAQ - if the search engine actually worked properly, I might take a different position...  I originally thought that EE Pro would offer improved services in this area (searches), but I was sadly mistaken.  Notice how I sign every response with "-Jon" - an EE pro search for "-Jon" reveals no results - go figure.

In any case, I thank Achim for the pt split...

Cheers,
-Jon