Greetings!

I have a new ESP-16 MI Serial Port hub that I'm trying to connect to
and get configured.

The manual for it says the following:

<<>>
The configuration utility is automatically enabled on port 1 after
delaying several seconds to allow an IP address to be configured using
DHCP/BootP. The port will be configured at 19,200 baud, 8 bits per
character, no parity, 1 stop bit and no flow control. If the ESP serial
hub already has an IP address or if the address is acquired through
DHCP/BootP, this access method will not be active.
<<>>

It can also be accessed via a web browser at 192.1.1.1 until you
change it. (Reading through, we MUST change the IP address away from this
default. So, this is for the first access only.)

It is connected to my Sun Ultra 30, the qfe2 network port.

It will have a "hard coded" IP address. And, I do not believe I will
want DHCP to even be "in the picture" after I talk to it the first time,
and configure some "hard coded" IP address.

However, I would guess that I need to (temporarily) configure just my
qfe2 port to be a DHCP-server, to get to this point.

(The link light is not on, and it isn't on until it gets an IP
address via DHCP. Without the link light being on, I can't access it via
the web browser or the configuration utility.)

I will be attempting to temporarily set up just my qfe2 port to serve
DHCP. At that point, if I am able to access it, I will be (a mandatory
thing, from what the manual says) choosing some IP address. After that,
that IP address is how it is accessed.

I have the three System Admin volumes for Solaris 8, and I know
volume 3 talks about DHCP. If anyone has any suggestions for me, to get
it going (as I've never configured DHCP on anything before), and
especially since this is not intended to be a PERMANENT thing, I wouldn't
mind hearing them! :-)

Thank you.

Barry
--
Barry L. Bond | http://home.cfl.rr.com/os9barry/
Software Engineer, ITT Corporation | (My personal home web page, last
bbondATcfl.rr.com | updated February 17, 2005)

Barry L. Bond wrote:
> It can also be accessed via a web browser at 192.1.1.1 until you
> change it. (Reading through, we MUST change the IP address away from this
> default. So, this is for the first access only.)

[snip]

> However, I would guess that I need to (temporarily) configure just my
> qfe2 port to be a DHCP-server, to get to this point.

I'm wondering... Withouth DHCP, wouldn't it try to come up on
192.1.1.1? Have you tried that address?

> (The link light is not on, and it isn't on until it gets an IP
> address via DHCP. Without the link light being on, I can't access it via
> the web browser or the configuration utility.)

That seems very odd. I wouldn't call it a "link" light in that case.
It must have general ethernet connectivity to initiate a DHCP request.

> I will be attempting to temporarily set up just my qfe2 port to serve
> DHCP. At that point, if I am able to access it, I will be (a mandatory
> thing, from what the manual says) choosing some IP address. After that,
> that IP address is how it is accessed.
>
> I have the three System Admin volumes for Solaris 8, and I know
> volume 3 talks about DHCP. If anyone has any suggestions for me, to get
> it going (as I've never configured DHCP on anything before), and
> especially since this is not intended to be a PERMANENT thing, I wouldn't
> mind hearing them! :-)

Just to be sure... Can you run 'snoop -d qfe2' and see that you're even
getting DHCP requests from the device? I don't like that you don't see
a link light.

No requests, nothing for a DHCP server to answer.

--
Darren

On 2008-08-25, Darren Dunham wrote:
> Barry L. Bond wrote:
>> It can also be accessed via a web browser at 192.1.1.1 until you
>> change it. (Reading through, we MUST change the IP address away from this
>> default. So, this is for the first access only.)
>
> [snip]
>
>> However, I would guess that I need to (temporarily) configure just my
>> qfe2 port to be a DHCP-server, to get to this point.
>
> I'm wondering... Withouth DHCP, wouldn't it try to come up on
> 192.1.1.1? Have you tried that address?

[ ... ]

>> I have the three System Admin volumes for Solaris 8, and I know
>> volume 3 talks about DHCP. If anyone has any suggestions for me, to get
>> it going (as I've never configured DHCP on anything before), and
>> especially since this is not intended to be a PERMANENT thing, I wouldn't
>> mind hearing them! :-)
>
> Just to be sure... Can you run 'snoop -d qfe2' and see that you're even
> getting DHCP requests from the device? I don't like that you don't see
> a link light.

And -- have you configured the qfe2 port to be somewhere in the
192.1.1.* block? If the port is configured to be in 192.168.*.*, it
will probably not see anything from 192.1.1.1. Maybe the promiscuous
mode of "snoop" will allow you to see it -- but not talk to it.

Edit /etc/hosts to change your "spare" entry to 192.1.1.10 or
something like that and reboot to switch that port to the new IP range,
and plug the box into the qfe3 port until you get it configured to use
an IP range of your choice.

> No requests, nothing for a DHCP server to answer.

:-)

Good Luck,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Hi Darren!

Thank you very much for your help!

>I'm wondering... Withouth DHCP, wouldn't it try to come up on
>192.1.1.1? Have you tried that address?

Yes. I'm not a "network guru", but I made the address of my qfe2
port 192.1.1.2. When I rebooted, ifconfig for qfe2 showed:

<<>>
qfe2: flags=1000843 mtu 1500 index 4
inet 192.1.1.2 netmask ffffff00 broadcast 192.1.1.255
<<>>

Here were my routes configured on the Sun, at that time:

<<>>
bash-2.03$ netstat -nr

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.1.1.0 192.1.1.2 U 1 0 qfe2
192.168.0.0 192.168.0.201 U 1 8 qfe0
192.168.2.0 192.168.2.2 U 1 1 qfe1
192.168.4.0 192.168.4.1 U 1 0 qfe3
224.0.0.0 192.168.0.201 U 1 0 qfe0
default 192.168.0.1 UG 1 2
127.0.0.1 127.0.0.1 UH 13 235 lo0
<<>>

When I typed "192.1.1.1" into my firefox web browser bar, after a
reasonably long delay, I got "The connection has timed out".

However, without even powering if off, I can unplug the RJ-45 network
cable that goes into qfe2 and plug it into the fourth port of my D-Link
router (which is set to be a DHCP server, for around 20 addresses on the
192.168.0 net), and I see numerous things!

The D-Link router has the 4th light now lit up. And, the serial hub,
on the front, has the following lights on:

Power (left most light, this was on when connected to the Sun, as well)
Online (next light, to the right, also on when on the Sun)
Link (off on Sun, on when connected to D-Link router)
Traffic (off on Sun, irregular blinking on D-Link router)
100 Mbps (off on Sun, on when connected to D-Link router)

Also, when I log onto the D-Link router, it shows this under "LAN
COMPUTERS", IP address 192.168,0.107, and the MAC address is the Ethernet
address of the serial hub.

So, it wound up getting an address that wasn't 192.1.1.1, and it does
show up. The D-Link router and the serial hub appear to be talking very
well, even if I can't! :-O

(I can't connect to it when it's attached to the D-Link router. I
suspect I need to configure something about the router differently,
because I want this to be a LAN connection, and I do NOT want data to/from
it to be even involved with the Internet. I was intending to connect it
to a port of my Sun's QFE card, anyway.)

>That seems very odd. I wouldn't call it a "link" light in that case.
>It must have general Ethernet connectivity to initiate a DHCP request.

You can see what I typed above. When connected to the D-Link router,
the Link light (and others) is on.

>Just to be sure... Can you run 'snoop -d qfe2' and see that you're even
>getting DHCP requests from the device? I don't like that you don't see
>a link light.

I got absolutely nothing, when I connected it to qfe2 just now, and
had the qfe2 as shown above.

Barry
--
Barry L. Bond | http://home.cfl.rr.com/os9barry/
Software Engineer, ITT Corporation | (My personal home web page, last
bbondATcfl.rr.com | updated February 17, 2005)

Hello,

Just to be clear, were you trying to connect the LAN port of the
ESP-16 directly to QFE2 on your sun box? Unless you were using an
ethernet crossover cable this will NOT work. You would have to connect
the ESP-16 LAN port and the QFE2 port on the sun box to an ethernet
switch. Then you should be able to web to 192.1.1.1. Looking at the
user manual for that terminal server it also looks like you could
connect your sun box serial port A (assuming it's free) to port one of
the terminal server (while it is not connected to the LAN) and use TIP
to configure the terminal server. Or use a dec terminal or a wintel
laptop with an open serial port and use hyperterm.

That looks like a nice little terminal server, BTW.

-CN

On 2008-08-26, Christopher Noyes wrote:
> Hello,
>
> Just to be clear, were you trying to connect the LAN port of the
> ESP-16 directly to QFE2 on your sun box? Unless you were using an
> ethernet crossover cable this will NOT work.

A good point. I had forgotten about that. Not having his
equipment to hand makes a difference. :-)

> You would have to connect
> the ESP-16 LAN port and the QFE2 port on the sun box to an ethernet
> switch.

To a switch -- or a hub -- or make a crossover cable by crimping
the wires to these pins at the two ends:

End End
1 2
==============================
1<-------------------->3 One twisted pair
2<-------------------->6

3<-------------------->1 Another twisted pair
6<-------------------->2

And -- while you're about it -- if you have four pair cables,
you might as well do the following:

4<-------------------->7
5<-------------------->8

7<-------------------->4
8<-------------------->5

The pin numbers are counted from left to right with the wire
towards you, the clip down and the connector terminal blades up.

But -- of course he has not yet gotten an appropriate crimper,
RJ-45 connectors, and Cat-5 or Cat-6 cable. He needs those to run the
serial ports to all the terminals he has anyway. The alternative is
buying a bunch of pre-made ethernet cables (he has RJ-45 to DB-25
adaptors already -- came with the box.

Hmm ... some short cables came with the box. Perhaps he should
examine them to see whether any one of them is a pre-made crossover. I
would *hope* that if so it is clearly marked -- but look at the colors
of the wires coming to pins 1 and 2 on each end. If they are the same,
it is not a crossover.

You *can* *buy* crossover cables. I have one purchased one, in
pink so I don't accidentally try to use it for normal connections.

> Then you should be able to web to 192.1.1.1. Looking at the
> user manual for that terminal server it also looks like you could
> connect your sun box serial port A (assuming it's free)

From another thread about the same machine, TTYA is dead, and
TTYB is in use (lightning damage which also zapped the built-in hme0
port) on his Ultra-30. The fact that TTYA is dead, and so is the
multi-RS232 card in his linux box is what got this terminal server into
the game.

> to port one of
> the terminal server (while it is not connected to the LAN) and use TIP
> to configure the terminal server. Or use a dec terminal or a wintel
> laptop with an open serial port and use hyperterm.

He does have DEC VT??? terminals -- he used one of them in the
early diagnostics on the Ultra-30. It remains to be seen how many
others of his terminals scattered about the house have survived. I
suggested that he make a loopback DB-25 connector to do a
quick-and-dirty test of the individual terminals not depending on
anything else working -- but his focus was on getting the Ultra-30
working first. :-)

> That looks like a nice little terminal server, BTW.

I should look at that too -- except that I have so few needs for
serial ports these days. Just one on each server machine for a console,
except that I've given each machine a framebuffer connected to a VGA
switchbox, and each has its own keyboard. Less problem with the system
shutting down when you switch terminals because it interprets the
disconnection as a BREAK. :-) Just have to keep the cats off the
keyboards. :-)

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Dear DoN, Darren, Christopher, whoever else!

> To a switch -- or a hub -- or make a crossover cable by crimping
>the wires to these pins at the two ends:

Great news! That was it!!

First of all, a crossover cable came with my D-Link router, so I had
one already. :-)

Second, as soon as I plugged it into qfe2 with the crossover
cable, I had all the same lights that were on when it was plugged into the
D-Link router.

Third, I typed "https://192.1.1.1" in my firefox, on the Linux, and
after a LONG delay, I still got "The connection has timed out".

However, I started the Sun web browser, which is netscape.

I typed 192.1.1.1 into its URL/address box, and VOILA!

I logged in. I set an administrator's password!

The hardest is indeed over! I'm talking to it! :-)

I don't absolutely HAVE to change its IP address, and so I didn't
this time, but I'm going to.

It is asking for the following: IP Address, Subnet Mask, Gateway
Address, and Interface Mode.

I know (or at least I'll think about and select an) IP address. :-)
If Subnet Mask is what I know generally as a netmask, I'll be able to put
something appropriate in there.

Gateway address...? I don't WANT this "talking" on the Internet.
What should go here, if the Sun routes are okay?

Interface Mode is a menu with: auto-negotiate, 10 Mb/sec (half or
full duplex), 10 Mb/sec half-duplex, 10 Mb/sec, full-duplex, 100 Mb/sec
(half or full duplex), 100 Mb/sec, half-duplex, and 100 Mb/sec,
full-duplex. (I'll likely leave it at auto-negotiate...)

DoN had recently suggested using a different non-routable block, such
as starting with 172.16. I'm open to suggestions on what would be best
for me to set the IP address (and the other stuff) to! :-)

I am intending for this to be used primarily from the Linux system.
(The reason for this is some of the serial devices I have also "work with"
programs or large/multiple files I have on the Linux system, though the
seven terminals I expect I could allow Solaris to use.)

There is a driver for Linux as well as Solaris, so I'll be getting
both. However, the Linux system, attached to the Sun via another qfe
port, will be the primary user.

I do not want even a hint of a connection to the cable
modem/Internet.

Great success, though! I want to thank you, who told me I needed a
crossover cable much faster than I would have figured out without you!
:-)

Barry
--
Barry L. Bond | http://home.cfl.rr.com/os9barry/
Software Engineer, ITT Corporation | (My personal home web page, last
bbondATcfl.rr.com | updated February 17, 2005)

barry@barrycon.cfl.rr.com (Barry L. Bond) writes:

[now _way_ off-topic for comp.sys.sun.hardware; but
comp.protocols.tcp-ip would probably go right over his head]

> Third, I typed "https://192.1.1.1" in my firefox, on the Linux, and
> after a LONG delay, I still got "The connection has timed out".

There is no known route for packets to go from Linux box to serial hub
and back again, so the Linux web browser times out.

> However, I started the Sun web browser, which is netscape.
....
> The hardest is indeed over! I'm talking to it! :-)
....
> If Subnet Mask is what I know generally as a netmask, I'll be able
> to put something appropriate in there.

Yes it is. 255.255.255.0 is usually the right choice for home
networks, as it will allow host addresses from a.b.c.1 up to a.b.c.254
(usually way more than a home user has) to talk to each other without
a router in between, but avoids the "messy numbers" of masks for
smaller subnets.

> Gateway address...? I don't WANT this "talking" on the Internet.
> What should go here, if the Sun routes are okay?

0.0.0.0, which will be interpreted as "no gateway - if you can talk to
it direct, don't talk to it at all". Otherwise, to stop it being able
to go outside you'll need to fiddle with routing or firewall config on
the Sun, or set up a packet filter on your D-Link if you can (which in
itself would not be a bad idea anyway).

> Interface Mode is a menu with: auto-negotiate, 10 Mb/sec (half or
> full duplex), 10 Mb/sec half-duplex, 10 Mb/sec, full-duplex, 100 Mb/sec
> (half or full duplex), 100 Mb/sec, half-duplex, and 100 Mb/sec,
> full-duplex. (I'll likely leave it at auto-negotiate...)

Best idea, unless you have problems like autoneg-pingpong that was
much more prevalent in the early days of 100BaseT, when you should
nail down one end of the link and let the other figure it out.

> DoN had recently suggested using a different non-routable block, such
> as starting with 172.16. I'm open to suggestions on what would be best
> for me to set the IP address (and the other stuff) to! :-)

Keeping different subnets on completely different address ranges does
(as already mentioned by someone) make it easier to separate things
when browsing logs, but ...

> I am intending for this to be used primarily from the Linux system.
> (The reason for this is some of the serial devices I have also "work with"
> programs or large/multiple files I have on the Linux system, though the
> seven terminals I expect I could allow Solaris to use.)

In that case you might be better off with an Ethernet switch or hub
into which you plug your Linux box, your serial hub, and one of your
Sun's qfe ports, and configure the serial hub to have another IP
address on the same subnet as the qfe and Linux box that are currently
connected together. i.e. (warning: display with monospace font) from

Sun qfe0 (192.168.0.201)<-->(192.168.0.1) D-Link
qfe1 (192.168.2.2) <---+
qfe2 (192.1.1.2) <-+ |
| |
ESP-16 (192.1.1.1) <-+ |
|
Linux (192.168.2.1) <---+

(3 separate IP subnets, each with just 2 hosts)

to

Sun qfe0 (192.168.0.201)<-->(192.168.0.1) D-Link
qfe1 (192.168.2.2) <---+
|
ESP-16 (192.168.2.99) <---+
|
Linux (192.168.2.1) <---+

(2 separate subnets, 192.168.2.x having 3 hosts)

> I do not want even a hint of a connection to the cable
> modem/Internet.

If you have Linux, Sun, and serial hub all connected to an Ethernet
hub (via straight-through, not crossover, cables), with addresses in
the same subnet, and the serial hub has its gateway set to 0.0.0.0,
then it will not be able to talk to the outside world but will be able
to talk with both Sun and Linux box.

To get the same effect with the serial hub connected direct to a qfe
port on the Sun, and needing the Sun to route packets between serial
hub and Linux box but _not_ route packets between serial hub and
outside world will be much more complex (since the serial hub would
need to have its gateway set to the Sun's corresponding IP address
just to talk to the Linux box, and thus the Sun or something upstream
would need to enforce your policy of "serial hub doesn't talk to
outside world").

mlp

Hello, Mark and others!

>[now _way_ off-topic for comp.sys.sun.hardware; but
>comp.protocols.tcp-ip would probably go right over his head]

I'm very sorry that I'm not as intelligent as you, and that I haven't
had as much time and experience at dealing with network questions.

>> I am intending for this to be used primarily from the Linux system.
>> (The reason for this is some of the serial devices I have also "work with"
>> programs or large/multiple files I have on the Linux system, though the
>> seven terminals I expect I could allow Solaris to use.)
>
>In that case you might be better off with an Ethernet switch or hub
>into which you plug your Linux box, your serial hub, and one of your
>Sun's qfe ports, and configure the serial hub to have another IP
>address on the same subnet as the qfe and Linux box that are currently
>connected together. i.e. (warning: display with monospace font) from
>
>Sun qfe0 (192.168.0.201)<-->(192.168.0.1) D-Link
> qfe1 (192.168.2.2) <---+
> qfe2 (192.1.1.2) <-+ |
> | |
>ESP-16 (192.1.1.1) <-+ |
> |
>Linux (192.168.2.1) <---+
>
>(3 separate IP subnets, each with just 2 hosts)
>
>to
>
>Sun qfe0 (192.168.0.201)<-->(192.168.0.1) D-Link
> qfe1 (192.168.2.2) <---+
> |
>ESP-16 (192.168.2.99) <---+
> |
>Linux (192.168.2.1) <---+
>
>(2 separate subnets, 192.168.2.x having 3 hosts)

Mark, thank you VERY MUCH for this. I believe I understand. I will
be purchasing an Ethernet Switch this coming Saturday, and I will
configure the Linux and Sun qfe1 network ports along with the serial hub
all on 192.168.2.

This was very helpful to me.

I apologize to everyone for wasting your time. I won't bother you
again.

Barry
--
Barry L. Bond | http://home.cfl.rr.com/os9barry/
Software Engineer, ITT Corporation | (My personal home web page, last
bbondATcfl.rr.com | updated February 17, 2005)

barry@barrycon.cfl.rr.com (Barry L. Bond) writes:

> Hello, Mark and others!
>
>>[now _way_ off-topic for comp.sys.sun.hardware; but
>>comp.protocols.tcp-ip would probably go right over his head]

> I'm very sorry that I'm not as intelligent as you, and that I
> haven't had as much time and experience at dealing with network
> questions.

Neither clause would be grounds for apology from you in any event,
Barry, and I'm certainly not claiming the former (you're employed -
you're doing _something_ righter than I am).

Anyhow, I'm not sure what the right newsgroup would be for "I have
this group of diverse devices and I want them to be able to talk
together across the network thus, but I don't know how to make it
so" queries. It's the sort of thing you'd probably need to pay a me
to design for you.

> I apologize to everyone for wasting your time. I won't bother you
> again.

Au contraire, I don't think too much time has been wasted (although I
would use "I've been busy elsewhere" rather than _quite_ so much life
story - rec.*, soc.*, talk.*, and alt.* are where one expects to find
that) - and anybody who was bothered should certainly have killed the
thread(s) by now.

It's often very difficult to separate hardware- from software- from
otherstuff- faults when recovering from disasters like a lightning
strike, especially where the struck thing is your only unit of its
type _and_ your experience with e.g. network config is limited.

DoN's hardware step-by-step has been most interesting to me, as my
only bit of Sun hardware is a Sun3 which is in storage at present.
Seeing what newer gear can and can't do is illuminating.

mlp

Hi Mark!

Thank you. I feel a little better/different about this reply. :-)

>Neither clause would be grounds for apology from you in any event,
>Barry, and I'm certainly not claiming the former (you're employed -
>you're doing _something_ righter than I am).

Well, while I don't know, it may not be your fault. I was laid off
in Nov 2002 -- and it was May 2005 before I got back in my field -- at ITT!

(The Lord gave me repentance because of my sin in Jan of 2003, but
that will definitely be email if anyone's interested.) :-)

>It's often very difficult to separate hardware- from software- from
>otherstuff- faults when recovering from disasters like a lightning
>strike, especially where the struck thing is your only unit of its
>type _and_ your experience with e.g. network config is limited.

Thank you for your understanding.

Barry
--
Barry L. Bond | http://home.cfl.rr.com/os9barry/
Software Engineer, ITT Corporation | (My personal home web page, last
bbondATcfl.rr.com | updated February 17, 2005)

Mark L Pappin wrote:
> Best idea, unless you have problems like autoneg-pingpong that was
> much more prevalent in the early days of 100BaseT, when you should
> nail down one end of the link and let the other figure it out.

Assuming you mean disable autoneg and hardcode a setting, if you nail
down one end of the link you really must nail down the other end.
What follows is some boiler-plate I have stashed away for this topic:

How 100Base-T Autoneg is supposed to work:

When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full-duplex if both sides can do
full-duplex.

If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.

If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.

So, the following table shows what will happen given various settings
on each side:

Auto Half Full

Auto Happiness Lucky Sorrow

Half Lucky Happiness Sorrow

Full Sorrow Sorrow Happiness

Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly Sorrow means that there _will_ be a duplex
mis-match.

When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of _LATE_ collisions
("normal" collisions don't count here). On the side running
full-duplex you will see things like FCS errors. Note that those
errors are not necessarily conclusive, they are simply indicators.

Further, it is important to keep in mind that a "clean" ping (or the
like - eg "linkloop" or default netperf TCP_RR) test result is
inconclusive here - a duplex mismatch causes lost traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.

Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.


--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

All who have replied to help me,

I have had success setting up the ESP-16 MI serial hub!

I have had success regarding every serial device (for the moment,
skipping terminals) I had on the Cyclades Cyclom YeP PCI card in my Linux
system. The X10 CP290, the Seiko mailing label printer, the Caller ID
box, the AICOM speech synthesizer, the APC Smart-UPS 750XL UPS.

All of these are working perfectly.

I have one terminal (of the two) in my training room where I was not
successful at logging in on it. I haven't done anything else with it at
the moment. I am not teaching at home right now, and I'm really not using
or desperately needing that terminal right now. (And, I actually have a
couple of spare VT220s, if it turns out the terminal is bad. Though I'll
be double checking the cables involved. The serial hub port attaches to a
wall jack, and then the long cable is involved which goes from the office
to the training room, and then the cable is attached to the wall jack in
there and goes to the terminal. I'm not sure at the moment exactly where
the problem is. I have a breakout box, and Avocent has what seems to be a
wonderful diagnostic utility, though I wasn't able to run it yet. [It may
be my version of java. I've emailed Dan about this.])

Saturday night, the VT330 terminal in my bedroom allowed me to log on
to both sessions. (The VT330 has two independent serial ports, and
attaches to two independent serial connections. The F4 key switches back
and forth between the two sessions.) Hours later, I was able to log out
on session 1. However, session 2 wasn't responding. At the moment I am
able to use at least one of the two sessions in my master bedroom, so I'm
happy. As I get a chance, I'll do some troubleshooting to try to
determine the problem there.

Mark's suggestion with an Ethernet switch is working exactly as he
indicated. I have the qfe1 of the Sun, the only Ethernet port of the
Linux, and the serial hub all attached to it, and all the IPs start with
192.168.2. They're talking amongst themselves just fine. And, according
to snoop, the interchanges involving the serial hub are NOT getting to the
D-Link router or cable modem! Thank you again, Mark!

I have successfully run Avocent's configure/install for the Linux and
the Solaris SPARC, and I have only kudos to report! The pkgadd for the
Solaris and the RPM file for the Linux installation went perfectly, and I
haven't had any trouble on either system, at this point, that I attribute
to that. Both systems are "talking" to the serial hub. (I am not USING it
from the Sun right, but I can if it comes to it!)

I just wanted to let you all know that ending today (I was off from
work), I have nearly everything working! All the devices other than the
weather station are, and nearly all my terminals!

Thank you all -- again!

Barry
--
Barry L. Bond | http://home.cfl.rr.com/os9barry/
Software Engineer, ITT Corporation | (My personal home web page, last
bbondATcfl.rr.com | updated February 17, 2005)

On 2008-09-01, Barry L. Bond wrote:
>
> All who have replied to help me,
>
> I have had success setting up the ESP-16 MI serial hub!
>
> I have had success regarding every serial device (for the moment,
> skipping terminals) I had on the Cyclades Cyclom YeP PCI card in my Linux
> system. The X10 CP290, the Seiko mailing label printer, the Caller ID
> box, the AICOM speech synthesizer, the APC Smart-UPS 750XL UPS.
>
> All of these are working perfectly.

Great.

> I have one terminal (of the two) in my training room where I was not
> successful at logging in on it. I haven't done anything else with it at
> the moment. I am not teaching at home right now, and I'm really not using
> or desperately needing that terminal right now. (And, I actually have a
> couple of spare VT220s, if it turns out the terminal is bad. Though I'll
> be double checking the cables involved.

Check the terminal itself first.

> I have a breakout box


Then you probably do not even need to make a loopback connector
to test the terminal's serial port. Just use the breakout box to see
whether you are getting pulses out the data-out pin, and then jumper it
on the breakout box to the data-in pin and see if what you type appears
on the terminal's screen. If it doesn't -- the terminal is bad. (Or it
*may* need DSR and CTS tied true -- which you can also test on your
breakout box.

> Saturday night, the VT330 terminal in my bedroom allowed me to log on
> to both sessions. (The VT330 has two independent serial ports, and
> attaches to two independent serial connections. The F4 key switches back
> and forth between the two sessions.) Hours later, I was able to log out
> on session 1. However, session 2 wasn't responding.

Was session 1 only sitting idle while you were working on
session two? If so -- is there some kind of idle timeout feature in the
seral box? If so -- you can probably re-configure this -- but you have
to find it first.

[ ... ]

> I just wanted to let you all know that ending today (I was off from
> work), I have nearly everything working! All the devices other than the
> weather station are, and nearly all my terminals!

Thanks, and Good Luck,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Hi DoN!

> Was session 1 only sitting idle while you were working on
>session two? If so -- is there some kind of idle timeout feature in the
>seral box? If so -- you can probably re-configure this -- but you have
>to find it first.

No.

And, yes, there IS something about serial port attributes where you
can indicate an idle time, but I have that set to 0, which means disabled.

I've talked to a person at work who described electronic devices as
acting "strangely" after a lightning strike, sometimes for a short time,
but eventually returning to "normal". I'll mention this in email. :-)

I haven't done anything else with that terminal yet, but it could be
that! (At least, other electronic devices I have fit this category!)

Barry
--
Barry L. Bond | http://home.cfl.rr.com/os9barry/
Software Engineer, ITT Corporation | (My personal home web page, last
bbondATcfl.rr.com | updated February 17, 2005)