* [Bridge] ebtables PREROUTING -drop @ 2010-08-04 11:05 ratheesh k 2010-08-04 11:43 ` Jan Engelhardt 2010-08-04 11:49 ` Nicolas de Pesloüan 0 siblings, 2 replies; 12+ messages in thread From: ratheesh k @ 2010-08-04 11:05 UTC (permalink / raw) To: bridge, Netfilter mailing list 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 ? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-04 11:05 [Bridge] ebtables PREROUTING -drop ratheesh k @ 2010-08-04 11:43 ` Jan Engelhardt 2010-08-05 10:42 ` ratheesh k 2010-08-04 11:49 ` Nicolas de Pesloüan 1 sibling, 1 reply; 12+ messages in thread From: Jan Engelhardt @ 2010-08-04 11:43 UTC (permalink / raw) To: ratheesh k; +Cc: Netfilter mailing list, bridge 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-04 11:43 ` Jan Engelhardt @ 2010-08-05 10:42 ` ratheesh k 2010-08-05 11:11 ` Jan Engelhardt 0 siblings, 1 reply; 12+ messages in thread From: ratheesh k @ 2010-08-05 10:42 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Netfilter mailing list, bridge 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 ? . ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-05 10:42 ` ratheesh k @ 2010-08-05 11:11 ` Jan Engelhardt 2010-08-05 11:39 ` ratheesh k 0 siblings, 1 reply; 12+ messages in thread From: Jan Engelhardt @ 2010-08-05 11:11 UTC (permalink / raw) To: ratheesh k; +Cc: Netfilter mailing list, bridge 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-05 11:11 ` Jan Engelhardt @ 2010-08-05 11:39 ` ratheesh k 0 siblings, 0 replies; 12+ messages in thread From: ratheesh k @ 2010-08-05 11:39 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Netfilter mailing list, bridge 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. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-04 11:05 [Bridge] ebtables PREROUTING -drop ratheesh k 2010-08-04 11:43 ` Jan Engelhardt @ 2010-08-04 11:49 ` Nicolas de Pesloüan 2010-08-04 12:31 ` Alex Bligh 1 sibling, 1 reply; 12+ messages in thread From: Nicolas de Pesloüan @ 2010-08-04 11:49 UTC (permalink / raw) To: ratheesh k; +Cc: Netfilter mailing list, bridge 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-04 11:49 ` Nicolas de Pesloüan @ 2010-08-04 12:31 ` Alex Bligh 2010-08-04 12:33 ` Jan Engelhardt 0 siblings, 1 reply; 12+ messages in thread From: Alex Bligh @ 2010-08-04 12:31 UTC (permalink / raw) To: Nicolas de Pesloüan, ratheesh k Cc: Netfilter mailing list, bridge, 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-04 12:31 ` Alex Bligh @ 2010-08-04 12:33 ` Jan Engelhardt 2010-08-04 14:25 ` Alex Bligh 0 siblings, 1 reply; 12+ messages in thread From: Jan Engelhardt @ 2010-08-04 12:33 UTC (permalink / raw) To: Alex Bligh; +Cc: bridge, Netfilter mailing list 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-04 12:33 ` Jan Engelhardt @ 2010-08-04 14:25 ` Alex Bligh 2010-08-04 14:32 ` Jan Engelhardt 0 siblings, 1 reply; 12+ messages in thread From: Alex Bligh @ 2010-08-04 14:25 UTC (permalink / raw) To: Jan Engelhardt; +Cc: bridge, Netfilter mailing list, 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-04 14:25 ` Alex Bligh @ 2010-08-04 14:32 ` Jan Engelhardt 2010-08-04 16:39 ` Nicolas de Pesloüan 0 siblings, 1 reply; 12+ messages in thread From: Jan Engelhardt @ 2010-08-04 14:32 UTC (permalink / raw) To: Alex Bligh; +Cc: bridge, Netfilter mailing list 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. :) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-04 14:32 ` Jan Engelhardt @ 2010-08-04 16:39 ` Nicolas de Pesloüan 2010-08-04 16:40 ` Jan Engelhardt 0 siblings, 1 reply; 12+ messages in thread From: Nicolas de Pesloüan @ 2010-08-04 16:39 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Netfilter mailing list, bridge, Alex Bligh 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bridge] ebtables PREROUTING -drop 2010-08-04 16:39 ` Nicolas de Pesloüan @ 2010-08-04 16:40 ` Jan Engelhardt 0 siblings, 0 replies; 12+ messages in thread From: Jan Engelhardt @ 2010-08-04 16:40 UTC (permalink / raw) To: Nicolas de Pesloüan; +Cc: Netfilter mailing list, bridge, Alex Bligh 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 ;-) ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-08-05 11:39 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-08-04 11:05 [Bridge] ebtables PREROUTING -drop ratheesh k 2010-08-04 11:43 ` Jan Engelhardt 2010-08-05 10:42 ` ratheesh k 2010-08-05 11:11 ` Jan Engelhardt 2010-08-05 11:39 ` ratheesh k 2010-08-04 11:49 ` Nicolas de Pesloüan 2010-08-04 12:31 ` Alex Bligh 2010-08-04 12:33 ` Jan Engelhardt 2010-08-04 14:25 ` Alex Bligh 2010-08-04 14:32 ` Jan Engelhardt 2010-08-04 16:39 ` Nicolas de Pesloüan 2010-08-04 16:40 ` Jan Engelhardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox