ebtables PREROUTING -drop

ebtables PREROUTING -drop

[ratheesh k]

I  googled and  understood that "If we  DROP a packet at BROUTER chain
, it will be passed to upper layer  and netfilter subsystem will
process those packets .

What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?

[Bridge] ebtables PREROUTING -drop

[ratheesh k]

I  googled and  understood that "If we  DROP a packet at BROUTER chain
, it will be passed to upper layer  and netfilter subsystem will
process those packets .

What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?

Re: ebtables PREROUTING -drop

[Jan Engelhardt]

On Wednesday 2010-08-04 13:05, ratheesh k wrote:

>I  googled and  understood that "If we  DROP a packet at BROUTER chain
>, it will be passed to upper layer  and netfilter subsystem will
>process those packets .
>
>What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?

Depends on the table you are referring to.

Re: [Bridge] ebtables PREROUTING -drop

[Jan Engelhardt]

On Wednesday 2010-08-04 13:05, ratheesh k wrote:

>I  googled and  understood that "If we  DROP a packet at BROUTER chain
>, it will be passed to upper layer  and netfilter subsystem will
>process those packets .
>
>What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?

Depends on the table you are referring to.

Re: [Bridge] ebtables PREROUTING -drop

[Nicolas de Pesloüan]

Le 04/08/2010 13:05, ratheesh k a écrit :
> I  googled and  understood that "If we  DROP a packet at BROUTER chain
> , it will be passed to upper layer  and netfilter subsystem will
> process those packets .
>
> What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?

Did you read http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html and 
http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png ?

	Nicolas.

Re: [Bridge] ebtables PREROUTING -drop

[Nicolas de Pesloüan]

Le 04/08/2010 13:05, ratheesh k a écrit :
> I  googled and  understood that "If we  DROP a packet at BROUTER chain
> , it will be passed to upper layer  and netfilter subsystem will
> process those packets .
>
> What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?

Did you read http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html and 
http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png ?

	Nicolas.

Re: [Bridge] ebtables PREROUTING -drop

[Alex Bligh]

--On 4 August 2010 13:49:28 +0200 Nicolas de Pesloüan 
<nicolas.2p.debian@free.fr> 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.

-- 
Alex Bligh

Re: [Bridge] ebtables PREROUTING -drop

[Alex Bligh]

--On 4 August 2010 13:49:28 +0200 Nicolas de Pesloüan 
<nicolas.2p.debian@free.fr> 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.

-- 
Alex Bligh

Re: [Bridge] ebtables PREROUTING -drop

[Jan Engelhardt]

On Wednesday 2010-08-04 14:31, 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.

Re: [Bridge] ebtables PREROUTING -drop

[Jan Engelhardt]

On Wednesday 2010-08-04 14:31, 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.

Re: [Bridge] ebtables PREROUTING -drop

[Alex Bligh]

--On 4 August 2010 14:33:10 +0200 Jan Engelhardt <jengelh@medozas.de> 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.

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.

-- 
Alex Bligh

Re: [Bridge] ebtables PREROUTING -drop

[Alex Bligh]

--On 4 August 2010 14:33:10 +0200 Jan Engelhardt <jengelh@medozas.de> 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.

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.

-- 
Alex Bligh

Re: [Bridge] ebtables PREROUTING -drop

[Jan Engelhardt]

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. :)

Re: [Bridge] ebtables PREROUTING -drop

[Jan Engelhardt]

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. :)

Re: [Bridge] ebtables PREROUTING -drop

[Nicolas de Pesloüan]

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.

Re: [Bridge] ebtables PREROUTING -drop

[Nicolas de Pesloüan]

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.

Re: [Bridge] ebtables PREROUTING -drop

[Jan Engelhardt]

On Wednesday 2010-08-04 18:39, Nicolas de Pesloüan wrote:
>>> 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.

Well, bonding is not really part of Netfilter.
Then again, neither is ingress/xfrm ;-)

Re: [Bridge] ebtables PREROUTING -drop

[Jan Engelhardt]

On Wednesday 2010-08-04 18:39, Nicolas de Pesloüan wrote:
>>> 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.

Well, bonding is not really part of Netfilter.
Then again, neither is ingress/xfrm ;-)

Re: ebtables PREROUTING -drop

[ratheesh k]

On Wed, Aug 4, 2010 at 5:13 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Wednesday 2010-08-04 13:05, ratheesh k wrote:
>
>>I  googled and  understood that "If we  DROP a packet at BROUTER chain
>>, it will be passed to upper layer  and netfilter subsystem will
>>process those packets .
>>
>>What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?
>
> Depends on the table you are referring to.
>

Ok .
Could you please answer below question . i got little confused here .
This answer may solve some confusion .

What is the difference between  droppin a Pkt in Brouting chain of
Broute table and  Drop a Pkt in  nat prerouing chain of ebtables . Or
are they having same effect ? .

Re: [Bridge] ebtables PREROUTING -drop

[ratheesh k]

On Wed, Aug 4, 2010 at 5:13 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Wednesday 2010-08-04 13:05, ratheesh k wrote:
>
>>I  googled and  understood that "If we  DROP a packet at BROUTER chain
>>, it will be passed to upper layer  and netfilter subsystem will
>>process those packets .
>>
>>What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?
>
> Depends on the table you are referring to.
>

Ok .
Could you please answer below question . i got little confused here .
This answer may solve some confusion .

What is the difference between  droppin a Pkt in Brouting chain of
Broute table and  Drop a Pkt in  nat prerouing chain of ebtables . Or
are they having same effect ? .

Re: ebtables PREROUTING -drop

[Jan Engelhardt]

On Thursday 2010-08-05 12:42, ratheesh k wrote:
>>>
>>>What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?
>>
>> Depends on the table you are referring to.
>
>What is the difference between  droppin a Pkt in Brouting chain of
>Broute table and  Drop a Pkt in  nat prerouing chain of ebtables . Or
>are they having same effect ? .

Generally, nat and broute are intended to be a configuration databases 
only, where special semantics to standard verdicts can apply, as it does 
for broute. To avoid confusion, the use of DROP in nat is not 
advised, and iptables checks for such attempts. Ebtables doesn't, but 
then again, it's the 4th-order-stepson of iptables only...
deep down below in source code, DROP just does that - drop.

Re: [Bridge] ebtables PREROUTING -drop

[Jan Engelhardt]

On Thursday 2010-08-05 12:42, ratheesh k wrote:
>>>
>>>What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?
>>
>> Depends on the table you are referring to.
>
>What is the difference between  droppin a Pkt in Brouting chain of
>Broute table and  Drop a Pkt in  nat prerouing chain of ebtables . Or
>are they having same effect ? .

Generally, nat and broute are intended to be a configuration databases 
only, where special semantics to standard verdicts can apply, as it does 
for broute. To avoid confusion, the use of DROP in nat is not 
advised, and iptables checks for such attempts. Ebtables doesn't, but 
then again, it's the 4th-order-stepson of iptables only...
deep down below in source code, DROP just does that - drop.

Re: ebtables PREROUTING -drop

[ratheesh k]

On Thu, Aug 5, 2010 at 4:41 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> deep down below in source code, DROP just does that - drop.

1.  In ebtables Broute, if packet  gets  dropped , how it goes to ip
layer for further processing ?
2.  ip_route_input will be called on all frames hitting prerouting nat
table of ebtables . How it can decide where to route once it is past
prerouing hook (packet which are dropped on nat prerotuing of ebtables
) ?  /* i could be totally wrong here */


-Ratheesh


> On Thursday 2010-08-05 12:42, ratheesh k wrote:
>>>>
>>>>What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?
>>>
>>> Depends on the table you are referring to.
>>
>>What is the difference between  droppin a Pkt in Brouting chain of
>>Broute table and  Drop a Pkt in  nat prerouing chain of ebtables . Or
>>are they having same effect ? .
>
> Generally, nat and broute are intended to be a configuration databases
> only, where special semantics to standard verdicts can apply, as it does
> for broute. To avoid confusion, the use of DROP in nat is not
> advised, and iptables checks for such attempts. Ebtables doesn't, but
> then again, it's the 4th-order-stepson of iptables only...
> deep down below in source code, DROP just does that - drop.
>

Re: [Bridge] ebtables PREROUTING -drop

[ratheesh k]

On Thu, Aug 5, 2010 at 4:41 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> deep down below in source code, DROP just does that - drop.

1.  In ebtables Broute, if packet  gets  dropped , how it goes to ip
layer for further processing ?
2.  ip_route_input will be called on all frames hitting prerouting nat
table of ebtables . How it can decide where to route once it is past
prerouing hook (packet which are dropped on nat prerotuing of ebtables
) ?  /* i could be totally wrong here */


-Ratheesh


> On Thursday 2010-08-05 12:42, ratheesh k wrote:
>>>>
>>>>What will happen,  if we drop a packet at PREROUTING chain  of ebtables ?
>>>
>>> Depends on the table you are referring to.
>>
>>What is the difference between  droppin a Pkt in Brouting chain of
>>Broute table and  Drop a Pkt in  nat prerouing chain of ebtables . Or
>>are they having same effect ? .
>
> Generally, nat and broute are intended to be a configuration databases
> only, where special semantics to standard verdicts can apply, as it does
> for broute. To avoid confusion, the use of DROP in nat is not
> advised, and iptables checks for such attempts. Ebtables doesn't, but
> then again, it's the 4th-order-stepson of iptables only...
> deep down below in source code, DROP just does that - drop.
>