Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/Documentation/README.rtnetproxy
===================================================================
--- rtnet.orig/Documentation/README.rtnetproxy
+++ rtnet/Documentation/README.rtnetproxy
@@ -1,59 +1,79 @@
README.rtnetproxy
===================
08-Nov-2002, Mathias Koehrer <[EMAIL PROTECTED]>
+02-May-2008, Wolfgang Grandegger <[EMAIL PROTECTED]>
-rtnetproxy can be used to share a single network adapter for both - realtime
-and non-realtime ethernet traffic. TCP/IP can be used via rtnet (of course
-not in realtime!)
+RTnetproxy can be used to share a single network adapter for both - realtime
+and non-realtime ethernet traffic. TCP/IP, UDP and ARP can be used via RTnet
+(of course not in realtime!)
-rtnetproxy represents a network device to standard linux and can be used
-as any other linux network device (ifconfig for configuration), the name
+RTnetproxy represents a network device to standard Linux and can be used
+as any other Linux network device (ifconfig for configuration), the name
the network device is "rtproxy".
Setup:
--------
-Get your rtnet working first! All IP addresses you are interested in have
+Get your RTnet working first! All IP addresses you are interested in have
to be set via "rtifconfig ethX route solicit IP_ADDRESS"!
insmod rtnetproxy.o
-Now, you have a network device "rtproxy" ready to be used with linux.
+Now, you have a network device "rtproxy" ready to be used with Linux.
Configure this network device using "ifconfig":
+
Example:
+
ifconfig rtproxy up 192.168.10.10 netmask 255.255.255.0
That's it!
-Restrictions:
---------------
-rtnetproxy is restricted to IP-based protocols (TCP/IP!!!).
-Incoming frames from ICMP and UDP are interpreted directly by rtnet and are
-not forwarded to rtnetproxy => UDP works only with outgoing frames from linux
-context. Of course UDP works with rtnet!
+Configuration options:
+------------------------
+--enable-proxy: this enables RTnetproxy support, which is by default
+ restricted to IP-based protocols (TCP/IP!!!). Incoming frames from
+ ICMP and UDP are interpreted directly by RTnet and are not forwarded
+ to RTnetproxy => UDP works only with outgoing frames from Linux
+ context. Of course UDP works with RTnet!
+
+--enabled-proxy-udp: this option enables routing of non-realtime UDP
+ packets to the Linux network stack (via rtproxy device). It's the
+ users responsibility to make sure that port numbers used by RTnet
+ or the Linux network stack are assigned uniquely.
+
+--enable-proxy-arp: this option enables ARP support for the rtproxy Linux
+ network device. Incoming ARP replys are delivered to both, the RTnet
+ and the Linux network stack. The rtproxy then gets attached to the
+ corresponding RTnet device, rteth0 by default.
+
+--disable-icmp: this option disables the RTnet IPv4 ICMP support. ICMP
+ will then be handled by the Linux network stack via the rtproxy Linux
+ network device.
+Important note:
+-----------------
It is highly recommended to strictly separate realtime LAN traffic and non-
-realtime LAN traffic. For a configuration/setup phase, TCP/IP is sometimes
+realtime LAN traffic. For a configuration/setup phase, TCP/IP is sometimes
very useful, buf for realtime data exchange the LAN should be reserved for
the realtime traffic using UDP!
How it works internally:
--------------------------
-rtnetproxy works on top of rtnet.
-All data to be sent out or received is actually copied between rtnet and
-rtnetproxy => The performance is not as good as with the standard linux
+RTnetproxy works on top of RTnet.
+All data to be sent out or received is actually copied between RTnet and
+RTnetproxy => The performance is not as good as with the standard Linux
network drivers.
All incoming IPv4 frames, having a IP protocol ID that is not handled by
-rtnet are passed to rtnetproxy.
-Incoming frames, that are passed to rtnetproxy (TCP frames) slow down the
+RTnet are passed to RTnetproxy.
+Incoming frames, that are passed to RTnetproxy (TCP frames) slow down the
realtime stuff a little bit - as all this is done in realtime mode context!
Possible enhancements:
-----------------------
-Pass incoming frames to rtnetproxy not only by checking the protocol ID but
-by actual checking, if a certain frame has been processed by rtnet or not.
-This leads to a couple of changes in the rtnet implementation...
+Pass incoming frames to RTnetproxy not only by checking the protocol ID but
+by actual checking, if a certain frame has been processed by RTnet or not.
+This leads to a couple of changes in the RTnet implementation...
--
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
RTnet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rtnet-users
