ipt_ROUTE and destination MAC address

ipt_ROUTE and destination MAC address

[junk]

Hello,

i'm coding a virtual interface. That virtual interface has to receive packets
coming on eth0. For that purpose, i'm using ipt_ROUTE. That works great, i can
see my packets arriving on red0 (my virtual interface).

But there is a problem..

If i send an icmp request to 10.0.1.1 from another computer:

The icmp request arrives on the physical interface, ROUTE target makes it
arrive on red0

icmp request arriving on red0: 10.0.0.1

The problem is that the destination MAC is the one of eth0, so, it seems the
kernel doesn't really deliver the packet to my driver. I can see it in tcpdump
but my driver receive function is never called.

I tried every -j ROUTE option, --gw or --iif, with --continue, or not..

Any idea?

Re: ipt_ROUTE and destination MAC address

[junk]

On Fri, 11 Feb 2005 01:07:55 +0100 (CET), Henrik Nordstrom wrote
> On Thu, 10 Feb 2005, junk wrote:
> 
> > i'm coding a virtual interface. That virtual interface has to receive packets
> > coming on eth0. For that purpose, i'm using ipt_ROUTE. That works great, i can
> > see my packets arriving on red0 (my virtual interface).
> >
> > The problem is that the destination MAC is the one of eth0, so, it seems the
> > kernel doesn't really deliver the packet to my driver. I can see it in tcpdump
> > but my driver receive function is never called.
> 
> It is not due to the destination MAC, but to what ipt_ROUTE does.
> 
> ipt_ROUTE reoutes the packet as if it came in on the other interface,
>  all done at the IP layer in the kernel, it does not resubmit the 
> packet to the driver level.
> 
> The MAC is not modified as this is not relevant to the IP layer, and 
> there really isn't any reason why it should be modified either. The 
> MAC used in received skbufs is the MAC the sending station was 
> addressing the packet to, not the MAC of the receiving interface. 
> Usually they are the same, but not always.
> 
> Can you give an more detailed example of what it is you are trying 
> to accomplish or why you need a custom virtual interface driver? It 
> is possible (or even likely) there is other better tools for the job.
> 
> Also I am a little confused on your virtual interface driver. 
> Normally virtual interface drivers does not have a receive function, 
> only a transmit function called when packets are routed to be 
> transmitted on the interface.. How you make packets arrive at the 
> interface driver is up to you (emulated hardware or whatever).
> 
> Regards 
> Henrik
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" 
> in the body of a message to majordomo@vger.kernel.org More majordomo 
> info at  http://vger.kernel.org/majordomo-info.html


The purpose is to run a redundant network.

My virtual interface has to duplicate packets it receive from software, and
send each copy of it on eth0 and eth1 respectively.

>From the application, there is only one interface: red0.

red0 has to:
- duplicate packets having red0 as outgoing interface (real output iface are
eth0/eth1)
- receive packets from eth0/eth1, discarding the copy (as eth0 and eth1
receive the same data), pass the packet to application
- alert userland if eth0 or eth1 comes down

The problem is that I want my driver to know about incoming packets, not only
the software.

Re: ipt_ROUTE and destination MAC address

[jamal]

Maybe if you describe your purpose it would help more. I dont know what
ROUTE or red0 is, but you could essentially use mirred action to mirror
or redirect packets to any interface you want; examples (part of
iproute/doc):

Host A is hooked  up to us on eth0 for these examples

1)
tc qdisc add dev lo ingress
# redirect all packets arriving on ingress of lo to eth0
tc filter add dev lo parent ffff: protocol ip prio 10 u32 \
match u32 0 0 flowid 1:2 action mirred egress redirect dev eth0

2)
#allow every 10th packet to be sent to be copied to eth0
# you could sample better by using netrand insted of determ
#
tc filter add dev lo parent ffff: protocol ip prio 10 u32 \
match u32 0 0 flowid 1:2 \
action drop random determ ok 10\
action mirred egress mirror dev eth0

3)
# for packets coming from 10.0.0.9:
#Redirect packets on egress (to ISP A) if you exceed a certain rate
# to eth1 (to ISP B) if you exceed a certain rate
#

tc qdisc add dev eth0 handle 1:0 root prio

tc filter add dev eth0 parent 1:0 protocol ip prio 6 u32 \
match ip src 10.0.0.9/32 flowid 1:16 \
action police rate 100kbit burst 90k ok \
action mirred egress mirror dev eth1

4)
# repeat above but send packets to dummy0 as well so you can see them
# with tcpdump:

tc filter add dev eth0 parent 1:0 protocol ip prio 6 u32 \
match ip src 10.0.0.9/32 flowid 1:16 \
action police rate 100kbit burst 90k ok \
action mirred egress mirror dev eth1 \
action mirred egress mirror dev dummy0

Again, dont know what you are trying to do, so i gave you a shotgun
answer and i could almost swear you are probably trying to hardcode one
of these scenarios by writting a driver ;->

cheers,
jamal

On Fri, 2005-02-11 at 07:39, junk wrote:
> Hello,
> 
> i'm coding a virtual interface. That virtual interface has to receive packets
> coming on eth0. For that purpose, i'm using ipt_ROUTE. That works great, i can
> see my packets arriving on red0 (my virtual interface).
> 
> But there is a problem..
> 
> If i send an icmp request to 10.0.1.1 from another computer:
> 
> The icmp request arrives on the physical interface, ROUTE target makes it
> arrive on red0
> 
> icmp request arriving on red0: 10.0.0.1
> 
> The problem is that the destination MAC is the one of eth0, so, it seems the
> kernel doesn't really deliver the packet to my driver. I can see it in tcpdump
> but my driver receive function is never called.
> 
> I tried every -j ROUTE option, --gw or --iif, with --continue, or not..
> 
> Any idea?
> 
>