packets (based on the Ethernet type). "pppoes" has the side-effect that
subsequent filter expressions will test the PPP header and headers
in the PPP payload, not the link-layer header and headers in the
link-layer payload.
so that it's not EBUSY if we didn't get an EBUSY in a
DL_ERROR_ACK/DL_SYSERR reply, and our checks for EBUSY only catch that
case.
If we *did* get EBUSY on all the SAPs we tried, supply an error.
Make "dl_dohpuxbind()" always return a value, so we don't fall off the
end and return an error indication by accident.
to -1, set a "we're doing MPLS" flag, and check that flag rather than
checking for an off_linktype of -1; off_linktype can be -1 for reasons
having nothing to do with MPLS (e.g., a DLT_ of DLT_RAW), and those
should be handled as they have traditionally been.
Rename "gen_null()" to "gen_mpls_linktype()" to make it clearer what it
does (it checks the MPLS stack as well as the IP header).
instruction as an unsigned value, and, at least for comparisons, the
value is converted to unsigned anyway, as the A and X registers are
unsigned, and the Usual Arithmetic Conversions of C89 apply to
comparisons. Make ours unsigned as well. (On two's complement machines
- which means all machines we support - that won't be an issue for using
the constant field as an offset, either, as arithmetic in the BPF
virtual machine is 32-bit two's complement.)
centralize the MPLS check into gen_linktype() and backout the
specific checks in gen_proto_abrev(), gen_proto(), gen_host()
this adds as a by-product support for IPv6
values for an HDLC link (MTP2 is what's usually run on those links, with
MTP3 atop it); remove them. Also, boost dlt_count to match the number
of DLT_ values.
if we have a MPLS label stack deeper > 1 then generate a match
for a cleared bottom-of-stack-bit of the previous MPLS shim header
rather than just incrementing the offset;
if there is a compined expression of MPLS and IP like e.g.
"mpls && ip" | "mpls && ip host" | "mpls && ip src net"
then poison the linkoffset to make sure that other code generators
do not try to match link-layer protos like Q_ARP, Q_RARP etc.
introduce a new function gen_null() that matches against the first nibble
of the IP header and matches if the bottom-of-stack bit is set;
TODO: IPv6 stuff i.e. gen_host6() etc.
the size of the buffer we handed to it is insufficient to determine
whether we have the entire list of interfaces or not - if the amount of
space left in the buffer after adding an entry is non-zero but less
than the amount of space required by the next entry, the ioctl will stop
before adding the next entry, and not necessarily return an error.
The only way to ensure that we got all the data is to pass a buffer
large enough that the amount of space in the buffer *not* filled in
is greater than the largest possible entry.
We assume that's "sizeof(ifreq.ifr_name)" plus 255, under the assumption
that no address is more than 255 bytes (on systems where the "sa_len"
field in a "struct sockaddr" is 1 byte, e.g. newer BSDs, that's the
case, and addresses are unlikely to be bigger than that in any case).
"septel_set_datalink()".
It's also always the same, so get rid of "septel_get_datalink()".
Add an inject routine that just returns an error.
Get rid of a malloc() whose result was neither used nor freed.
Clean up indentation.
the mpls stack processing is broken:
for example "mpls 10000 && mpls 20000" does produce
reading from file ppp.pcap, link-type PPP (PPP)
(000) ldh [2]
(001) jeq #0x00000281 jt 2 jf 11
(002) ld [4]
(003) and #0xfffff000
(004) jeq #0x02710000 jt 5 jf 11
(005) ldh [6]
(006) jeq #0x00000281 jt 7 jf 11
(007) ld [8]
(008) and #0xfffff000
(009) jeq #0x04e20000 jt 10 jf 11
(010) ret #1514
(011) ret #0
the extra match for 0x281 at instruction #6 is broken and
a copy&paste artifact from the vlan code generator, which
in contrast does require the VLAN tag 0x8100 at every instance
inside a VLAN stack;
correct code should be:
(000) ldh [2]
(001) jeq #0x281 jt 2 jf 9
(002) ld [4]
(003) and #0xfffff000
(004) jeq #0x2710000 jt 5 jf 9
(005) ld [8]
(006) and #0xfffff000
(007) jeq #0x4e20000 jt 8 jf 9
(008) ret #1514
(009) ret #0
pcap_dumper_t. (Just doing an "ftell()" on the result of
"pcap_dump_file()" won't necessarily work on Windows, as Microsoft, in
their infinite wisdom, have multiple different versions of the C library
runtime, and if a DLL is built using one version, and another DLL or an
executable is built with another version, file descriptors and FILE *'s
opened in one of them cannot be used in the other.)
guy