linux-decnet-user — Discussion for users of DECnet on Linux

[Linux-decnet-user] eth0 deactivates with DECnet module

[<ray...@mi...>]

I'm a Linux newbie who's spent lots of hours very intermittently over the last few months trying to simulataneously learn Linux and install your DECnet program, and I've finally reached the point where I understand enough to ask a question.

My current problem is this:

I've got Redhat 8.0 on two machines doing the same thing.  On bootup, everything seems loaded and happy including eth0 with the IP networking.  Installing DECnet as a module (I haven't been able to successfully get a DECnet kernel compiled yet), it immediately shuts off eth0, and it won't reactivate until a reboot.  Trying to remove the DECnet module with RMMOD says "decnet: device or resource busy".

I'm pretty sure that I've done the MACADDR right in /etc/sysconfig/network-scripts/ifcfg-eth0; it appears that the PC card adapter in the notebook is Tulip based and the 3com in the desktop is not. (Does MACADDR and HWADDR both work for this?)

Another basic question: if this were working, should I be able to do a loopback dnping or sethost to test it?  That currently tells me "Write: transport endpoint is not connected"; I assume a symptom of the problem above.

Any suggestions would be appreciated.  Thanks.

Ray McClellan

RE: [Linux-decnet-user] Can only connect to three out offourofourVMS nodes

[Ben A. <be...@bg...>]

On Mon, 2003-02-24 at 16:35, Colin Butcher wrote:
> If you really mean not in use at all (no cable even) then OK

That's correct.

> , I'd probably
> enable it on both and then you have a measure of manual failover, or better
> would be to use the available bandwidth out of the box and run DECnet over
> one interface and IP etc. over the other one, plug them both into the same
> switch and off you go. Be careful about doing this if you're also running
> clustering (SCS protocol) and LAT etc. Might be a nice plan to run the SCS
> traffic over a private 4 box ethernet (if they all have dual 100Mbit/sec FDX
> NICs or even better Gigabit NICs), disable SCS on the rest
> (SYS$UPDATE:LAVC$STOP_BUS). It all depends on what's out there and what
> protocols you need where.

I believe DECnet use on our network is declining and in fairly low
demand.  At least, that's how it seems from doing a bit of traffic
monitoring, so I doubt if running both interfaces would be worth the
added complexity.  Anyway, I'll mention the manual failover point to my
sys admin and let him choose whether to leave phaseiv enabled on the
unused interface or not.

> NET$CONFIGURE in ADVANCED mode will be your friend (@NET$CONFIGURE
> ADVANCED) - also lets you set things like the ES hello timer values. Read
> the manual carefully first - it does vary slightly depending on which
> version of VMS you're running.

It turns out my sys admin is wary of running NET$CONFIGURE at all
because he's afraid of the possibility of inadvertently toasting
currently working settings.  He tells me if he knew exactly which NCL
script(s) to modify manually and how, that would be his preferred way to
go about it, as then we could back things out easily by simply renaming
files if something went wrong.

> Also, if you're going to be rebooting - remember to install the current
> patches for VMS. There's at least one very useful fix for ethernet link
> speed / duplex autonegotiation. You probably want to check your Alpha's
> firmware version while you're at it and update that too.

I believe our sys admin stays on top of these things already, but I'll
mention it anyway.  The system is showing 38 days uptime which means
some system maintenance has been performed recently.  (I can't remember
the last time our UPSes completely conked out during a power outage, or
a piece of equipment in this system failed. :)

So now I'll have to look over the NCL stuff.  My first barrier to
overcome is that as an ordinary unprivileged user, I cannot see
SYS$MANAGER:*.NCL (my best guess at where to start).  So, where to go
from here?  I'm sure my sys admin will grant me any reasonable access to
materials needed to research this configuration change.

Thanks for bringing me this far.

Ben
-- 
      Ben Armstrong                -.       Medianet Development Group,
      BAr...@dy...         `-.    Dymaxion Research Limited
      <URL: http://www.dymaxion.ca/>    `-  Halifax, Nova Scotia, Canada

RE: [Linux-decnet-user] Can only connect to three out of fourofourVMS nodes

[Ben A. <be...@bg...>]

On Mon, 2003-02-24 at 15:55, Colin Butcher wrote:
> Very quickly since I'm away later today and all tomorrow: DON'T TOUCH IT
> YET!

Heh, no worries.  I'm very conservative making recommendations to my sys
admin, and this stuff will be scheduled for after hours regardless of
whether a reboot is required or not.  It will probably need to wait for
the next scheduled maintenance requiring a reboot because the requested
change is very low priority.  We'll be reviewing carefully your advice
and asking any questions we still have before doing anything.

> You can have both interfaces with Phase IV addressing enabled, but they MUST
> NOT be connected to the same ethernet segment or bridged between segments.
> Routed would be OK, but bridged isn't. Swapping over Phase IV / V addressing
> per interface might work - it might just screw up everything else
> completely. It depends how the network's been configured, what the rest of
> the network looks like, etc. etc.

Ah.  Well, I understand that the first interface simply is not used at
all.  I don't know why the second was chosen instead.  That just seems
to be the way things are.  It seems the safe way to go is to set the
first interface phaseiv addressing to false because we don't know what
future use it might be put to, and I'd hate for someone to forget and
have it cause problems later.

> Changing the MAC address that an adapter runs with is generally a 'reboot'
> issue, but you might be able to take an adapter offline and bring it back -
> it depends what other protocols are in use on that adapter. Reconfigure with
> NET$CONFIGURE (or manual hacking of the NCL scripts IF you know exactly what
> you're doing) and reboot is safest.

I suspect my sys admin will feel most comfortable doing a NET$CONFIGURE
and reboot.

> I think that we're getting into network diagram territory and understanding
> how your VMS systems are set up. That's probably heading into rather more
> than a few comments by e-mail.

Well, it's fairly simple now, isn't it, since the system in question is
only connected to one network on one physical interface?

> Some other info from comp.os.vms (from me) might help too:
...
> This 'Phase IV changes the MAC address' behaviour is behind what's meant by
> Phase IV compatible addressing in Phase V - and it's why NET$CONFIGURE won't
> let you (by default) enable Phase IV Compatible addressing on more than one
> NIC.

OK, I think I see now.

So, back to my question now.  Given that the first interface is not in
use and that the second interface should have phaseiv addressing turned
on to support phaseiv-only nodes (currently only my workstation) should
I issue the two NCL commands I pasted in my earlier note, or does
running NET$CONFIGURE handle that detail for me?

Thanks,
Ben
-- 
      Ben Armstrong                -.       Medianet Development Group,
      BAr...@dy...         `-.    Dymaxion Research Limited
      <URL: http://www.dymaxion.ca/>    `-  Halifax, Nova Scotia, Canada

RE: [Linux-decnet-user] Can only connect to three out of fourofour VMS nodes

[Ben A. <be...@bg...>]

On Mon, 2003-02-24 at 13:02, Colin Butcher wrote:
> Another good start is to use NCL SHO
> ROUT CIRC * ALL to see the "enable Phase IV address" - which should be TRUE
> if Phase IV compatible addressing and FALSE if not.

Bingo!  The system has two interfaces and, surprise surprise, the one
that is actually used has it set to false.  The other one that isn't
actually being used for anything is set to true.  I'm guessing that this
is because it is the first interface, and therefore was simply set to
true by default.

Since all nodes on our network apparently speak Phase V, this hasn't
been an issue up until now.

The doc says "only one circuit may have this attribute set to true".  Do
you know if setting the other circuit to true will automatically set the
first one to false, or if I need to tell my sys admin to set the first
one to false beforehand?

In any event, I guess I just need to ask my sys admin to issue these ncl
commands:

set routing circuit csmacd-0 enable phaseiv address false
set routing circuit csmacd-1 enable phaseiv address true

Can someone verify this for me, please?  Can this be done on a "live"
system without taking down any services first?

Thanks,
Ben
-- 
      Ben Armstrong                -.       Medianet Development Group,
      BAr...@dy...         `-.    Dymaxion Research Limited
      <URL: http://www.dymaxion.ca/>    `-  Halifax, Nova Scotia, Canada

RE: [Linux-decnet-user] Can only connect to three out of four ofour VMS nodes

[Ben A. <be...@bg...>]

On Sat, 2003-02-22 at 06:15, Colin Butcher wrote:
> It looks to me as if there isn't enough understanding of how to configure /
> manage / use DECnet at the VMS end.

Heh, well, there's certainly very little understanding on my part.  I
don't administer the VMS end.  However, I am friendly with the VMS sys
admin, so it is more likely I'll be able to make changes at the VMS end
than at any of the switches.  So this is good news, I guess.

> It depends
...
> See the published DECnet on VMS manuals at
> http://www.openvms.compaq.com/doc/ and find DECnet way down the left hand
> side
...
> There's also some Phase IV and Phase V notes at
> www.xdelta.co.uk/downloads/decus which are things I've done for the HP User
> Group over the years.

Thanks.  Filed for future reference.

> Layer 2 (MAC address / protocol type etc.) filtering usually only comes in
> if you've got bridges set up with filtering enabled, or bridge filtering
> between VLANS or whatever set up in core switches. That's NOT a default
> configuration, so requires thought and planning to set it up.

OK.  I managed to get the attention of the net admin here responsible
for the switches and he assures me there is no filtering in place.

> Phase V in Phase IV compatible addressing mode (which is what most people
> use) will do all the Phase IV hello stuff and use Phase IV MAC addressing
> for the ethernet packets.

Now that's interesting.  You say "... which is what most people use". 
But how do I (as an unprivileged user on the VMS host) determine if that
is in fact what is used on this node?  Could it be relevant that the MAC
addr involved in all non-IP packets I was able to log from the VMS host
is 08:00:2B:86:56:E1?  That doesn't look like a area.node format MAC
address.  Does that mean this host just isn't in Phase IV compatible
addressing mode?  If not, what is the impact of switching it (i.e. could
I get my VMS sys admin to change it without breaking anything else?)

Thanks,
Ben
-- 
      Ben Armstrong                -.       Medianet Development Group,
      BAr...@dy...         `-.    Dymaxion Research Limited
      <URL: http://www.dymaxion.ca/>    `-  Halifax, Nova Scotia, Canada

Re: [Linux-decnet-user] Can only connect to three out of four of our VMS nodes

[Steven W. <st...@gw...>]

Hi,

> 
> On Fri, 2003-02-21 at 16:24, Steven Whitehouse wrote:
> > Can you find out the OS and version of the problematic node?
> 
> OpenVMS V7.1-2 running on an AlphaServer DS10 466.  Has DECNET OSI V7.1,
> ECO 07.
> 
> > Thats a bit odd I think. The LAT connection suggests that there is MAC
> > level connectivity between the two machines, which would normally
> > indicate that the Linux box should be getting hello messages too.
> 
> I thought it should be too.
> 
> > I have seen problems in the past with Phase V not sending regular enough
> > hello messages to keep an entry in the neighbour table. This can be fixed
> > by forcing the information into the table with iproute2.
> 
> Sure, but wouldn't I eventually see a hello?  Anyway, I tried playing
> with iproute2 but I'm not sure if I have the necessary stuff in my
> kernel to support it.  Will look into this and recompile kernel if
> necessary.
>
Yes, you should see a hello at some stage even if it times out after
60 seconds. The Linux neighbour cache is based on a timeout system which
records the time of last update in each entry and then times out the entry
at a later time which is set per table. This means that its rather tricky
to take the variable timeouts into account that are sent in the hello messages
as it should. We could "fix" the last update times to push them back in time
a certain amount, but I'd rather do the fix properly and allow entries to
specify their own timeouts. So the iproute2 route is a bit of a hack, but
useful nonetheless.
 
> > Might well do. I wonder if there isn't some filtering on the network
> > affecting the hello messages. Not that this should prevent you from
> > setting up a connction with 1.1, it would only explain the lack of an
> > automatically generated entry in the neighbour table.
> 
> Since I'm just toying around to see if I can get this working, getting
> information about what filtering, if any, might be in place on the
> switches may prove to be difficult to extract from the net admins.  It's
> not that they're unreasonable people, but it's very difficult to get any
> of their time.
>
Yes I guessed that might be the case - hence my request of the tcpdump.
 
> > Could you send a tcpdump of the Linux box trying to connect to 1.1 ?
> > The first thing to establish is whether 1.1 replies at all, and if it
> > does, to find out whether its sending something unexpected. Make sure
> > that you get a full hex dump of each packet as I don't trust tcpdump
> > to decode the packets correctly,
> 
> Sure thing.
> 
> # tcpdump -s0 -x decnet host 1.20
> tcpdump: listening on eth0
> 21:10:41.495812 1.20 > 1.1 50 conn-initiate 8213>0 ver 4.1 segsize 1450 
>                          3200 8126 0000 aa00 0400 0104 0000 aa00
>                          0400 1404 0000 0000 1800 0015 2001 03aa
>                          0500 1902 0000 0000 0005 4c49 4e55 5803
>                          0000 0000
> 21:10:43.489676 1.20 > 1.1 50 retrans-conn-initiate 8213>0 ver 4.1 segsize 1450 
>                          3200 8126 0000 aa00 0400 0104 0000 aa00
>                          0400 1404 0000 0000 6800 0015 2001 03aa
>                          0500 1902 0000 0000 0005 4c49 4e55 5803
>                          0000 0000
> ...
> 
> Then lots of "retrans-conn-initiate" identical to the second packet.  I
> eventually ^C'd.
>
Ah. So unless you can tell by looking on the remote end that it has seen
these packets and is responding, then I very much suspect that you don't
have communication in either direction between 1.1 and 1.20 since no
reply is being received. It looks like a network problem to me I'm afraid,

Steve.

RE: [Linux-decnet-user] Can only connect to three out of four ofour VMS nodes

[Colin B. <col...@xd...>]

My background is DECnet Phase IV & V, predominantly VMS, not Linux, so I
can't comment on any of the Linux specific stuff.

It looks to me as if there isn't enough understanding of how to configure /
manage / use DECnet at the VMS end.

<snip>

>> I have seen problems in the past with Phase V not sending regular enough
>> hello messages to keep an entry in the neighbour table. This can be fixed
>> by forcing the information into the table with iproute2.
>
> Sure, but wouldn't I eventually see a hello?  Anyway, I tried playing
> with iproute2 but I'm not sure if I have the necessary stuff in my
>  kernel to support it.  Will look into this and recompile kernel if
>  necessary.

It depends what the "hello timer" is set to. Your code should cope with
anything between the minimum and maximum values - you may need to see the
published (not sure where they are on the web now) functional
specifications, however you should be able to determine these by using NCP
(Phase IV) or NCL (phase V) on a test node. Note that there are hello timers
for L1 routers to other L1 routers and for L1 routers to End Nodes (Phase IV
terminology) or IS to IS and IS to ES (Phase V terminology). Phase IV
default is 30 secs, Phase V default is 600 secs. I usually change these to
be more useful for a specific network, along with other things such as
retransmit factor. See the published DECnet on VMS manuals at
http://www.openvms.compaq.com/doc/ and find DECnet way down the left hand
side - the various parameters you can configure haven't changed for some
time.

There's also some Phase IV and Phase V notes at
www.xdelta.co.uk/downloads/decus which are things I've done for the HP User
Group over the years.

> > Might well do. I wonder if there isn't some filtering on the network
> > affecting the hello messages. Not that this should prevent you from
> > setting up a connction with 1.1, it would only explain the lack of an
> > automatically generated entry in the neighbour table.
>
> Since I'm just toying around to see if I can get this working, getting
i> nformation about what filtering, if any, might be in place on the
> switches may prove to be difficult to extract from the net admins.  It's
> not that they're unreasonable people, but it's very difficult to get any
> of their time.

Layer 2 (MAC address / protocol type etc.) filtering usually only comes in
if you've got bridges set up with filtering enabled, or bridge filtering
between VLANS or whatever set up in core switches. That's NOT a default
configuration, so requires thought and planning to set it up. Don't even
think of going there and making / suggesting changes unless you understand
it! It's easy enough to see if filtering is happening - just use a network
analyser (packet sniffer or whatever - even the M$ network monitor from
their SMS product will be useful enough) and look for all the DECnet related
packets and sort out what's what based on the MAC addresses in the
"destination" field. You should see multicast addresses on packets which
correspond to the Phase IV and Phase V L1 and End Node hellos etc. See
RFC1700 for all the address and protocol type details at
http://www.faqs.org/rfcs/rfc1700.html. DECnet Phase IV is protocol type
60-03, Phase IV end node hello multicast address is AB-00-00-03-00-00, Phase
IV router hello is AB-00-00-04-00-00.

Phase V in Phase IV compatible addressing mode (which is what most people
use) will do all the Phase IV hello stuff and use Phase IV MAC addressing
for the ethernet packets.


I'm currently trying to write a reasonable definitive article on "DECnet, a
Technical Overview" for the VMS Technical Journal, so look there in a couple
of months if you're interested -
http://www.openvms.compaq.com/openvms/journal/index.html

Re: [Linux-decnet-user] Can only connect to three out of four of our VMS nodes

[Ben A. <be...@bg...>]

On Fri, 2003-02-21 at 16:24, Steven Whitehouse wrote:
> Can you find out the OS and version of the problematic node?

OpenVMS V7.1-2 running on an AlphaServer DS10 466.  Has DECNET OSI V7.1,
ECO 07.

> Thats a bit odd I think. The LAT connection suggests that there is MAC
> level connectivity between the two machines, which would normally
> indicate that the Linux box should be getting hello messages too.

I thought it should be too.

> I have seen problems in the past with Phase V not sending regular enough
> hello messages to keep an entry in the neighbour table. This can be fixed
> by forcing the information into the table with iproute2.

Sure, but wouldn't I eventually see a hello?  Anyway, I tried playing
with iproute2 but I'm not sure if I have the necessary stuff in my
kernel to support it.  Will look into this and recompile kernel if
necessary.

> Might well do. I wonder if there isn't some filtering on the network
> affecting the hello messages. Not that this should prevent you from
> setting up a connction with 1.1, it would only explain the lack of an
> automatically generated entry in the neighbour table.

Since I'm just toying around to see if I can get this working, getting
information about what filtering, if any, might be in place on the
switches may prove to be difficult to extract from the net admins.  It's
not that they're unreasonable people, but it's very difficult to get any
of their time.

> Could you send a tcpdump of the Linux box trying to connect to 1.1 ?
> The first thing to establish is whether 1.1 replies at all, and if it
> does, to find out whether its sending something unexpected. Make sure
> that you get a full hex dump of each packet as I don't trust tcpdump
> to decode the packets correctly,

Sure thing.

# tcpdump -s0 -x decnet host 1.20
tcpdump: listening on eth0
21:10:41.495812 1.20 > 1.1 50 conn-initiate 8213>0 ver 4.1 segsize 1450 
                         3200 8126 0000 aa00 0400 0104 0000 aa00
                         0400 1404 0000 0000 1800 0015 2001 03aa
                         0500 1902 0000 0000 0005 4c49 4e55 5803
                         0000 0000
21:10:43.489676 1.20 > 1.1 50 retrans-conn-initiate 8213>0 ver 4.1 segsize 1450 
                         3200 8126 0000 aa00 0400 0104 0000 aa00
                         0400 1404 0000 0000 6800 0015 2001 03aa
                         0500 1902 0000 0000 0005 4c49 4e55 5803
                         0000 0000
...

Then lots of "retrans-conn-initiate" identical to the second packet.  I
eventually ^C'd.

Thanks,
Ben
-- 
      Ben Armstrong                -.       Medianet Development Group,
      BAr...@dy...         `-.    Dymaxion Research Limited
      <URL: http://www.dymaxion.ca/>    `-  Halifax, Nova Scotia, Canada

Re: [Linux-decnet-user] Can only connect to three out of four of our VMS nodes

[Steven W. <st...@gw...>]

Hi,

> 
> Hi,
> 
> I am running Debian/unstable on a 2.4.20 kernel.  After resolving the
> problem described in sections 4.9 and 4.10 of the FAQ[0] by setting my
> default_device to eth0, I can now dnping or sethost to three out of four
> VMS nodes on our network.  I know at least two of these nodes run DECnet
> phase V.  I'm not sure about the other.
> 
> But I still cannot contact one DECnet phase V host on our network.  The
> symptom is that dnping or sethost will just hang and never connect.  No
> error messages are returned.  I need to ^C the client to regain control
> of the terminal.
>
Can you find out the OS and version of the problematic node?
 
> The host I cannot contact does appear in /proc/net/decnet_neigh after a
> failed dnping attempt, e.g.
> 
> $ cat /proc/net/decnet_neigh 
> Addr    Flags State Use Blksize Dev
> 1.1     ---   40    02  0000230 eth0    
                          ^^^^^^^ This set to the minimum size, which usually
                                  means this entry was added due to an outgoing
                                  route request, rather than an incoming hello
                                  message. i.e. No hello messages have been seen
                                  from this node.

> 1.3     ---   40    01  0001492 eth0    
> 1.4     ---   40    02  0001492 eth0    
> 1.20    ---   40    01  0001498 lo      
> 
> In the above listing, 1.1 is the host I cannot contact and 1.20 is the
> node from which I am attempting to make the connection.
> 
> I can use telnet or LAT (llogin) to connect to this host successfully,
> however the LAT connection sometimes drops, especially after displaying
> a lot of output at once (e.g. SHOW TERM fairly reliably causes the
> connection to drop).  LAT connections to other hosts don't drop.
>
Thats a bit odd I think. The LAT connection suggests that there is MAC
level connectivity between the two machines, which would normally
indicate that the Linux box should be getting hello messages too.

I have seen problems in the past with Phase V not sending regular enough
hello messages to keep an entry in the neighbour table. This can be fixed
by forcing the information into the table with iproute2.

[snip] 
> 
> I know there are a number of switches deployed in our building, but I am
> not familiar with how they are configured.  I am guessing that since all
> of the servers live in the machine room on the same bench, they all talk
> to the same switch, whereas my desktop Linux workstationm, which is in
> an adjacent room along with a few dozen other workstations could be
> connected via a different switch.  I wonder if the network topology has
> a bearing on my problem.
>
Might well do. I wonder if there isn't some filtering on the network
affecting the hello messages. Not that this should prevent you from
setting up a connction with 1.1, it would only explain the lack of an
automatically generated entry in the neighbour table.
 
> 
> Any pointers as to how to proceed with debugging this problem?
>
Could you send a tcpdump of the Linux box trying to connect to 1.1 ?
The first thing to establish is whether 1.1 replies at all, and if it
does, to find out whether its sending something unexpected. Make sure
that you get a full hex dump of each packet as I don't trust tcpdump
to decode the packets correctly,

Steve.

[Linux-decnet-user] Can only connect to three out of four of our VMS nodes

[Ben A. <be...@bg...>]

Hi,

I am running Debian/unstable on a 2.4.20 kernel.  After resolving the
problem described in sections 4.9 and 4.10 of the FAQ[0] by setting my
default_device to eth0, I can now dnping or sethost to three out of four
VMS nodes on our network.  I know at least two of these nodes run DECnet
phase V.  I'm not sure about the other.

But I still cannot contact one DECnet phase V host on our network.  The
symptom is that dnping or sethost will just hang and never connect.  No
error messages are returned.  I need to ^C the client to regain control
of the terminal.

The host I cannot contact does appear in /proc/net/decnet_neigh after a
failed dnping attempt, e.g.

$ cat /proc/net/decnet_neigh 
Addr    Flags State Use Blksize Dev
1.1     ---   40    02  0000230 eth0    
1.3     ---   40    01  0001492 eth0    
1.4     ---   40    02  0001492 eth0    
1.20    ---   40    01  0001498 lo      

In the above listing, 1.1 is the host I cannot contact and 1.20 is the
node from which I am attempting to make the connection.

I can use telnet or LAT (llogin) to connect to this host successfully,
however the LAT connection sometimes drops, especially after displaying
a lot of output at once (e.g. SHOW TERM fairly reliably causes the
connection to drop).  LAT connections to other hosts don't drop.

In all other respects, the network services offered by the host I cannot
contact seem fine.  For instance, I successfully use smbfs to mount
Pathworks shares off this system.  DECnet connections to/from this host
from other nodes on the network are operating properly too.

I know there are a number of switches deployed in our building, but I am
not familiar with how they are configured.  I am guessing that since all
of the servers live in the machine room on the same bench, they all talk
to the same switch, whereas my desktop Linux workstationm, which is in
an adjacent room along with a few dozen other workstations could be
connected via a different switch.  I wonder if the network topology has
a bearing on my problem.

If I turn on debugging and attempt to dnping the host as follows:

# echo -n '1' >/proc/sys/net/decnet/debug
# dnping SOMENODE 1

I see the following in /var/log/syslog

Feb 21 15:21:32 bgpc kernel: dn_route_rcv: got 0x0d from lo [34 34 0]
Feb 21 15:22:12 bgpc last message repeated 4 times

Any pointers as to how to proceed with debugging this problem?

Thanks,
Ben

[0] http://linux-decnet.sourceforge.net/faq-4.html#ss4.9
-- 
      Ben Armstrong                -.       Medianet Development Group,
      BAr...@dy...         `-.    Dymaxion Research Limited
      <URL: http://www.dymaxion.ca/>    `-  Halifax, Nova Scotia, Canada

Re: [Linux-decnet-user] lat RPM and simh

[Patrick C. <pa...@ty...>]

On Sat, Feb 08, 2003 at 03:53:48PM -0500, Gregg C Levine wrote:
> Hello from Gregg C Levine
> Patrick, can you elaborate on this? I am about to plunge into the fray,
> regarding Linux, and DECnet, and SIMH. And, naturally I need som advice. I
> can make my binaries for SIMH, without any problems, but its the networking
> configuration issues that drive me into the levels of frustration, and
> upset.
> 
> Are there any caveats that we need to know? And what operating sysrems were
> you running on your SIMH instance?

you need to build the emulators using "make USE_NETWORK=t" to enable networking
in the binaries - only pdp11 and vax work BTW.

I've successfully run VMS, netbsd (on VAX) and RSX11M with networking under
simh, you need to attach the device to a network card in the linux box with the
command "att xq eth0" - also, you need to run as root because it puts the card
into promiscuous mode. I'm not sure that there's a way around this, because of
the need to respond to various multicast addresses as well as the machine's
actual hardware address.

I've not been able to communicate between the host machine and the emulated one
but others seem fine

Here's some config files:

patrick

Re: [Linux-decnet-user] lat RPM and simh

[Gregg C L. <dr...@wo...>]

Hello from Gregg C Levine
Patrick, can you elaborate on this? I am about to plunge into the fray,
regarding Linux, and DECnet, and SIMH. And, naturally I need som advice. I
can make my binaries for SIMH, without any problems, but its the networking
configuration issues that drive me into the levels of frustration, and
upset.

Are there any caveats that we need to know? And what operating sysrems were
you running on your SIMH instance?

Gregg C Levine dr...@wo...
"Oh my!" The Second Doctor's nearly favorite phrase.
----- Original Message -----
From: "Patrick Caulfield" <pa...@ty...>
To: "DECnet list" <lin...@li...>
Sent: Thursday, January 23, 2003 4:15 AM
Subject: [Linux-decnet-user] lat RPM and simh


> The latd 1.16 Intel RPM is now uploaded. Sorry for the delay, I just
forgot.
>
> Incidentally the latest version of simh (V2.10-2) supports DECnet and
> clustering. (http://simh.trailing-edge.com)
>
> I've just set up a pair of simulated VAXes booting off a common system
> disk image which were also clustered with a real Alpha box via
> ethernet.
>
> You need to fool cluster_config to make it do this but it's not hard
> and it works a treat :-)
> --
>
> patrick
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Linux-decnet-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-decnet-user
>