What's the point of "oui Unknown"?

[John Hawkinson]

I guess it's been a long time since I've run tcpdump -e.
On an 802.11 packet, I see:

15:47:26.928534 0us BSSID:58:f3:9c:e5:a2:cf (oui Unknown) DA:Broadcast
SA:58:f3:9c:e5:a2:cf (oui Unknown) Beacon (MIT N) [18.0 24.0* 36.0 48.0
54.0 Mbit] ESS[|802.11]

That is:

58:f3:9c:e5:a2:cf (oui Unknown)

is from etheraddr_string() because 58:f3:9c does not appear
in the list of 14 ouis in oui.c:

29 /* FIXME complete OUI list using a script */
30
31 const struct tok oui_values[] = {
32 { OUI_ENCAP_ETHER, "Ethernet" },
33 { OUI_CISCO, "Cisco" },
34 { OUI_NORTEL, "Nortel Networks SONMP" },
35 { OUI_CISCO_90, "Cisco bridged" },
36 { OUI_RFC2684, "Ethernet bridged" },
37 { OUI_ATM_FORUM, "ATM Forum" },
38 { OUI_CABLE_BPDU, "DOCSIS Spanning Tree" },
39 { OUI_APPLETALK, "Appletalk" },
40 { OUI_JUNIPER, "Juniper" },
41 { OUI_HP, "Hewlett-Packard" },
42 { OUI_IEEE_8021_PRIVATE, "IEEE 802.1 Private"},
43 { OUI_IEEE_8023_PRIVATE, "IEEE 802.3 Private"},
44 { OUI_TIA, "ANSI/TIA"},
45 { OUI_DCBX, "DCBX"},
46 { 0, NULL }

What's the thinking here?

Obviously there are thousands of OUIs, and most are not going to ever
be in tcpdump's list, and it seems like populating oui.c with 20,000
OUIs may not be the way to go.

The code to do this was added by Hannes Gredler in:

commit 64690e70e5559c14aade6b2bccb3c05f14718d4c
Author: hannes <hannes>
Date: Sun Apr 10 07:17:00 2005 +0000

plumb in oui-name resolution

and is currently (addrtoname.c):

510 if (!nflag) {
511 snprintf(cp, BUFSIZE - (2 + 5*3), " (oui %s)",
512 tok2str(oui_values, "Unknown", oui));
513 } else


It seems to me that without more robust support this is just annoying
noise and, at the very least, the Unknown oui printing should be
removed.

Thoughts?

--***@mit.edu
John Hawkinson

[Hannes Gredler]

On Sun, Oct 12, 2014 at 04:00:57PM -0400, John Hawkinson wrote:
| I guess it's been a long time since I've run tcpdump -e.
| On an 802.11 packet, I see:
|
| 15:47:26.928534 0us BSSID:58:f3:9c:e5:a2:cf (oui Unknown) DA:Broadcast
| SA:58:f3:9c:e5:a2:cf (oui Unknown) Beacon (MIT N) [18.0 24.0* 36.0 48.0
| 54.0 Mbit] ESS[|802.11]
|
| That is:
|
| 58:f3:9c:e5:a2:cf (oui Unknown)
|
| is from etheraddr_string() because 58:f3:9c does not appear
| in the list of 14 ouis in oui.c:
|
| 29 /* FIXME complete OUI list using a script */
| 30
| 31 const struct tok oui_values[] = {
| 32 { OUI_ENCAP_ETHER, "Ethernet" },
| 33 { OUI_CISCO, "Cisco" },
| 34 { OUI_NORTEL, "Nortel Networks SONMP" },
| 35 { OUI_CISCO_90, "Cisco bridged" },
| 36 { OUI_RFC2684, "Ethernet bridged" },
| 37 { OUI_ATM_FORUM, "ATM Forum" },
| 38 { OUI_CABLE_BPDU, "DOCSIS Spanning Tree" },
| 39 { OUI_APPLETALK, "Appletalk" },
| 40 { OUI_JUNIPER, "Juniper" },
| 41 { OUI_HP, "Hewlett-Packard" },
| 42 { OUI_IEEE_8021_PRIVATE, "IEEE 802.1 Private"},
| 43 { OUI_IEEE_8023_PRIVATE, "IEEE 802.3 Private"},
| 44 { OUI_TIA, "ANSI/TIA"},
| 45 { OUI_DCBX, "DCBX"},
| 46 { 0, NULL }
|
| What's the thinking here?
|
| Obviously there are thousands of OUIs, and most are not going to ever
| be in tcpdump's list, and it seems like populating oui.c with 20,000
| OUIs may not be the way to go.
|
| The code to do this was added by Hannes Gredler in:
|
| commit 64690e70e5559c14aade6b2bccb3c05f14718d4c
| Author: hannes <hannes>
| Date: Sun Apr 10 07:17:00 2005 +0000
|
| plumb in oui-name resolution
|
| and is currently (addrtoname.c):
|
| 510 if (!nflag) {
| 511 snprintf(cp, BUFSIZE - (2 + 5*3), " (oui %s)",
| 512 tok2str(oui_values, "Unknown", oui));
| 513 } else
|
|
| It seems to me that without more robust support this is just annoying
| noise and, at the very least, the Unknown oui printing should be
| removed.
|
| Thoughts?

make it better ;-) - what do you suggest ? - pull in a OUI table frequently ?

/hannes

[John Hawkinson]

Post by Hannes Gredler
make it better ;-) - what do you suggest ? - pull in a OUI table frequently ?
| the Unknown oui printing should be removed.

Because this feels like a half-implemented feature that turns into
an annoyance. Can we just remove the "Unknown" printing?



I also don't see a really good way to solve the problem you
want solved (though I don't realy want it solved...).

One approach would be to do a realtime lookup of OUIs,
such as in the DNS.

Put them in OUI.ARPA (or oui.tcpdump.org) and look them up
when -n is not specified? Maybe?

--***@mit.edu
John Hawkinson

[Hannes Gredler]

On Sun, Oct 19, 2014 at 05:47:41PM -0400, John Hawkinson wrote:
| Hannes Gredler <***@juniper.net> wrote on Sun, 19 Oct 2014
| at 23:11:56 +0200 in <***@hannes-mba.local>:
|
| > make it better ;-) - what do you suggest ? - pull in a OUI table frequently ?
|
| As I said, I think:
|
| > | the Unknown oui printing should be removed.
|
| Because this feels like a half-implemented feature that turns into
| an annoyance. Can we just remove the "Unknown" printing?

i don't find it annoying ;-) -
also it appears that this is the first "annoyance" report after 9 years.

| I also don't see a really good way to solve the problem you
| want solved (though I don't realy want it solved...).
|
| One approach would be to do a realtime lookup of OUIs,
| such as in the DNS.

wireshark periodically pulls in the OUI HTML page from IEEE and then does
some AWK magic to extract the OUI/string tuples ...

| Put them in OUI.ARPA (or oui.tcpdump.org) and look them up
| when -n is not specified? Maybe?

hmm perhaps we can add a check that -n flag
also turns off local OUI name resolution ?

[Michael Richardson]

| Because this feels like a half-implemented feature that turns into |
an annoyance. Can we just remove the "Unknown" printing?
i don't find it annoying ;-) - also it appears that this is the first
"annoyance" report after 9 years.
| I also don't see a really good way to solve the problem you | want
solved (though I don't realy want it solved...).
|
| One approach would be to do a realtime lookup of OUIs, | such as in
the DNS.
wireshark periodically pulls in the OUI HTML page from IEEE and then
does some AWK magic to extract the OUI/string tuples ...
| Put them in OUI.ARPA (or oui.tcpdump.org) and look them up | when -n
is not specified? Maybe?
hmm perhaps we can add a check that -n flag also turns off local OUI

If there was energy for oui.tcpdump.org, I'm pretty sure that I can some
places with big DNS infrastructure to host it. If the AWK script can
generate a DNS table, having that lookup out there is actually really really
valuable.

In the interim, I suggest removing the word "oui", and also the "unknown"
string. We'll report the things in our table, and just won't bother with
bytes of output that don't help.

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

[Michael Richardson]

Post by Michael Richardson
In the interim, I suggest removing the word "oui", and also the
"unknown" string. We'll report the things in our table, and just
won't bother with bytes of output that don't help.

That was my original proposal. Do you want a patch?

Yes.
If someone wants to integrate the ethercodes.dat file in a future patch,
great.

[Michael Haardt]

Post by Hannes Gredler
| Obviously there are thousands of OUIs, and most are not going to ever
| be in tcpdump's list, and it seems like populating oui.c with 20,000
| OUIs may not be the way to go.
| Thoughts?
make it better ;-) - what do you suggest ? - pull in a OUI table frequently ?

How about loading it from a local file that is updated externally? That's
how PCI and USB IDs are updated on many systems, and that's how arpwatch
gets its OUIs already (ethercodes.dat - vendor ethernet block list).
It is simple and allows local changes. Allowing to share the file between
tcpdump and arpwatch would be nice.

Michael

[Rick Jones]

Post by John Hawkinson
It seems to me that without more robust support this is just annoying
noise and, at the very least, the Unknown oui printing should be
removed.
Thoughts?

What would removing it do to scripts attempting to parse tcpdump output?

rick jones

[Michael Richardson]

Post by Rick Jones

Post by John Hawkinson
It seems to me that without more robust support this is just annoying
noise and, at the very least, the Unknown oui printing should be
removed.
Thoughts?

What would removing it do to scripts attempting to parse tcpdump output?

I'm thinking that we leave the () there, and just make it blank when we don't
know rather than say "oui unknown".

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

[Rick Jones]

Post by Michael Richardson

Post by Rick Jones

Post by John Hawkinson
It seems to me that without more robust support this is just annoying
noise and, at the very least, the Unknown oui printing should be
removed.
Thoughts?

What would removing it do to scripts attempting to parse tcpdump output?

I'm thinking that we leave the () there, and just make it blank when we don't
know rather than say "oui unknown".

I suppose that might be marginally less annoying, but then I don't use
-e all that often in the first place. Still, when I have, I've not been
bothered by the oui unknown messages.

rick

[John Hawkinson]

I have to say, the tcpdump output format has changed so much recently
that I think anyone with scripts has to keep pretty far on top of it,
but:

What really bugged me was I had to go source diving to figure out
why I was getting "oui Unknown."

I suppose we could improve the documentation on this, but I suspect
most people won't find it. That's why I'd rather it go.

--***@mit.edu
John Hawkinson