From: "Nicolas de Pesloüan" <nicolas.2p.debian@free.fr>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: Netfilter mailing list <netfilter@vger.kernel.org>,
bridge@lists.linux-foundation.org, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Bridge] ebtables PREROUTING -drop
Date: Wed, 04 Aug 2010 18:39:57 +0200 [thread overview]
Message-ID: <4C5997DD.8080200@free.fr> (raw)
In-Reply-To: <alpine.LSU.2.01.1008041630390.19791@obet.zrqbmnf.qr>
Le 04/08/2010 16:32, Jan Engelhardt a écrit :
>
> On Wednesday 2010-08-04 16:25, Alex Bligh wrote:
>>
>>>>> Did you read http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html and
>>>>> http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png ?
>>>>
>>>> A useful improvement to those would be documenting where libpcap
>>>> (which does both input and, less well known, output) samples/injects
>>>> packets. I /think/ sampling is right on the left and injection right
>>>> on the right.
>>>
>>> pcap grabbing and injection is completely outside any of the graphs
>>> currently floating around.
>>
>> If by 'outside' you mean 'to the extreme left or extreme right'
>> that was my conclusion. But the absence of any documentation means
>> this makes debugging with tcpdump (for instance) harder
>> because you don't know where you are sampling.
>
> Well perhaps not extreme. If you inject into a tunnel, it may well
> walk through Xtables after all - but then of course, only in its
> encapsulated form.
>
>> I'm not 100% sure it is completely outside though. For instance,
>> if you do tcdump on a bridge device (as opposed to the corresponding
>> physical participant interface), isn't that after ingress ebtales
>> processing, but before egress? IE is in the graph somewhere.
>
> Huh, all once investigated already. See
> http://jengelh.medozas.de/images/nf-packet-flow.png for where
> in/egress happen to be. :)
Nice work!
May be just missing other netif_receive_skb() magic, like bonding for example.
Nicolas.
WARNING: multiple messages have this Message-ID (diff)
From: "Nicolas de Pesloüan" <nicolas.2p.debian@free.fr>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: Alex Bligh <alex@alex.org.uk>,
ratheesh k <ratheesh.ksz@gmail.com>,
bridge@lists.linux-foundation.org,
Netfilter mailing list <netfilter@vger.kernel.org>
Subject: Re: [Bridge] ebtables PREROUTING -drop
Date: Wed, 04 Aug 2010 18:39:57 +0200 [thread overview]
Message-ID: <4C5997DD.8080200@free.fr> (raw)
In-Reply-To: <alpine.LSU.2.01.1008041630390.19791@obet.zrqbmnf.qr>
Le 04/08/2010 16:32, Jan Engelhardt a écrit :
>
> On Wednesday 2010-08-04 16:25, Alex Bligh wrote:
>>
>>>>> Did you read http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html and
>>>>> http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png ?
>>>>
>>>> A useful improvement to those would be documenting where libpcap
>>>> (which does both input and, less well known, output) samples/injects
>>>> packets. I /think/ sampling is right on the left and injection right
>>>> on the right.
>>>
>>> pcap grabbing and injection is completely outside any of the graphs
>>> currently floating around.
>>
>> If by 'outside' you mean 'to the extreme left or extreme right'
>> that was my conclusion. But the absence of any documentation means
>> this makes debugging with tcpdump (for instance) harder
>> because you don't know where you are sampling.
>
> Well perhaps not extreme. If you inject into a tunnel, it may well
> walk through Xtables after all - but then of course, only in its
> encapsulated form.
>
>> I'm not 100% sure it is completely outside though. For instance,
>> if you do tcdump on a bridge device (as opposed to the corresponding
>> physical participant interface), isn't that after ingress ebtales
>> processing, but before egress? IE is in the graph somewhere.
>
> Huh, all once investigated already. See
> http://jengelh.medozas.de/images/nf-packet-flow.png for where
> in/egress happen to be. :)
Nice work!
May be just missing other netif_receive_skb() magic, like bonding for example.
Nicolas.
next prev parent reply other threads:[~2010-08-04 16:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-04 11:05 [Bridge] ebtables PREROUTING -drop ratheesh k
2010-08-04 11:05 ` ratheesh k
2010-08-04 11:43 ` [Bridge] " Jan Engelhardt
2010-08-04 11:43 ` Jan Engelhardt
2010-08-05 10:42 ` [Bridge] " ratheesh k
2010-08-05 10:42 ` ratheesh k
2010-08-05 11:11 ` [Bridge] " Jan Engelhardt
2010-08-05 11:11 ` Jan Engelhardt
2010-08-05 11:39 ` [Bridge] " ratheesh k
2010-08-05 11:39 ` ratheesh k
2010-08-04 11:49 ` [Bridge] " Nicolas de Pesloüan
2010-08-04 11:49 ` Nicolas de Pesloüan
2010-08-04 12:31 ` Alex Bligh
2010-08-04 12:31 ` Alex Bligh
2010-08-04 12:33 ` Jan Engelhardt
2010-08-04 12:33 ` Jan Engelhardt
2010-08-04 14:25 ` Alex Bligh
2010-08-04 14:25 ` Alex Bligh
2010-08-04 14:32 ` Jan Engelhardt
2010-08-04 14:32 ` Jan Engelhardt
2010-08-04 16:39 ` Nicolas de Pesloüan [this message]
2010-08-04 16:39 ` Nicolas de Pesloüan
2010-08-04 16:40 ` Jan Engelhardt
2010-08-04 16:40 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C5997DD.8080200@free.fr \
--to=nicolas.2p.debian@free.fr \
--cc=alex@alex.org.uk \
--cc=bridge@lists.linux-foundation.org \
--cc=jengelh@medozas.de \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.