On Thu, 11 Mar 2021, Pablo Neira Ayuso wrote:
> On Wed, Mar 10, 2021 at 04:51:26PM -0700, Marc Aurèle La France wrote:
>> On Tue, 9 Mar 2021, Pablo Neira Ayuso wrote:
>>> On Mon, Mar 08, 2021 at 09:25:28PM -0700, Marc Aurèle La France wrote:
>>>> On Tue, 9 Mar 2021, Pablo Neira Ayuso wrote:
>>>>> On Mon, Mar 08, 2021 at 09:21:20AM -0700, Marc Aurèle La France wrote:
>>>>>> On Mon, 8 Mar 2021, Pablo Neira Ayuso wrote:
>>>>>>> On Sun, Mar 07, 2021 at 06:16:34PM -0700, Marc Aurèle La France wrote:
>>>>>>>> In the non-bridge case, the REJECT target code assumes the REJECTed
>>>>>>>> packets were originally emitted by the local host, but that's not
>>>>>>>> necessarily true when the local host is the default route of a subnet
>>>>>>>> it is on, resulting in RST packets being sent out with an incorrect
>>>>>>>> destination MAC.  Address this by refactoring the handling of bridged
>>>>>>>> packets which deals with a similar issue.  Modulo patch fuzz, the
>>>>>>>> following applies to v5 and later kernels.

>>>>>>> The code this patch updates is related to BRIDGE_NETFILTER. Your patch
>>>>>>> description refers to the non-bridge case. What are you trying to
>>>>>>> achieve?

>>>>>> Via DHCP, my subnet's default route is a Linux system so that it can monitor
>>>>>> all outbound traffic.  By doing so, for example, I have determined that my
>>>>>> Android phone connects to Facebook despite the fact that I have no such app
>>>>>> installed.  I want to know, and control, what other behind-the-scenes
>>>>>> (under-handed) traffic devices on my subnet generate.

>>>>>>> dev_queue_xmit() path should not be exercised from the prerouting
>>>>>>> chain, packets generated from the IP later must follow the
>>>>>>> ip_local_out() path.

>>>>>> Well, I can tell you dev_queue_xmit() does in fact work in prerouting
>>>>>> chains, as it must for the bridging case.  The only potential problem I've
>>>>>> found so far is that the RST packet doesn't go through any netfilter hooks.

>>>>> That's the issue, Netfilter rejects code from the IP layer, so the
>>>>> packets follows the ip_local_out() path.

>>>> ... which sets an incorrect destination MAC.  Also, in this case, netfilter
>>>> doesn't reject any such thing.  It doesn't even "see" the RST packet
>>>> dev_queue_xmit() sends out.  That's OK as there is no further need to
>>>> process such a packet.

>>> dev_queue_xmit() skips the policy in the local out path for the
>>> generated RST packet. If you want to plain reject using
>>> dev_queue_xmit() then you have to use the ingress hook.

>>>> At least, the device whose connection request is being denied
>>>> doesn't hang anymore...

>>> The neighbour cache selects the destination MAC from the destination
>>> IP address of the RST packet.

>>> Your patch also refers to non-bridge scenario (no br_netfilter in
>>> place).

>>> Could you describe what you're trying to achieve in plain layman terms?

>> I will (re-)do no such thing because you are refusing to make sense.

>> It's OK that the bridge code uses dev_queue_xmit() to send out an RST packet
>> that has correct MACs, but that doesn't make another trip through netfilter.

> It's not OK that the bridge uses dev_queue_xmit().

> That was an ugly solution to make the REJECT target work from
> br_netfilter, because there was absolutely no other better way at that
> time to make it work.

> There has been now native support to reject traffic from the bridge
> from many years on through br_forward(), which is the way to go.

Ah, the cart before the horse.  I'll wait.

Later.

Marc.