All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] How to bypass the local routing table, to simulate a hub
@ 2003-12-12  2:15 Antony Lesuisse
  2003-12-12 15:09 ` [LARTC] How to bypass the local routing table, to simulate a Darryl Miles
  0 siblings, 1 reply; 2+ messages in thread
From: Antony Lesuisse @ 2003-12-12  2:15 UTC (permalink / raw)
  To: lartc

Imagine, on a linux box, having 3 different network interfaces on the
same switch.  It is for simulating a network, using virtual tun/tap
interface:


----------------+-----+------------------------
Hub    simulator|Linux| Userspaces apps
                |     |
             ?--|-----|--- tap0 192.168.1.1
             ?  |     |
/dev/net/tun ?--|-----|--- tap1 192.168.1.2
             ?  |     |
             ?--|-----|--- tap2 192.168.1.3
                |     |
----------------+-----+-----------------------

How can you tell the linux networking stack that a packet for 192.168.1.2 has
to be sent via the network interface tap0 or tap2 (according to the sin_addr)
to the WIRE and be received by tap1?

I would like that, for packets that comes from process, the kernel
doesn't recognize the dest ip as local so that the packet will be sent
over the interface even if there is an other interface configurated with
the destination ip on the same kernel.

For example i will configure a HTTP server on tap2 binding 192.168.1.3:80
and i will launch an HTTP client binding IP 192.168.1.1 trying to make
TCP connection to 192.168.1.3:80 doing a GET. Everything on the same
computer. My hub simulator will sometimes simulate packet loss.

    ping -I tap0 192.168.1.2 should go trought my simulator and not use lo.

    ping 192.168.1.2 should go trought my simulator (ie using 192.168.1.1) as source

Acoording to my understanting of the linux network stack the problem is that
there is no way to skip the lookup in the local routing table:

You cannot change the 0: of ip rules

ip rule:
	0:	from all lookup local 
	32766:	from all lookup main 
	32767:	from all lookup default 

ip route show table local:
	local 192.168.1.1 dev eth0  proto kernel  scope host  src 192.168.1.1 
	local 192.168.1.2 dev eth0  proto kernel  scope host  src 192.168.1.2 
	local 192.168.1.3 dev eth0  proto kernel  scope host  src 192.168.1.3 
	...

Somebody on irc told me to do something like this:

	iptables -A PREROUTING -t mangle -p tcp -s MYIP1 -j MARK --set-mark 10
	iptables -A PREROUTING -t mangle -p tcp -s MYIP2 -j MARK --set-mark 20
	ip rule add fwmark 10 table first
	ip rule add from MYIP1 to 0.0.0.0/0 lookup second
	ip route add default via eth2 table second

But it doesn't change the fact that linux still lookup the local routing
table.

TIA
Antony Lesuisse

BONUS: Here is my small (but fully functionnal) network hub simulator in python:

#!/usr/bin/python2.2
# hub with a probabilty of 0.9
import fcntl,math,os,random,select,sys,time

# TUN TAP kernel interface
def net_alloc(name=""):
	s = len(name)
	if s>15:
		raise "name too long"
	fd = os.open("/dev/net/tun",os.O_RDWR)
	print fd
	if fd = -1:
		raise "could not open /dev/net/tun"
	ioctl_int = 0x400454ca
	ioctl_ifreq = name+(16-s)*'\x00'+'\x02'+15*'\x00'
	name = fcntl.ioctl(fd,ioctl_int,ioctl_ifreq)
	name = name[:name.find('\x00')]
	return (fd,name)

# Contruction of a hub
hub = []
hubname = {}
for i in range(2):
	fd,name = net_alloc()
	hub.append(fd)
	hubname[fd]={'fd':fd, 'name':name}
os.system("ifconfig -a")
os.system("ifconfig tap0 192.168.66.1; ifconfig tap1 192.168.66.2")

# hub simulation
while 1:
	(fdin,a,b) = select.select(hub,[],[],1.0)
	print "event:",fdin
	for i in fdin:
		frame = os.read(i,2048)
		print "%s:frame:%s"%(hubname[i]['name'],repr(frame))
		for j in hub:
			if j != i:
				if random.random() < 0.9:
					os.write(j,frame)
				else:
					print "lost:%s:to:%s"%(hubname[i]['name'],hubname[j]['name'])


-- 
Antony Lesuisse
GPG EA2CCD66: 4B7F 6061 3DF5 F07A ACFF  F127 6487 54F7 EA2C CD66
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [LARTC] How to bypass the local routing table, to simulate a
  2003-12-12  2:15 [LARTC] How to bypass the local routing table, to simulate a hub Antony Lesuisse
@ 2003-12-12 15:09 ` Darryl Miles
  0 siblings, 0 replies; 2+ messages in thread
From: Darryl Miles @ 2003-12-12 15:09 UTC (permalink / raw)
  To: lartc


Antony,

I have not completely read / understood your situation, so forgive me 
for jumping in.

I don't know much about tap0 device so maybe you can eligthen me.  But 
from what I can see you can setup a NETWORK on a tapX interface and the 
kernel will route all traffic to the interface as-if its a hardware 
device, except its not, its a software device that passes packets 
between userspace and the kernel interface through the use of a file 
descriptor / socket, created by opening a device like file.

I use the word NETWORK since it behaves like a normal interface, that is 
you give it an IP address that represents the kernels interface facing 
the userspace software/virtual network.  Therefore you should have setup 
the interface with a netmask to allow other IPs to exist on that 
network, it is those IPs that your application program should assume and 
use.

To do this means the tap0 interface is configured along the lines of 
192.168.1.8/30, using a netmask of 255.255.255.252, using 192.168.1.9 as 
the kernel interface IP, 192.168.1.10 as your applications IP.   Then 
run your "ping -I tap0" again.


Now if on the other hand you are wanting to sniff all traffic to a 
particular IP address from your ethernet segment, but not have the 
kernel stack treat the packets as local, then down all the tapX 
interfaces, then checkout AF_RAW, NETLINK, whatever the current scheme 
is for injecting / sniffing packets and setup a proxy ARP addresses of 
the IPs you want to assume on the LAN.  However if the box this is all 
hosted on has a lot of other traffic destined for the kernel stack you 
will have to receive, filter, discard all those packets through into 
userspace.  Maybe socket filters can help in the kernel, but the point 
is the tapX interfaces when used as a NETWORK would be a better solution.

Darryl



Antony Lesuisse wrote:

>Imagine, on a linux box, having 3 different network interfaces on the
>same switch.  It is for simulating a network, using virtual tun/tap
>interface:
>
>
>----------------+-----+------------------------
>Hub    simulator|Linux| Userspaces apps
>                |     |
>             ?--|-----|--- tap0 192.168.1.1
>             ?  |     |
>/dev/net/tun ?--|-----|--- tap1 192.168.1.2
>             ?  |     |
>             ?--|-----|--- tap2 192.168.1.3
>                |     |
>----------------+-----+-----------------------
>


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-12-12 15:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-12  2:15 [LARTC] How to bypass the local routing table, to simulate a hub Antony Lesuisse
2003-12-12 15:09 ` [LARTC] How to bypass the local routing table, to simulate a Darryl Miles

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.