| created | 2019-10-15T01:39:55Z |
|---|---|
| begin | 2019-09-13T00:00:00Z |
| end | 2019-09-14T00:00:00Z |
| path | src/sys |
| commits | 2 |
| date | 2019-09-13T01:31:24Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/if_tun.c | log | diff | annotate |
| message |
tweak tun/tap kn_data to be more consistent with everything else. for EVFILT_READ, kn_data is now like FIONREAD and reports how many bytes there are to read. previously it would report how many packets were available to read, which is not something i've seen anywhere else. for EVFILT_WRITE, report the max number of bytes a write can do. previously it was if_mtu bytes, now it is if_hdrlen + if_hardmtu bytes, which is the same as what the write path uses as it's maximum message size. discussed with and ok visa@ |
|||
| date | 2019-09-13T01:47:51Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/if_pflog.c | log | diff | annotate |
| message |
avoid the use of a custom bpf copy function. currently pflog prepares a pfloghdr and then passes that, the original mbuf, and a pflog copy function to bpf. bpf matches on the original packet, and then if bpf decides it wants the packet it uses the custom function to copy the packet for userland to read. the custom function patches the packet so you see the packet after nat and rdr and af-to and so on. however, this means bpf is matching on the original packet and reporting a patched packet. this is also the only use of a custom copy function in the tree, and it relies on some behaviours that should be internal to bpf to get away with it. this pulls the patching up so it's done before the packet is given to bpf. this simplifies the code a bit, and means bpf is now matching on and reporting the same packet. removing this custom copy code also means that we can get rid of that functionality from the bpf_mtap_hdr function. ok sashan@ visa@ |
|||