[Winpcap-users] Winpcap in Intanium machine

[Fish]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gianluca Varenni wrote:
> Fish wrote:
> > Forgive me for asking, but WHY does WinPcap *rely* on
> > unaligned access?!
> 
> There are a number of reasons for that, but one of them is
> simply that WinPcap was developed over the years by people
> (including myself) that were still learning about problems
> like misaligned access.

Ah. Okay. Sorry. Been there myself. :)


> In general there are two reasons for misaligned access in
> the WinPcap driver:
>
> 1. due to an implementation choice, the packets are stored
> in the ring buffer without any padding, so the header prepended
> to each packet can start at a non-aligned address. This is
> what probably causes the crash that the OP is experiencing.

Sounds likely.


> This can be changed (by putting padding bytes at the right
> spots) but requires touching a very critical part of the
> capture engine (the ring buffer code).

Critical or not, it needs to be done from the sounds of it.


> 2. when we access the packet contents for filtering, the
> header fields are inevitably misaligned. In that case the
> only solution would be using macros when reading the header
> fields from the packets to avoid misalignment errors on
> architectures like Itanium (this is exactly what wireshark
> does).

Right! That's what we do in our Hercules project as well. [*]


> Since we decided not to support Itanium, we relied on the
> fact that unaligned accesses are supported on x86/x64 (the
> platforms that we support).

I understand. But my point is regardless of whether it works or not it's
arguably *incorrect* (or at the very least quite inefficient).


> I hope this answers your questions.

It does.

But I'm as yet still unconvinced as to the validity of your reasoning behind
your apparent reluctance to change it. One should not, IMO, be so reluctant
to change critical code if the situation warrants it (and IMO it does).

Now I understand the decision is ultimately yours to make and that you know
what your capabilities are as well as what's best for WinPcap, etc. I
understand all that.

I'm just trying to gently convince you otherwise, that's all. :)

You seem to be a very conscientious and skilled developer which I guess is
why I'm so surprised about your apparent reluctance to properly address this
issue. I haven't looked at WinPcap's driver code in a long while now but I
certainly hope this particular piece of code isn't in the gawd-awful messy
state it was in many years ago. If it still is then I guess I can understand
your reluctance to change it (house of cards and all that).

But if it's in reasonably good shape however then I think you should
seriously reconsider your decision not to change it.

With that hope in mind I've attached some modified macros that we ourselves
use in our Hercules project. Today's mainframes, just like Intel and several
other architectures, can also stand unaligned accesses just fine (except for
certain very specific privileged instructions of course). Because our
emulator is designed to be portable however (and thus capable of running on
pretty much ANY host platform/architecture), we use the attached portability
macros when accessing any area of emulated storage. (Note: they also
portably handle host platform endianess issues too and didn't bother
removing that part even though that's probably not an issue for you).

I hope you find it useful as an example of how you should be able to easily
accomplish your goal with minimal risk and maximal efficiency/payoff.

Respectfully submitted,
- -- 
"Fish" (David B. Trout) - fish at softdevlabs.com
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52

[*] http://www.turbohercules.com, http://www.hercules-390.org



-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.8.0 (Build 2158)
Charset: us-ascii

wj8DBQFK0RQ3SPXX9MTuPioRAmE8AJ9Z5btaDLR/jtAsKLTXJIkAjBFEgwCg35Dx
XQ1NQDy9fCr6JXPI9GVo18o=
=Aksr
-----END PGP SIGNATURE-----