created | 2023-06-10T19:11:57Z |
---|---|
begin | 2023-06-05T00:00:00Z |
end | 2023-06-06T00:00:00Z |
path | src/sys |
commits | 3 |
date | 2023-06-05T08:37:27Z | |||
---|---|---|---|---|
author | sashan | |||
files | src/sys/net/pf.c | log | diff | annotate |
message |
pf_remove_state() should not attempt to remove state which is already removed. OK dlg@ |
date | 2023-06-05T08:45:20Z | |||
---|---|---|---|---|
author | sashan | |||
files | src/sys/net/if_pfsync.c | log | diff | annotate |
message |
pfsync_update_state() is too paranoid about pf_state::pfsync_state. For example it should not be surprised if caller asks to remove state from pfsync queue which has been removed already. That kind of race is sorted out later when pfsync_update_state() calls to pfsync_q_ins()/pfsync_q_del(). Change relaxes pfsync_update_state() to panic on sync_state value which is unknown. OK dlg@ |
date | 2023-06-05T11:35:46Z | |||
---|---|---|---|---|
author | bluhm | |||
files | src/sys/net/if.c | log | diff | annotate |
src/sys/net/if_loop.c | log | diff | annotate | |
message |
Do not calculate IP, TCP, UDP checksums on loopback interface. Packets sent over loopback got their checksums calculated twice. In the output path they were filled in and during TCP/IP input all checksums were calculated again to be compared with the previous result. Avoid this by claiming that lo(4) supports hardware checksum offloading. For each packet convert the flag that the checksum should be calculated to the flag that it has been checked successfully. Keep the flag that it should be calculated for the case that it may be bridged or forwarded later. A drawback is that "tcpdump -ni lo0 -v" reports invalid checksum. But that is the same with physical interfaces and hardware offloading. OK dlg@ |