was expecting it to be set, thus ignored it.
bin/29509 - because ipft_cookie wasn't reset to 0 before making the ioctl
call for each variable, only the first name to find was used, each successive
call just used the cookie.
CVn: ----------------------------------------------------------------------
8 bytes of data were dropped.
- If the packet is a fragment, return. There is no UDP header in this case.
- Don't set the FI_SHORT flag. Already tested in `frpr_short()'.
- Remove unneeded test `!fin->fin_off'.
Approved by: Christos Zoulas <christos@netbsd.org>
ok yamt@
> MFC:
> Fix by dhartmei@
>
> replace finer-grained spl locking in pfioctl() with a single broad lock
> around the entire body. this resolves the (misleading) panics in
> pf_tag_packet() during heavy ioctl operations (like when using authpf)
> that occur because softclock can interrupt ioctl on i386 since SMP.
> patch from camield@.
ok yamt@
> MFC:
> Fix by dhartmei@
>
> ICMP state entries use the ICMP ID as port for the unique state key. When
> checking for a usable key, construct the key in the same way. Otherwise,
> a colliding key might be missed or a state insertion might be refused even
> though it could be inserted. The second case triggers the endless loop
> fixed by 1.474, possibly allowing a NATed LAN client to lock up the kernel.
> Report and test data by Srebrenko Sehic.
MFC:
Fix by dhartmei@
IPv6 packets can contain headers (like options) before the TCP/UDP/ICMP6
header. pf finds the first TCP/UDP/ICMP6 header to filter by traversing
the header chain. In the case where headers are skipped, the protocol
checksum verification used the wrong length (included the skipped headers),
leading to incorrectly mismatching checksums. Such IPv6 packets with
headers were silently dropped. Reported by Bernhard Schmidt.
ok deraadt@ dhartmei@ mcbride@
MFC:
Fix by mcbride@
Initialise init_addr in pf_map_addr() in the PF_POOL_ROUNDROBIN,
prevents a possible endless loop in pf_get_sport() with 'static-port'
Reported by adm at celeritystorm dot com in FreeBSD PR74930, debugging
by dhartmei@
ok mcbride@ dhartmei@ deraadt@ henning@
allowing rules to be set to match only ipv4/ipv6. And so ipnat must be updated
to actually set this field correctly but to keep things working for old
versions of ipnat (that will set this to 0), make the ioctl handler "update"
the 0 to a 4 to keep things working when people just upgrade kernels. This
forces NAT rule matching to be limited to ipv4 only, here forward, fixing
kern/28662
MFC:
Fix by dhartmei@
fix a bug that leads to a crash when binat rules of the form
'binat from ... to ... -> (if)' are used, where the interface
is dynamic. reported by kos(at)bastard(dot)net, analyzed by
Pyun YongHyeon.
state is not applicable. The fix just reverts the new code that blocked
packets where fr_addstate() fails. This is not correct in all cases, but
blocking them is a bit drastic and breaks existing functionality. The proper
fix is to change fr_addstate() to return:
- state added
- adding state failed
- adding state is not applicable
and then filter packets only in the second case. I am leaving this for someone
else.
MFC:
Fix by dhartmei@
The flag to re-filter pf-generated packets was set wrong by synproxy
for ACKs. It should filter the ACK replayed to the server, instead of
of the one to the client.
MFC:
Fix by dhartmei@
For RST generated due to state mismatch during handshake, don't set
th_flags TH_ACK and leave th_ack 0, just like the RST generated by
the stack in this case. Fixes the Raptor workaround.
the fastroute function so that it uses accurate packet information about
the packet being sent out rather than the packet received (impacts both
return-rst and return-icmp features.)
PR: kern/27093
are present or vice versa
* Fix matching of IPv6 state entries when the initial packet is a
sent to a multicast address. This includes not updating the address as
being fixed when a second (or further) such packet is seen before a reply.
* Disable code, for now, that limited how many ICMP packets could match a
state entry based on the number of real packets seen.
> ----------------------------
> revision 1.58
> date: 2004/06/23 04:34:17; author: mcbride; state: Exp; lines: +5 -3
> pfr_commit_ktable calls functions that can result in the current
> ktable being destroyed, which makes it unsafe in a SLIST_FOREACH.
>
> Fix from Chris Pascoe
> ----------------------------
> revision 1.56
> date: 2004/06/11 05:21:20; author: mcbride; state: Exp; lines: +5 -3
> Eliminate a dereference after pool_put when an inactive/no-longer referenced
> table is destroyed in pfr_setflags_ktable.
>
> Fix from Chris Pascoe
> ----------------------------
- pfsync (due to protocol # assignment issues)
- carp (not really a PF portion, but thought important to mention)
- PF and ALTQ are mutually-exclusive. this will be sorted out when
kjc@csl.sony.co.jp updates ALTQ and PF (and API inbetween)
reviewed by matt, christos, perry
torture-test is very welcomed.
peter