On Tue, Aug 14, 2007 at 11:13:31PM +0200, Ulf Lamping wrote:
> Joerg Mayer schrieb:
> > On Tue, Aug 14, 2007 at 06:25:20PM +0200, Ulf Lamping wrote:
> >
> >> I've implemented an experimental change in epan/addr_resolv.c, which strips down both flags before doing the actual manuf resolvings - which is working well:
> >>
> >> 04:05:06 -> Xerox
> >> 05:05:06 -> Xerox
> >> 06:05:06 -> Xerox
> >> 07:05:06 -> Xerox
> >>
> >
> > OK, BUT: The moment, the flag for locally assigned is true, resolving
> > should either stop or at least not mask out that bit
> Sorry, but I don't understand both comments that you gave :-(
Oops, sorry.
> Do you mean:
>
> 04:05:06 -> Xerox
> 05:05:06 -> Xerox
or Maybe: MC-Xerox ?
> 06:05:06 -> 06:05:06
> 07:05:06 -> 07:05:06
yes.
> >> Unfortunately, this "hides" both flags a little bit (although the display of these flags wasn't very "prominent" already before), so I'm unsure if the change should go into the Wireshark sources or not.
> >>
> >
> > Maybe do two passes: One without the mask, and if it doesn't return
> > success, then with the mask (0xfe) on the first octet?
> >
> Hmmm, I don't really understand you here, too.
>
> The removing of the bits are only done on a local copy in the manuf
> resolving function, not on the real data which will be displayed.
>
> What I didn't meant is that the displayed address number will be changed
> in any way. But, when you display the address as text Xerox_01:02:03,
> you won't see the flags mentioned in the Source/Destination columns. Of
> course you see still see them in the tree.
>
> Could you give a more verbose description of your points please?
resolv(04:05:06) -> xerox
resolv(05:05:06) -> fail, but it has mc-bit set,
so resolv(04:05:06) -> MC-Xeroxa with 0x04 = (0x05 & 0xfe)
Yeah, working with examples might help....
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
