I don't know DECnet for Linux, but is there a way that you could
manually disable the eth1 circuit on sketti? Kind of a "define circuit
eth1 state off"?
DECnet/Linux is not supposed to be touching eth1. My /etc/default/decnet
says -
# DNET_INTERFACES specifies the names of ethernet interfaces whose
# MAC address is to be set to the DECnet node address
DNET_INTERFACES="eth0"
and also the /etc/decnet.conf says
#Node Node Name Node Line Line
#Type Address Tag Name Tag
Device
#----- ------- ----- ----- -----
------
executor 2.16 name sketti line eth0
So AFAIK the host DECnet should only be listening on eth0. Chrissy would
probably know for sure.
Bob
Bob Armstrong wrote:
Guys -
Sorry to bother you with a question, but I was wondering if anyone who had
tried Charon-AXP-nce was successful at getting DECnet running on OVMS 8.3
under the Charon emulation?
I'm running ovms 8.3 w/ DECnet & TCP/IP under charon-nce.
I't runnign right now (CTEPBA:: 1.301).
No problems found.
Host OS is Ubuntu 9.10, startup script:
--
#!/bin/sh
export CHARON_RAM_SIZE="256"
export CHARON_DKA0="dka0.vdisk"
export CHARON_DKA100="dka100.vdisk"
export CHARON_CDROM="ovms83-axp.iso"
export CHARON_EWA0="eth1"
cd /emul/charon && exec taskset -c 0-2 /emul/charon/es40_nce
--
eth0 used by host OS, eth1 used by emulator (no entry for eth1 in `intefaces' file), both connected to the same switch.
Hmmm.... Maybe I should uninstall DECnet/Linux from the host and try
again...
I don't know DECnet for Linux, but is there a way that you could manually disable the eth1 circuit on sketti? Kind of a "define circuit eth1 state off"?
--Marc
2.16 shouldn't have answered for your Alpha system.
I think that's OK - the Linux host is also running DECnet/Linux and its
(the host, that is) name is SKETTI, 2.16. It took some fooling, but I'm
pretty sure the host DECnet is using eth0 (as it should be).
That is a difference between our systems. I don't have DECnet on the host, so there isn't anything listening on eth1 except for CHARON-AXP.
I'm still concerned that a "TELL 2.17" got answered by the wrong system.
Here are a couple bad examples:
NCP>tell charon show exec
Node Volatile Summary as of 1-NOV-2009 13:16:12
Executor node = 2.17 (CHARON)
State = on
Identification = HP DECnet for OpenVMS Alpha
NCP>tell charon show exec
Node Volatile Summary as of 1-NOV-2009 13:16:13
Executor node = 2.16 (SKETTI)
Circuit = eth0
State = on
Identification = DECnet for Linux V2.6.31-14-generic on x86_64
And this looks worse:
$ set host charon
Welcome to OpenVMS (TM) Alpha Operating System, Version V8.3 Username: Exit Error reading command input
End of file detected
%REM-S-END, control returned to node DUSTY::
$ set host charon
Welcome to OpenVMS (TM) Alpha Operating System, Version V8.3 sketti login: ^Z
Login incorrect
sketti login: Interrupt Interrupt Are you repeating ^Y to abort the remote session on node CHARON? Y
Sometimes when you connect to 2.17, you're getting 2.16 answering instead. That can't be good.
--Marc
NCP>tell 2.17 show exec
Executor node = 2.16 (SKETTI)
Oppss. I take it all back about it being OK. You're right - that is a
problem. This is new, though - it wasn't doing this before.
That's really odd, though - if I log into the host Linux system and do
ifconfig, I see -
eth0 Link encap:Ethernet HWaddr aa:00:04:00:10:08
inet addr:10.1.1.25 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::21b:78ff:fe39:80df/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6419 errors:0 dropped:0 overruns:0 frame:0
TX packets:1049 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:439015 (439.0 KB) TX bytes:215532 (215.5 KB)
Interrupt:17
eth1 Link encap:Ethernet HWaddr aa:00:04:00:11:08
inet6 addr: fe80::a800:4ff:fe00:1108/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5174 errors:0 dropped:0 overruns:0 frame:0
TX packets:661 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:314584 (314.5 KB) TX bytes:42823 (42.8 KB)
Interrupt:18 Base address:0x5000
Note that eth0 and eth1 DON'T have the same MACs, and I believe they're the
correct MACs for 2.16 (eth0) and 2.17 (eth1) respectively.
Hmmm.... Maybe I should uninstall DECnet/Linux from the host and try
again...
Bob
2.16 shouldn't have answered for your Alpha system.
I think that's OK - the Linux host is also running DECnet/Linux and its
(the host, that is) name is SKETTI, 2.16. It took some fooling, but I'm
pretty sure the host DECnet is using eth0 (as it should be).
The emulation is 2.17, which I'm calling CHARON for the moment. Not very
original, but hey :-) It's using eth1.
The password to the SYSTEM account on 2.17 is GUEST. Have your way with
it - there's nothing on there I want to keep :-)
Bob
I think I see something funny going on. It looks as though your Linux host is listening on eth1:
NCP>tell 2.17 show exec
Node Volatile Summary as of 1-NOV-2009 13:05:01
Executor node = 2.16 (SKETTI)
Circuit = eth0
State = on
Identification = DECnet for Linux V2.6.31-14-generic on x86_64
2.16 shouldn't have answered for your Alpha system.
--Marc
Question - is "auto eth1" the right thing to do
I guess I can answer my own question - if you don't have the "auto" then
the "pre-up" to configure the MAC never gets invoked....
I tried this suggestion, and unfortunately it doesn't fix anything. Eth1
did indeed get pre-configured with the right DECnet MAC before Charon
started, but it made no difference.
I did notice this additional symptom, though -
[On the Charon-AXP-nce emulated OVMS system]
$ mcr ncp show act cir count
...
Circuit = EWA-0
...
12 Unrecognized frame destination
...
That looks like an Ethernet MAC problem, but I've no idea what's causing it.
Bob
I just "dd"ed mine to an ISO file. No problems there. If you have some
ftp site that I can upload it to, I can send you my .iso later tonight.
Thanks, that would be quite helpful. Can you sftp? If so, I'll send you a login you can use.
If my math is right, aa:00:04:00:11:08 works out to 2.17 (and that's the
right address).
It does look like Charon-AXP changed the hardware address of the interface correctly, then.
# The trailing zone network interface
auto eth1
iface eth1 inet manual
pre-up /sbin/ifconfig eth1 hw ether aa:00:04:00:d5:08
I'll give that a try next. Question - is "auto eth1" the right thing to
do? That makes the interface start up when the boot does an "ifup -a",
right? I didn't do that (I figured Charon would start it when it got around
to it).
I'm far from an expert on Linux network interfaces. It doesn't seem to harm anything, and I do want the interface to be up for the emulated system.
Since Charon-AXP is expecting to have dedicated access to the interface, it may do a lot more configuration and management of the interface than I expect. I've been using this setup with SIMH VAX and PDP-11, and something similar for Panda (TOPS-20), so it's just a matter of course for me when I'm setting up an emulated system (that uses DECnet, anyway).
--Marc
Thanks Marc -
I ran into some strange problems with my Alpha CD.
I just "dd"ed mine to an ISO file. No problems there. If you have some
ftp site that I can upload it to, I can send you my .iso later tonight.
One thing that I did that may be useful is that I preconfigured my eth1
interface with the expected (computed) hardware address for my DECnet ...
I didn't do that, although I did do 'ifconfig eth1' on the Linux host
while the Charon/OVMS emulation was running.
eth1 Link encap:Ethernet HWaddr aa:00:04:00:11:08
inet6 addr: fe80::a800:4ff:fe00:1108/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9870 errors:0 dropped:0 overruns:0 frame:0
TX packets:751 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:602103 (602.1 KB) TX bytes:66583 (66.5 KB)
Interrupt:18 Base address:0x5000
If my math is right, aa:00:04:00:11:08 works out to 2.17 (and that's the
right address).
# The trailing zone network interface
auto eth1
iface eth1 inet manual
pre-up /sbin/ifconfig eth1 hw ether aa:00:04:00:d5:08
I'll give that a try next. Question - is "auto eth1" the right thing to
do? That makes the interface start up when the boot does an "ifup -a",
right? I didn't do that (I figured Charon would start it when it got around
to it).
Bob
