| created | 2019-09-18T16:47:32Z |
|---|---|
| begin | 2019-08-16T00:00:00Z |
| end | 2019-08-17T00:00:00Z |
| path | src/sys |
| commits | 2 |
| date | 2019-08-16T04:09:02Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/ifq.c | log | diff | annotate |
| message |
ifq_hdatalen should keep the mbuf it's looking at, not leak it. ie, use ifq_deq_rollback after looking at the head mbuf instead of ifq_deq_commit. this is used in tun/tap, where it had the effect that you'd get the datalen for the packet, and then when you try to read that many bytes it had gone. cool and normal. this was found by a student who was trying to do just that. i've always just read the packet into a large buffer. |
|||
| date | 2019-08-16T19:53:32Z | |||
|---|---|---|---|---|
| author | procter | |||
| files | src/sys/net80211/ieee80211_crypto.c | log | diff | annotate |
| src/sys/net80211/ieee80211_crypto.h | log | diff | annotate | |
| message |
check that software de/encrypt is possible: under hardware offload, it needn't be. the stack must otherwise rely on every offloading driver correctly handling all frames governed by a given key. ok stsp@ |
|||