Guy Harris

The only way in which this is connected with macOS is that macOS's libpcap and tcpdump can write pcapng files in which not all the IDBs have the same link-layer...

Note that OFFSET + sizeof(int32) overflows to 0 on an ILP32 platform but not an LP64 platform, and probably not even on an LLP64 platform (cf. WinPcap) as long as...

For kernel BPFs, the `-O` is necessary because, without `-O`, it compiles to ``` (000) ld [-4] (001) jeq #0xf00ba4f jt 2 jf 3 (002) ret #0 (003) ret #65535...

I've checked change 26a30758eb9c64bdb26e72b611418085e3a31e13 into the trunk; it makes the interpreter more like the FreeBSD interpreter, which does more bounds checking and catches this issue. Unless somebody finds a problem...

Submitted by guy_harris (FYI - #if 0/#endif is a bit more convenient way to remove code.)

Submitted by guy_harris Works on eth0, doesn't work on the "any" device (which is what you get on Linux when you pass NULL as the device name; NULL might crash...

Submitted by None Interesting. Using a specific interface such as "eth0" solves the problem. I see, so in "any" mode, will raw+tp_mac point to meta-data when bpf_filter expects a data...

Submitted by None By the way, I found this while investigating this other bug: #169 so they are directly related :)

Was this intended to be an Nmap issue rather than an Npcap issue?

Why does nmap have its own version of libpcap?