[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/52074: -current npf map directive broken
Hi Roy !
Would be possible, but I think we are not gaining any benefit from the
Before the packet filter we see the originating interface. That is the
one for which we need to count the bytes sent.
After the packet filter we see either no change most of the time, some
other local interface or nothing.
So I would prefer just to look the the originating interface.
There is one subtle case for not being able to find the correct local
interface from the source address.
In BSD multiple interfaces can have the same IP address. In this
situation we cannot correctly determine
the correct interface from the source address alone for bytes-sent
As this didn't work properly up to now we are not making things worse
with respect to bytes-sent accounting.
On 05/11/17 22:42, Roy Marples wrote:
On 11/05/2017 21:33, Frank Kardel wrote:
I think the solution is much simpler (as I mentioned before).
If we actually take look at ip_output we see roughly following
1) insert ip options
2) create IP header unless forwarding or raw output
3) handle routing (choose output interface)
4) if no source address is set, use the interface address of the
5) handle IPSEC
6) run packet filter
7) check whether we are sending from a valid local address (our
8) do xmit accounting
9) handle TSO offloading or packet not needing fragmentation and output
via interface -> done
10) handle checksum offloading/calculation
11) handle fragmentation output fragmented packets
During 1...5 the assumption/requirement that non IP_FORWARDING packets
must originate from local addresses holds.
Number 6 breaks this assumption in case of a redirected remote address
to a local address. There the test in 7 relies
on a requirement that cannot be guaranteed after packet filter NAT
Moving ia pickup and !IP_FORWARDING local address check from 7 to 5a
will achieve what we want (guard against from invalid local addresses).
IFA accounting would correctly measure bytes-sent at the right local
address involved in the redirect scenario.
I am currently running a check on local address violations before the
packet filter call. The invariant that 1..5 follow the local address
requirement holds so
far. Traffic processed is: normal connections, ipsec transport/NATT,
Can somebody verify that strategy as a correct solution?
NB: the current fix has the drawback of at least miscounting output
bytes and missing some local checks.
Why not grab the pre-filter address at 5 and if the post filter
address is NULL, use the pre-filter address?
Would that work and solve the counting issue as well?
Main Index |
Thread Index |