Sign in with
Sign up | Sign in
Your question

Possible to run 10Mbps IP/UDP over a terminal server?

Last response: in Networking
Share
Anonymous
a b C Monitor
May 22, 2004 2:54:15 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hello good folks -

I'm wondering if an idea I've thought of to solve a problem I have might
be something actually workable. Here's my problem:

I have a number (10, say) of small ethernet devices (medical monitors)
which speak UDP over IP. The problem is that they can be configured
with an IP address only - no subnet mask or default gateway. I need to
be able to talk to these devices (all sitting in a single room) from an
interface server that is some distance away (i.e. in a basement data
center, with the monitors 15 floors up or more, too far/expensive to
wire directly). There is network access between the data center and the
rooms where the monitors are, but it is composed of a number of
segments, which of course these little monitors won't play with. (Each
floor where the monitors are is on a different subnet.) So - I'm
wondering if it's possible to connect these monitors up to a local
terminal server (in a wiring closet near the room where the monitors
live) using cat5 cabling. I've done this lots with serial devices but
never thought of doing it with ethernet until now.

My need is to be able to access these monitors from a (unix) server in
the data center over the existing (subnetted) network infrastructure. I
need to get to a specific port on these devices (port 2000), so I need
to be able to get to monitor1 port 2000, monitor2 port 2000, etc.
Anyone know if something like this is possible? I'm really not much of
a network guru - a rank newbie describes me well. I know a little but
my expertise runs out quickly :-)

I'm pinging a couple termserver makers to see what they might say, but
thought I'd check here too. The folks here don't have the kind of axe
to grind that a termserver manufacturer might (*sure* we can do it, just
buy our products for lots of $$!).

Perhaps a switch would serve the purpose here? Would a switch (or
router) have its own IP address that would be reachable across subnets
and allow me access to these monitors? I'd still need a way to talk to
individual ports where the monitors are plugged into, and I'd need to
access the specific port (2000) on each monitor.

I should mention that high performance is not a huge need here. The
monitors are 10mbit speed, and the traffic would be fairly low and only
once a minute or so.

Lots and lots of thanks in advance for any tips or help -
--
Fuzzy

"It is unwise to insult a doughnut by refusing to eat it."

== I am fuzzy underscore 2 at charter dot net ==
Anonymous
a b C Monitor
May 22, 2004 9:22:45 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <10atnqs4d83c49e@corp.supernews.com>, fuzzy@fuzzy.net says...
> I have a number (10, say) of small ethernet devices (medical monitors)
> which speak UDP over IP. The problem is that they can be configured
> with an IP address only - no subnet mask or default gateway. I need to
> be able to talk to these devices (all sitting in a single room) from an
> interface server that is some distance away (i.e. in a basement data
> center, with the monitors 15 floors up or more, too far/expensive to
> wire directly). There is network access between the data center and the
> rooms where the monitors are, but it is composed of a number of
> segments, which of course these little monitors won't play with. (Each
> floor where the monitors are is on a different subnet.) So - I'm
> wondering if it's possible to connect these monitors up to a local
> terminal server (in a wiring closet near the room where the monitors
> live) using cat5 cabling. I've done this lots with serial devices but
> never thought of doing it with ethernet until now.

You don't even need the terminal server.

> My need is to be able to access these monitors from a (unix) server in
> the data center over the existing (subnetted) network infrastructure. I
> need to get to a specific port on these devices (port 2000), so I need
> to be able to get to monitor1 port 2000, monitor2 port 2000, etc.
> Anyone know if something like this is possible? I'm really not much of
> a network guru - a rank newbie describes me well. I know a little but
> my expertise runs out quickly :-)

What you need is proxy arp. The devices, lacking a default gateway,
will arp for everyone in the world. Your router must answer these arps
on behalf of the real servers (in the basement). Cisco routers for
example enable proxy arp by default. If your router knows how to get to
the basement servers, it will automagically work.

--

hsb

"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
********************************************************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************
Anonymous
a b C Monitor
May 22, 2004 12:45:33 PM

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

Fuzzball wrote:

> I have a number (10, say) of small ethernet devices (medical monitors)
> which speak UDP over IP. The problem is that they can be configured
> with an IP address only - no subnet mask or default gateway. I need to
> be able to talk to these devices (all sitting in a single room) from an
> interface server that is some distance away (i.e. in a basement data
> center, with the monitors 15 floors up or more, too far/expensive to
> wire directly). There is network access between the data center and the
> rooms where the monitors are, but it is composed of a number of
> segments, which of course these little monitors won't play with.

(snip)

Terminal servers will be TCP, not UDP, so I don't think
that will help.

Small NAT routers, commonly used for home networks, though
should be able to do it.

The way it is supposed to work is that the router connects
between the local (LAN) network (where your devices are),
and the rest of the world (WAN). If all on one floor were
in one room, then a separate network (subnet) would be the
obvious way to do it.

They are very affordable now, as models supporting wireless
networks come out pushing down the price of ones that don't
to around $40.

If you can't arrange a separate physical network for them,
you should be able to run the LAN side, with private IP
addresses, on the same physical network as your existing
network. In other words, one such router could support
an entire floor, even though it is connected through
the regular floor network.

Are you sure, though, that they don't support either subnet
mask or default router? It would be unusual for an IP
implementation in the last 15 years not to support subnets.
(I knew of some older that didn't.)

Oh, this is really an IP question so should go to
comp.protocols.tcp-ip (added)

-- glen
Related resources
Anonymous
a b C Monitor
May 22, 2004 5:22:19 PM

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

glen herrmannsfeldt wrote:
> Fuzzball wrote:
>
>> I have a number (10, say) of small ethernet devices (medical monitors)
>> which speak UDP over IP. The problem is that they can be configured
>> with an IP address only - no subnet mask or default gateway. I need
>> to be able to talk to these devices (all sitting in a single room)
>> from an interface server that is some distance away (i.e. in a
>> basement data center, with the monitors 15 floors up or more, too
>> far/expensive to wire directly). There is network access between the
>> data center and the rooms where the monitors are, but it is composed
>> of a number of segments, which of course these little monitors won't
>> play with.
>
>
> (snip)
>
> Terminal servers will be TCP, not UDP, so I don't think
> that will help.
>
> Small NAT routers, commonly used for home networks, though
> should be able to do it.
>
> The way it is supposed to work is that the router connects
> between the local (LAN) network (where your devices are),
> and the rest of the world (WAN). If all on one floor were
> in one room, then a separate network (subnet) would be the
> obvious way to do it.
>
> They are very affordable now, as models supporting wireless
> networks come out pushing down the price of ones that don't
> to around $40.
>
> If you can't arrange a separate physical network for them,
> you should be able to run the LAN side, with private IP
> addresses, on the same physical network as your existing
> network. In other words, one such router could support
> an entire floor, even though it is connected through
> the regular floor network.
>
> Are you sure, though, that they don't support either subnet
> mask or default router? It would be unusual for an IP
> implementation in the last 15 years not to support subnets.
> (I knew of some older that didn't.)
>
> Oh, this is really an IP question so should go to
> comp.protocols.tcp-ip (added)
>
> -- glen
>

Another possibility would be to use subnetting and to enable
proxy-arp on the router near the monitors.

F'rinstance:
The monitors are 10.1.1.1, 10.1.1.2...
The local router is 10.1.1.254, but knows the network is 10.1.1.0/24.
The manager (I assume no problem with that) is 10.2.1.1 in another
part of the building.

When the monitors need to send to the manager, they don't know about
the subnetting and simply try to ARP 10.2.1.1 as though it were on
the same LAN. If a router is configured with proxy-arp enabled, then
it will respond tothe ARP request with its own MAC address. The
stupid monitor then keeps on sending packets to the router (which
forwards them) without ever knowing the manager box isn't actually
on the same LAN.

Steve
Anonymous
a b C Monitor
May 23, 2004 7:19:02 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

On Sat, 22 May 2004 08:45:33 GMT, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>(snip)
>
>Terminal servers will be TCP, not UDP, so I don't think
>that will help.
>
Not always - see link below -

http://www.lantronix.com/support/docs/pdf/UDS100_PB_910...

Watch for any wordwrap -
Anonymous
a b C Monitor
May 24, 2004 2:01:58 AM

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

glen herrmannsfeldt wrote:

(snip)
>
> Are you sure, though, that they don't support either subnet
> mask or default router? It would be unusual for an IP
> implementation in the last 15 years not to support subnets.
> (I knew of some older that didn't.)
>
> Oh, this is really an IP question so should go to
> comp.protocols.tcp-ip (added)
>
> -- glen
>

These really don't have subnetting or default gateway ability :-) The
implementation of the comm s/w in the monitors' firmware is probably a
good 10-15 years old and hasn't changed a whole lot since then. These
devices are most often used on their own dedicated lan where subnetting
is not used.

Fuzz

"It is unwise to insult a doughnut by refusing to eat it."

== I am fuzzy underscore 2 at charter dot net ==
Anonymous
a b C Monitor
May 24, 2004 3:08:31 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hansang Bae wrote:

> In article <10atnqs4d83c49e@corp.supernews.com>, fuzzy@fuzzy.net says...
>
>>I have a number (10, say) of small ethernet devices (medical monitors)
>>which speak UDP over IP. The problem is that they can be configured
>>with an IP address only - no subnet mask or default gateway. I need to
>>be able to talk to these devices (all sitting in a single room) from an
>>interface server that is some distance away (i.e. in a basement data
>>center, with the monitors 15 floors up or more, too far/expensive to
>>wire directly). There is network access between the data center and the
>>rooms where the monitors are, but it is composed of a number of
>>segments, which of course these little monitors won't play with. (Each
>>floor where the monitors are is on a different subnet.) So - I'm
>>wondering if it's possible to connect these monitors up to a local
>>terminal server (in a wiring closet near the room where the monitors
>>live) using cat5 cabling. I've done this lots with serial devices but
>>never thought of doing it with ethernet until now.
>
>
> You don't even need the terminal server.
>
>
>>My need is to be able to access these monitors from a (unix) server in
>>the data center over the existing (subnetted) network infrastructure. I
>>need to get to a specific port on these devices (port 2000), so I need
>>to be able to get to monitor1 port 2000, monitor2 port 2000, etc.
>>Anyone know if something like this is possible? I'm really not much of
>>a network guru - a rank newbie describes me well. I know a little but
>>my expertise runs out quickly :-)
>
>
> What you need is proxy arp. The devices, lacking a default gateway,
> will arp for everyone in the world. Your router must answer these arps
> on behalf of the real servers (in the basement). Cisco routers for
> example enable proxy arp by default. If your router knows how to get to
> the basement servers, it will automagically work.
>
Firstly, thanks muchly for the response. I've been since looking up
proxy arp on google and trying to figure out how it works. Can you help
me (not being as familiar with this as I'd like) to understand what
you're telling me a bit more? I should help out by explaining a typical
sequence of events (what I want to have happen):
1. interface s/w running on the main server needs to send request to one
of the monitors upstairs, asking it for data.
2. The correct monitor (addressed by IP addr) should get the request and
respond to it.
3. The response is received by the interface s/w on the server and
parsed out and stored.

There will likely be multiple routers in between the server and the room
where the monitors live.

When you say that the devices will "arp for everyone in the world", what
do you mean, exactly? "Lacking a default gateway" seems to be the
reason for this arping - why is this? I hate to ask what are probably
basic questions, but I'd like to fully understand what's going on here.
I may have to try and explain it to a remote network admin, so I
should know what I'm speaking of, and that way I advance my own net
knowledge which is a welcome thing.

Many thanks for the time & help -

--
Fuzzy
Anonymous
a b C Monitor
May 24, 2004 3:15:49 AM

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

Steve Horsley wrote:

> glen herrmannsfeldt wrote:
>
>> Fuzzball wrote:
>>
>>> I have a number (10, say) of small ethernet devices (medical
>>> monitors) which speak UDP over IP. The problem is that they can be
>>> configured with an IP address only - no subnet mask or default
>>> gateway. I need to be able to talk to these devices (all sitting in
>>> a single room) from an interface server that is some distance away
>>> (i.e. in a basement data center, with the monitors 15 floors up or
>>> more, too far/expensive to wire directly). There is network access
>>> between the data center and the rooms where the monitors are, but it
>>> is composed of a number of segments, which of course these little
>>> monitors won't play with.
>>
>>
>>
>> (snip)
>>
>> Terminal servers will be TCP, not UDP, so I don't think
>> that will help.
>>
>> Small NAT routers, commonly used for home networks, though
>> should be able to do it.
>>
>> The way it is supposed to work is that the router connects
>> between the local (LAN) network (where your devices are),
>> and the rest of the world (WAN). If all on one floor were
>> in one room, then a separate network (subnet) would be the
>> obvious way to do it.
>>
>> They are very affordable now, as models supporting wireless
>> networks come out pushing down the price of ones that don't
>> to around $40.
>>
>> If you can't arrange a separate physical network for them,
>> you should be able to run the LAN side, with private IP
>> addresses, on the same physical network as your existing
>> network. In other words, one such router could support
>> an entire floor, even though it is connected through
>> the regular floor network.
>>
>> Are you sure, though, that they don't support either subnet
>> mask or default router? It would be unusual for an IP
>> implementation in the last 15 years not to support subnets.
>> (I knew of some older that didn't.)
>>
>> Oh, this is really an IP question so should go to
>> comp.protocols.tcp-ip (added)
>>
>> -- glen
>>
>
> Another possibility would be to use subnetting and to enable proxy-arp
> on the router near the monitors.
>
> F'rinstance:
> The monitors are 10.1.1.1, 10.1.1.2...
> The local router is 10.1.1.254, but knows the network is 10.1.1.0/24.
> The manager (I assume no problem with that) is 10.2.1.1 in another
> part of the building.
>
> When the monitors need to send to the manager, they don't know about
> the subnetting and simply try to ARP 10.2.1.1 as though it were on the
> same LAN. If a router is configured with proxy-arp enabled, then
> it will respond tothe ARP request with its own MAC address. The stupid
> monitor then keeps on sending packets to the router (which forwards
> them) without ever knowing the manager box isn't actually
> on the same LAN.
>
> Steve

Many thanks for the reply - and apologies for the next question: What
does the nomenclature/expression "10.1.1.0/24" mean? I'm not an expert
in this area, obviously :-) When you say "manager" I assume you mean
the main server (?) I should help out by explaining a typical sequence
of events (what I want to have happen):
1. interface s/w running (just C code, one interface process per
monitor) on the main server needs to send a UDP request to one of the
monitors upstairs, asking it for data. I.e. the interface s/w on the
server will initiate all conversations. It's a single request/response
paradigm.
2. The correct monitor (addressed by IP addr) should get the request and
respond to it (via UDP).
3. The response is received by the interface s/w on the server and
parsed out and stored.

--
Fuzzy
Anonymous
a b C Monitor
May 24, 2004 7:18:22 AM

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

Fuzzball <fuzzy@fuzzy.net> wrote
> glen herrmannsfeldt wrote:
>
> (snip)
> >
> > Are you sure, though, that they don't support either subnet
> > mask or default router? It would be unusual for an IP
> > implementation in the last 15 years not to support subnets.
> > (I knew of some older that didn't.)
> >
> > Oh, this is really an IP question so should go to
> > comp.protocols.tcp-ip (added)

> These really don't have subnetting or default gateway ability :-) The
> implementation of the comm s/w in the monitors' firmware is probably a
> good 10-15 years old and hasn't changed a whole lot since then. These
> devices are most often used on their own dedicated lan where subnetting
> is not used.


As far as I can see terminal server(s) are not going to help. A
terminal server is essentially a serial to IP convertor and was
originally internded to allow serial teminals to communicate over
IP. You do not seem to have any serial kit?

As already discussed in seperate mesasges you have two options.

1.
Enable proxy ARP on the relevant interface(s) on your routers.
It may well be enabled already since I suspect that it is enabled
by default on many routers. As long as the IP stack in the device
has no further limitations then this should work.

2.
Use Network Address Translation (NAT).
In this case you will most likely need a dedicated router port
for your monitors and in the worst case another router port
for your management station.
This will be more complex to implement and will be more costly
however no matter what limitations the boxes have I would
think that it will be possible to get this to work.


From your description of the environment and application it sounds
as if you should get someone who is properly qualified to
do the design at least.
Anonymous
a b C Monitor
May 24, 2004 10:12:00 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Tom B. wrote:

> On Sat, 22 May 2004 08:45:33 GMT, glen herrmannsfeldt
> <gah@ugcs.caltech.edu> wrote:

>>(snip)

>>Terminal servers will be TCP, not UDP, so I don't think
>>that will help.

> Not always - see link below -

> http://www.lantronix.com/support/docs/pdf/UDS100_PB_910...

Interesting device, though it doesn't seem to say which
protocol it actually uses.

I suppose that could be considered a terminal server, but
more usually one would initiate or accept telnet sessions,
or another remote terminal protocol such as rsh, ssh, or even LAT.

I don't know of a standard UDP based remote terminal protocol.

As far as I can tell, this device requires similar devices
on both ends of the connection. More usual, a terminal
server would communicate with standard protocols so that
it could be used on one end or the other, interoperating
with existing equipment.

-- glen
Anonymous
a b C Monitor
May 25, 2004 8:15:24 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <10b31dvpv7gt14e@corp.supernews.com>, fuzzy@fuzzy.net says...
> Firstly, thanks muchly for the response. I've been since looking up
> proxy arp on google and trying to figure out how it works. Can you help
> me (not being as familiar with this as I'd like) to understand what
> you're telling me a bit more? I should help out by explaining a typical
> sequence of events (what I want to have happen):
> 1. interface s/w running on the main server needs to send request to one
> of the monitors upstairs, asking it for data.

The server has a GW, so he will arp for the gateway's MAC address (if
it's not in the cache already). He finds the mac address for the router
(gateway) and will send the packet to it.

> 2. The correct monitor (addressed by IP addr) should get the request and
> respond to it.

The routers will know how to get to the destination because the router
attached to the monitors will let everyone know how to reach it. Now
the responding part. Since your widget does not know how to reach
anyone but itself. So he has no concept of a gateway (I.e. it's not on
my segment so I should punt to the gateway. But I don't have a gateway
so what to do?) In most cases, the device simply assumes that every
other device on the network is connected to the same ethernet segment as
itself. So he will arp for the servers IP even if that server is five
routers down. The router that's immediately attached to the widget
(monitor in your terms) will know where the server really sits in the
network. So the router will answer the arp query even though he's not
the server. The idea is that the monitor will happily send the frame to
the router (thinking it's sending it to the server). The router will
then forward it on to the proper server.

--

hsb

"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
********************************************************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************
Anonymous
a b C Monitor
May 26, 2004 12:49:24 AM

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

Fuzzball wrote:
>
> Many thanks for the reply - and apologies for the next question: What
> does the nomenclature/expression "10.1.1.0/24" mean? I'm not an expert
> in this area, obviously :-)

It means a network witha 24-bit subnet mask, i.e.
ip address: 10.1.1.0
Subnet mask: 255.255.255.0

This means the top 24 bits of the IP address give you the network portion
of the address, and the last 8 bits give you a host address (0-255) on
that network. It's kind of like having variable-length area codes on
phone numbers.

When you say "manager" I assume you mean
> the main server (?) I should help out by explaining a typical sequence
> of events (what I want to have happen):

The thingy that drives the monitors - the Master Gizmo. I have trouble
seeing it as a server when it's controlling lots of monitors. But yes,
the machine that you call a main server below.

> 1. interface s/w running (just C code, one interface process per
> monitor) on the main server needs to send a UDP request to one of the
> monitors upstairs, asking it for data. I.e. the interface s/w on the
> server will initiate all conversations. It's a single request/response
> paradigm.
> 2. The correct monitor (addressed by IP addr) should get the request and
> respond to it (via UDP).
> 3. The response is received by the interface s/w on the server and
> parsed out and stored.
>

Yup, Proxy Arp fits that kind of usage. It sort of works invisibly to the
IP layer - the boxes would be unaware of it happening. There must be
hundreds of good explanations with diagrams on the web - try google.

It probably has to be set up by the local router administrator though.

Steve
!