Tcl - Big knowledge gap wrt TCP/IP

Author

Big knowledge gap wrt TCP/IP

Helmut Giese

2004-08-30, 8:58 pm

Hello out there,
the terminology used in the following description may easily be a bit
off, given that this domain is foreign to me. Please try to guess what
I mean :)
I am faced with these requirements:
1) We will have several sub-nets where all nodes are interconnected
via Ethernet and communicate via TCP/IP.
2) In each sub-net we will have a Linux box acting as a router (?) -
that is, this machine will receive all packets / data which has to be
delivered to a different sub-net. (A local expert will set up all
machines on this network.)
2a) If it makes any difference, the "local expert" mentioned today,
that we could also configure this Linux box as a "bridge" ...
3) On this box all packets are converted via SLIP and sent out over
RS232 + power line modem to another machine which "knows" how to
deliver the packets to the target sub-net (in case you wonder, the
whole setup is a research project, trying to communicate over 10.000 V
power lines).

My problem is (2). I suppose I will work with sockets, but there my
knowledge ends:
- Which extension could I use to receive (on the Linux box) the data
which needs to be routed somewhere else?
- Given that I get the data, how do I find out to which sub-net /
target address it has to be sent to?
- Probably more questions once I get started ...

Should you need more information, I will gladly provide anything
needed. However, given my ignorance in this matter, it would
accelerate things, if - when asking for a specific piece of
information - you could also tell me how to obtain it.

Oh, and I don't know anything about Linux either :) - taking on this
project I just relied on Tcl, my C skills and the conviction, that
this whole matter cannot be terribly complicated, once the low level
stuff has been put into place.

Any insight, tips or links will be greatly appreciated.
Helmut Giese

Heinz-Detlev Koch

2004-08-30, 8:58 pm

Helmut Giese wrote:
> Hello out there,
> the terminology used in the following description may easily be a bit
> off, given that this domain is foreign to me. Please try to guess what
> I mean :)
> I am faced with these requirements:
> 1) We will have several sub-nets where all nodes are interconnected
> via Ethernet and communicate via TCP/IP.
> 2) In each sub-net we will have a Linux box acting as a router (?) -
> that is, this machine will receive all packets / data which has to be
> delivered to a different sub-net. (A local expert will set up all
> machines on this network.)
> 2a) If it makes any difference, the "local expert" mentioned today,
> that we could also configure this Linux box as a "bridge" ...
> 3) On this box all packets are converted via SLIP and sent out over
> RS232 + power line modem to another machine which "knows" how to
> deliver the packets to the target sub-net (in case you wonder, the
> whole setup is a research project, trying to communicate over 10.000 V
> power lines).
>
> My problem is (2). I suppose I will work with sockets, but there my
> knowledge ends:
> - Which extension could I use to receive (on the Linux box) the data
> which needs to be routed somewhere else?
> - Given that I get the data, how do I find out to which sub-net /
> target address it has to be sent to?
> - Probably more questions once I get started ...
>
> Should you need more information, I will gladly provide anything
> needed. However, given my ignorance in this matter, it would
> accelerate things, if - when asking for a specific piece of
> information - you could also tell me how to obtain it.
>
> Oh, and I don't know anything about Linux either :) - taking on this
> project I just relied on Tcl, my C skills and the conviction, that
> this whole matter cannot be terribly complicated, once the low level
> stuff has been put into place.
>
> Any insight, tips or links will be greatly appreciated.
> Helmut Giese

I'm not sure if I understood your problem correctly, but it seems to me
that there should be no need for additional programming on the network
level (neither in C nor in Tcl).

A properly configured linux system should handle the routing issues on
the kernel level with the help of some network daemons.

Normally, the complete setup would be controlled by a few configuration
commands like the following

# slattach /dev/cua1 &
# ifconfig sl0 this_host pointopoint other_host
# route add -host other_host sl0
# route add -net xxx.xxx.xxx.0 netmask 255.255.255.0 gw other_host

This attaches the serial interface /dev/cua1 to the SLIP discipline (and
creates the first slip interface sl0), configures the slip interface as
a point-to-point connection to the other host, adds a static route to
the other host, and establishes a route to the other network
xxx.xxx.xxx.0 through the other host.

I hope I remembered the commands correctly since SLIP is a bit outdated
and I haven't used it for years. If in doubt, consult the man pages for
the commands in question.

Alternatively, you may consider running a routing daemon like gated our
routed instead of modifying the routing tables by hand.

Hope this helps,

Heinz-Detlev

Helmut Giese

2004-08-30, 8:58 pm

On Mon, 30 Aug 2004 18:52:23 GMT, hgiese@ratiosoft.com (Helmut Giese)
wrote:

>2) In each sub-net we will have a Linux box acting as a router (?) -
>that is, this machine will receive all packets / data which has to be
>delivered to a different sub-net. (A local expert will set up all
>machines on this network.)
>2a) If it makes any difference, the "local expert" mentioned today,
>that we could also configure this Linux box as a "bridge" ...
>
>My problem is (2). I suppose I will work with sockets, but there my
>knowledge ends:
>- Which extension could I use to receive (on the Linux box) the data
>which needs to be routed somewhere else?
>- Given that I get the data, how do I find out to which sub-net /
>target address it has to be sent to?
>- Probably more questions once I get started ...
>
>Should you need more information, I will gladly provide anything
>needed. However, given my ignorance in this matter, it would
>accelerate things, if - when asking for a specific piece of
>information - you could also tell me how to obtain it.

Sorry, I have to add an important piece of information (Heinz-Detlev's
advice made me aware of the omission): On the Linux box I cannot just
forward (via SLIP) whatever I recieve (via TCP/IP) - the connection
has to be explicitely established by some "master" which effectively
controls the power-line communication (as I mentioned, the setup is a
bit, well, non-standard).
This is the situation:
- We have an electrical 3 phase net.
- At each phase we have a power-line modem connected to a Linux box.
From the POV of the power-line communication mechanism, these are
slaves.
- We have a master machine in the background, which will initiate any
communication. This is a Windows machine where we have to talk via
Microsoft's COM interface to a software the vendor of the power line
modems provided (BTW, this now works like a charm with the tcom
extension.)
- Now, although slave1 needs to talk to slave2, there is no way to
achieve this directly. Rather, the master will poll each slave in turn
and ask it, whether it has some data to transmit.
If so,
- it is then allowed to send it,
- the master closes the connection to slave1,
- opens the connection to slave2 (the actual destination) and
- eventually transmits the data to slave2.
Turning around as fast as possible, it is supposed to look to the
outside, as if slave1 could talk directly to slave2 - albeit not very
fast.

So, more precisely the requirements are:
- accept (and buffer) all TCP/IP packets which arrive,
- wait, until a serial connection is established by receiving a
"question" from the master (see above),
- and then SLIP everything I collected so far.

Also note, that the power-line communication is really sloooow, so
that we need to minimize any communication overhead.
Best regards
Helmut Giese

David Gravereaux

2004-08-30, 8:58 pm

hgiese@ratiosoft.com (Helmut Giese) wrote:

>3) On this box all packets are converted via SLIP and sent out over
>RS232 + power line modem to another machine which "knows" how to
>deliver the packets to the target sub-net (in case you wonder, the
>whole setup is a research project, trying to communicate over 10.000 V
>power lines).

Oh, a power line modem. There was a company called Gridcomm from Danbury,
CT that did this around 1986. Multiplexed RF channels, with repeaters, I
think. The company tanked, but the technology worked (except for the LSI
12-bit system).
--
David Gravereaux <davygrvy@pobox.com>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]

Helmut Giese

2004-08-30, 8:58 pm

On Mon, 30 Aug 2004 22:01:57 +0200, Heinz-Detlev Koch <koch@epc.de>
wrote:
[snip problem description]
Hello Heinz-Detlev,
thanks for these ideas. (I don't fully understand them, but our 'local
expert' surely would.)
However, I just realized that I omitted an important detail: On the
Linux box I cannot just send out data at any moment I want - the
connection has to be explicitely established. Please see my follow-up
to my OP for details.
AFAICT, this is a setup where I cannot just rely on the kernel "to do
the right thing", so I'll probably have to do some programming on an
intermediate level myself.

Best regards
Helmut Giese

>I'm not sure if I understood your problem correctly, but it seems to me
>that there should be no need for additional programming on the network
>level (neither in C nor in Tcl).
>
>A properly configured linux system should handle the routing issues on
>the kernel level with the help of some network daemons.
>
>Normally, the complete setup would be controlled by a few configuration
>commands like the following
>
># slattach /dev/cua1 &
># ifconfig sl0 this_host pointopoint other_host
># route add -host other_host sl0
># route add -net xxx.xxx.xxx.0 netmask 255.255.255.0 gw other_host
>
>This attaches the serial interface /dev/cua1 to the SLIP discipline (and
>creates the first slip interface sl0), configures the slip interface as
>a point-to-point connection to the other host, adds a static route to
>the other host, and establishes a route to the other network
>xxx.xxx.xxx.0 through the other host.
>
>I hope I remembered the commands correctly since SLIP is a bit outdated
>and I haven't used it for years. If in doubt, consult the man pages for
>the commands in question.
>
>Alternatively, you may consider running a routing daemon like gated our
>routed instead of modifying the routing tables by hand.
>
>Hope this helps,
>
>Heinz-Detlev
>
>
>
>
>

Heinz-Detlev Koch

2004-08-31, 8:58 am

Helmut Giese wrote:

>
> Sorry, I have to add an important piece of information (Heinz-Detlev's
> advice made me aware of the omission): On the Linux box I cannot just
> forward (via SLIP) whatever I recieve (via TCP/IP) - the connection
> has to be explicitely established by some "master" which effectively
> controls the power-line communication (as I mentioned, the setup is a
> bit, well, non-standard).
> This is the situation:
> - We have an electrical 3 phase net.
> - At each phase we have a power-line modem connected to a Linux box.
> From the POV of the power-line communication mechanism, these are
> slaves.
> - We have a master machine in the background, which will initiate any
> communication. This is a Windows machine where we have to talk via
> Microsoft's COM interface to a software the vendor of the power line
> modems provided (BTW, this now works like a charm with the tcom
> extension.)
> - Now, although slave1 needs to talk to slave2, there is no way to
> achieve this directly. Rather, the master will poll each slave in turn
> and ask it, whether it has some data to transmit.
> If so,
> - it is then allowed to send it,
> - the master closes the connection to slave1,
> - opens the connection to slave2 (the actual destination) and
> - eventually transmits the data to slave2.
> Turning around as fast as possible, it is supposed to look to the
> outside, as if slave1 could talk directly to slave2 - albeit not very
> fast.
>
> So, more precisely the requirements are:
> - accept (and buffer) all TCP/IP packets which arrive,
> - wait, until a serial connection is established by receiving a
> "question" from the master (see above),
> - and then SLIP everything I collected so far.
>

Oh, that's quite a different setup than what I had imagined. AFAIK,
there is no standard solution to implement a store-and-forward mechanism
like the one that you have described.

So, there is one more question that seems to be important: Do you want
to implement a transparent IP gateway mechanism in this way (so that
virtually any network communication between slave1 and slave2 is
possible) or is the communication between slave1 and slave2 restricted
to some special applications and a proprietary network protocol?

The second case seems to be much easier to deal with and would require
the routers to work as a kind of proxy for your special network protocol.

A transparent IP gateway solution based on a store-and-forward mechanism
looks a bit like "TCP/IP over UUCP" which sounds rather strange to me.
I'm not saying that it can't be done, but I'm afraid that this could be
tricky. My first guess woule be to fool the Linux kernel into thinking
that is has a permanent SLIP connection to your master machine by
establishing a SLIP connection to a pseudo terminal. You would then
write a piece of software that sits around on the master side of the
pseudo terminal and collects, stores, and forwards any incoming data.
This approach is taken by diald (http://diald.sourceforge.net, IIRC), so
that could be a place to go for further information.

Best regards,

Heinz-Detlev

Helmut Giese

2004-08-31, 8:58 am

On Tue, 31 Aug 2004 11:08:15 +0200, Heinz-Detlev Koch <koch@epc.de>
wrote:
>
>Oh, that's quite a different setup than what I had imagined. AFAIK,
>there is no standard solution to implement a store-and-forward mechanism
>like the one that you have described.
>
>So, there is one more question that seems to be important: Do you want
>to implement a transparent IP gateway mechanism in this way (so that
>virtually any network communication between slave1 and slave2 is
>possible) or is the communication between slave1 and slave2 restricted
>to some special applications and a proprietary network protocol?
I think we'll start out supporting http requests only and then see
where we'll go from there.

>The second case seems to be much easier to deal with and would require
>the routers to work as a kind of proxy for your special network protocol.
>
>A transparent IP gateway solution based on a store-and-forward mechanism
>looks a bit like "TCP/IP over UUCP" which sounds rather strange to me.
>I'm not saying that it can't be done, but I'm afraid that this could be
>tricky. My first guess woule be to fool the Linux kernel into thinking
>that is has a permanent SLIP connection to your master machine by
>establishing a SLIP connection to a pseudo terminal. You would then
>write a piece of software that sits around on the master side of the
>pseudo terminal and collects, stores, and forwards any incoming data.
>This approach is taken by diald (http://diald.sourceforge.net, IIRC), so
>that could be a place to go for further information.
I'll go and have a look. Thanks for your advice and best regards
Helmut Giese

Helmut Giese

2004-08-31, 8:58 am

On Mon, 30 Aug 2004 14:11:03 -0700, David Gravereaux
<davygrvy@pobox.com> wrote:

>hgiese@ratiosoft.com (Helmut Giese) wrote:
>
>
>Oh, a power line modem. There was a company called Gridcomm from Danbury,
>CT that did this around 1986. Multiplexed RF channels, with repeaters, I
>think. The company tanked, but the technology worked (except for the LSI
>12-bit system).
Hi David,
I'm a softie, I don't know nothin' about the hardware. It's a bit
special in that it is capacitively coupled onto what these guys call
'mid-voltage' lines - some mere 10.000 Volts.
Have a nice time
Helmut Giese

Sponsored Links