> > Nowadays there is an increased number of network cards which only
> > receive data - DVB-MPEG sattelite encapsulation of IP packets (which I
> > use), DirecPC, etc. ...
>
> Physical limitation of the card, or conceptually?
Physical limitation. The setup is: you dial to isp (or connect
through any other means), and then packets out go by modem or lan, and
packets down by satellite dish to your pc-card (which emulate a ethernet
card) and back to your linux. Obviously, the modem or the real ethernet
card are normal, two way devices, but the satellite receiver is only
download (you don't have the setup or transmitting power to reach the
satellite with a $300-$500 pc-card and a regular dish).
> > ... Isn't there anything that should be adjusted in the linux
> > kernel so that it knows that some cards are receive (or maybe send)
> > only? So that /proc/sys/net/ipv4/conf/*/rp_filter doesn't warn you
> > if it receives packets from that iface when the default route is
> > through a normal interface? Or maybe some other things, I don't
> > know, but I feel like they (the receive only ifaces) should be
> > treated a little differently.
>
> Remember that the default route is used for networks that we don't
> know a route for, not just blindly as an output interface.
>
> For example, if you have two networks A & B and your default route
> is out A, you will still have a route for the B subnet and all your
> traffic for anything on B will go through the B interface.
>
Of course, that I know, I was saying that if you enable rp_filter
(to 2), and you receive a packet by dish, from a.b.c.d, the kernel checks
how it would send it. Of course, this would be by ppp0 (or eth0), but it
came by eth1 (your fake ethernet adapter), so it is a warning (i didn't
really tried it, but this is how I know the rp_filter works). The kernel
thinks this is a case of IP spoofing, because it (the kernel) doesn't know
that you couldn't never ever send the packet by where it was received. You
can't add a route to the emmiter of the satellite packets through the eth1
(fake card) address, because it would not get sent ever (the packt).This
is asymetric routing, not by decision, by because of technical conditions.
So my question was if the current struct device from
/usr/src/linux/include/linux/netdevice.h doesn't need a new field (maybe
this is somethink bad to think - changing standard structures, I don't
know) describing the capabilities of a device.
Iustin Pop
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/