Sending network traffic to "self" externally - is it possible?

[Bryan Phillippe]

Hello,

I would like to conduct some ethernet network testing using a NetBSD
client & server configuration. The unusual part about this is that I
want my configuration to be a single NetBSD system functioning as
both a client and a server, physically sending network traffic out on
interface and back into another, using a cross-cable.

I initially attempted to set this up on a Linux system, but any
configuration I could devise was still defeated by the routing code,
which knew that the destination was ultimately "local" and would
"receive" the traffic without ever physically sending it. AFAICT,
making it work the way I want would have required a convoluted
iptables configuration or a kernel patch. I'm hoping the NetBSD team
has already provided a knob for doing this on NetBSD!

TIA,
--
-bp

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Bryan Phillippe
Hello,
I would like to conduct some ethernet network testing using a NetBSD
client & server configuration. The unusual part about this is that I
want my configuration to be a single NetBSD system functioning as
both a client and a server, physically sending network traffic out on
interface and back into another, using a cross-cable.
I initially attempted to set this up on a Linux system, but any
configuration I could devise was still defeated by the routing code,
which knew that the destination was ultimately "local" and would
"receive" the traffic without ever physically sending it. AFAICT,
making it work the way I want would have required a convoluted
iptables configuration or a kernel patch. I'm hoping the NetBSD team
has already provided a knob for doing this on NetBSD!

I suspect NetBSD will do the same. You may be able to work around this
by manualy fixing (deleting) the route entries, or playing with
ipfiler.
But the easiest way to do this would be to use Xen ...

[D'Arcy J.M. Cain]

On Sun, 15 Apr 2007 01:24:49 -0700

Post by Bryan Phillippe
I would like to conduct some ethernet network testing using a NetBSD
client & server configuration. The unusual part about this is that I
want my configuration to be a single NetBSD system functioning as
both a client and a server, physically sending network traffic out on
interface and back into another, using a cross-cable.

I'm not sure exactly what you are trying to test here but if you get
too convoluted you may change the tested system too much. Is it
impossible to find one more machine on the network that can run NAT?

[Liam J. Foy]

Post by Bryan Phillippe
Hello,
I would like to conduct some ethernet network testing using a NetBSD
client & server configuration. The unusual part about this is that I
want my configuration to be a single NetBSD system functioning as both a
client and a server, physically sending network traffic out on interface
and back into another, using a cross-cable.
I initially attempted to set this up on a Linux system, but any
configuration I could devise was still defeated by the routing code,
which knew that the destination was ultimately "local" and would
"receive" the traffic without ever physically sending it. AFAICT,
making it work the way I want would have required a convoluted iptables
configuration or a kernel patch. I'm hoping the NetBSD team has already
provided a knob for doing this on NetBSD!
TIA,
--
-bp

What exactly are you trying to 'test'? No 'knob' exists as far as I know
because there is almost no point.

--
Liam J. Foy
<***@netbsd.org>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bryan Phillippe]

Post by D'Arcy J.M. Cain
On Sun, 15 Apr 2007 01:24:49 -0700

Post by Bryan Phillippe
I would like to conduct some ethernet network testing using a NetBSD
client & server configuration. The unusual part about this is that I
want my configuration to be a single NetBSD system functioning as
both a client and a server, physically sending network traffic out on
interface and back into another, using a cross-cable.

I'm not sure exactly what you are trying to test here but if you get
too convoluted you may change the tested system too much. Is it
impossible to find one more machine on the network that can run NAT?

I'm trying to test an ethernet switch. I have a single workstation that
already has multiple NICs in it, and I'd like to be able to use it
for this
purpose. In addition to saving space & power, it will also be easier if
I only have to manage a single system. Furthermore, I could run
simultaneous captures (e.g. tcpdump) on both interfaces, which
also simplifies timestamp comparison.

If I can't find a simple way (I'll try Manuel's suggestion of manually
munging routes first), I'll probably just use one of these:

http://www.ssi.bg/~ja/#loop
http://norvegh.com/ntools/index.php


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Blair Sadewitz]

For simplicity's sake, I'd go with Xen.

--Blair
--
Support WFMU-FM: free-form radio for the masses!
<http://www.wfmu.org/>

"The frivolity and boredom which unsettle the established order, the
vague foreboding of something unknown, these are the heralds of
approaching change. The gradual crumbling that left unaltered the
face of the whole is cut short by a sunburst which, in one flash,
illuminates the features of the new world." --G.W.F. Hegel,
_Phenomenology of Spirit_ 5:11

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bryan Phillippe]

[moved to netbsd-help]

Post by Bryan Phillippe
I'm trying to test an ethernet switch. I have a single workstation
that already has multiple NICs in it, and I'd like to be able to
use
it for this purpose. In addition to saving space & power, it will
also be easier if I only have to manage a single system.
Furthermore,
I could run simultaneous captures (e.g. tcpdump) on both
interfaces,
which also simplifies timestamp comparison.

You can likely do this by changing routes. When you ifconfig an
address, you'll get a cloning route for the subnet, which will lead to
arp and "arp entries" which are really host routes with LLINFO and
WASCLONED flags.
You can delete the cloning route, or you can just add a host route.
Beware that this will disrupt ARP functioning and if the switch is
paying attention that may be trouble. But if it's truly an Ethernet
switch, it won't look at IP or ARP.

Hi Greg,

I tried your suggestion of adding host routes, but wasn't able to get it
working. It also seems to reliably crash the kernel in the routing
layer
when I attempt to ping with that configuration (this is 3.1/i386 from
CD).

I tried first removing the cloning route, then adding two host
routes, with
different combinations of -cloning; using host vs. net/32 + gateway
of the
other interface IP. I wasn't able to add these routes using -ifa/-
ifp though;
I get "bad value" or "invalid argument".

Just FYI, here is some information on my setup:

% ifconfig tlp0 ; ifconfig tlp1
tlp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:e8:13:40:cd
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.0.1 netmask 0xfffffffc broadcast 192.168.0.3
inet6 fe80::200:e8ff:fe13:40cd%tlp0 prefixlen 64 scopeid 0x2
tlp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:e8:13:89:d3
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.0.2 netmask 0xfffffffc broadcast 192.168.0.3
inet6 fe80::200:e8ff:fe13:89d3%tlp1 prefixlen 64 scopeid 0x3
% netstat -rn -f inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu
Interface
127/8 127.0.0.1 UGRS 0 0 33192 lo0
127.0.0.1 127.0.0.1 UH 1 0 33192 lo0
192.168/30 link#2 UC 0 0 -
tlp0

% route delete -net 192.168.0.0/30
delete net 192.168.0.0
% route add -host 192.168.0.1 -iface -ifp tlp1
writing to routing socket: Invalid argument
add host 192.168.0.1: Invalid argument

... so that doesn't work. How about this:

% route add -host 192.168.0.1 192.168.0.2 -iface
add host 192.168.0.1: gateway 192.168.0.2
% route add -host 192.168.0.1 192.168.0.2 -iface
add host 192.168.0.1: gateway 192.168.0.2

(which doesn't report an error on the cli, but does print this in the
logs:
Apr 16 15:07:31 randy /netbsd: arp_rtrequest: bad gateway value)

% netstat -rn -f inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu
Interface
127/8 127.0.0.1 UGRS 0 0 33192 lo0
127.0.0.1 127.0.0.1 UH 1 0 33192 lo0
192.168.0.1 192.168.0.2 UHS 0 0 -
tlp1
192.168.0.2 192.168.0.1 UHS 0 0 -
tlp0

Looks like it should work, but no-go on the ping and I get this in
the logs:

Apr 16 15:10:18 randy /netbsd: arpresolve: can't allocate llinfo on
tlp1 for 192.168.0.1

If there are any other ideas, I'm willing to give them a shot.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bill Stouder-Studenmund]

Post by Bryan Phillippe
Hello,
I would like to conduct some ethernet network testing using a NetBSD
client & server configuration. The unusual part about this is that I
want my configuration to be a single NetBSD system functioning as
both a client and a server, physically sending network traffic out on
interface and back into another, using a cross-cable.

That won't really work. The problem is that NetBSD has one routing system.
You really need a system with two, one for one NIC and one for the other
NIC. The thing is that what is a local address for one routine system is a
remote address for the other, and our stack doesn't handle that.

I think something like Xen or Parallels or VMware would be the best way to
go. You'd then have two separate kernels & installations, each talking to
one of the NICs.

Take care,

Bill

[Herb Peyerl]

Post by Bill Stouder-Studenmund
That won't really work. The problem is that NetBSD has one routing system.
You really need a system with two, one for one NIC and one for the other
NIC. The thing is that what is a local address for one routine
system is a
remote address for the other, and our stack doesn't handle that.
I think something like Xen or Parallels or VMware would be the best way to
go. You'd then have two separate kernels & installations, each
talking to
one of the NICs.

Having said that, one thing I like about QNX (there are not many) is
that you can instantiate as many instances of the IP stack as you
want, bind them to devices, and API calls are directed to a specific
instance by environment variable.

so:

SOCK=external ssh somehost
SOCK=internal mount somehost:/home /home



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Bill Stouder-Studenmund

Post by Bryan Phillippe
Hello,
I would like to conduct some ethernet network testing using a NetBSD
client & server configuration. The unusual part about this is that I
want my configuration to be a single NetBSD system functioning as
both a client and a server, physically sending network traffic out on
interface and back into another, using a cross-cable.

That won't really work. The problem is that NetBSD has one routing system.
You really need a system with two, one for one NIC and one for the other
NIC. The thing is that what is a local address for one routine system is a
remote address for the other, and our stack doesn't handle that.
I think something like Xen or Parallels or VMware would be the best way to
go. You'd then have two separate kernels & installations, each talking to
one of the NICs.

I agree with Bill that virtualization is the way to go, however, you
*might* be able to add each of the host routes you require using a trick
such as this one, which I have used successfully to add a host route
with link-layer info:

# route add -host 192.168.1.1 -link tlp0:00.0a.0b.0c.0d.0e -iface

Dave