I was thinking less robust - since there are not very many valid opcodes for
aarp at this point, just check both pletohs(pd[x]) and pd[x] against the
table.
I agree, it's bad enough with the NFS stuff (where they have a significant
benefit of not moving a LOT of data around), but here, we're talking about
TWO BYTES! And they are copying it ANYWAY... Jeesh.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@xxxxxxx
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxx]
> Sent: Wednesday, December 08, 1999 4:52 PM
> To: Neulinger, Nathan R.
> Cc: 'ethereal-dev@xxxxxxxx'
> Subject: Re: [ethereal-dev] yep, damnit... it's the linux kernel
> screwing with the packet dat a...
>
>
> > How annoying... Should ethereal do any handling of this, or
> should we
> > consider it being broke, and not care?
>
> Well, there might be some heuristics that could cope with it -
> unfortunately, we'd have to know whether the capture file came from a
> Linux system, and "we're running on Linux/not running on
> Linux" doesn't
> necessarily correctly tell us that.
>
> *I* consider the Linux mechanism broken - if you have a mechanism in
> your OS that purports to deliver raw copies of all packets sent
> from/received on your machine (or, if promiscuous, all packets on your
> network segment), I think it reasonable to expect that you'll get the
> raw data from those packets, exactly as they appeared on the wire.
>
> If nothing else, they could perhaps do a copy-on-write on the
> packet, so
> that the copy handed to the raw packet socket doesn't get
> munged, and do
> so only if there *is* a raw packet socket.
>
