> On Mar 9, 2020, at 12:47 PM, Mark J. Blair <nf6x at nf6x.net> wrote:
>
> I made good progress yesterday on updating my home network setup. I changed my home router/NAT/DHCP/DNS box from FreeBSD to Debian 10.3 "Buster" for various reasons. It's routing and NATing and DHCPing and DNSing, and a simh VAX-11/785 running OpenVMS 7.3 on it can talk DECnet phase IV to another simh VAX-11/785 running on a BeagleBone Green (a small single-board computer) on my LAN. The emulation running on the router connects to a tap device, which is bridged to the physical ethernet interface for my LAN.
>
> I've started trying to figure out how to run PyDECnet on the same router, connected to another bridged tap. I haven't figured it out yet. My config file looks like this:
>
> # DOGRTR config file for PyDECnet
> circuit tap-0 Ethernet tap:/dev/net/tap0
> routing 1.42 --type l1router
> node 1.42 DOGRTR
> node @nodenames.dat
> system --identification "DOGRTR PyDECnet Router"
>
> and the output when I launch it is:
>
> 2020-03-09 09:43:26.278: MainThread: Starting DECnet/Python DECnet/Python V1.0-487
> 2020-03-09 09:43:27.098: DOGRTR: No hardware address for Ethernet TAP-0
> 2020-03-09 09:43:27.099: DOGRTR: Event type 2.0, Local node state change
> From node 1.42 (DOGRTR), occurred 09-Mar-2020 09:43:27.099
> Reason = Operator command
> Old state = Off
> New state = On
>
> Does that look right?
I haven't used TAP in ages; when I need bridging I use Johnny's bridge. But the message ("No hardware address") means that PyDECnet tried to find out the MAC address for the interface you mentioned and could not do so. You can avoid that by specifying an address explicitly.
> I've also tried the HTTP server, with this config:
>
> # DOGRTR config file for PyDECnet
> circuit tap-0 Ethernet tap:/dev/net/tap0
> node 1.42 DOGRTR
> node @nodenames.dat
> system --identification "DOGRTR PyDECnet Router"
> http --https-port 0
>
> When I connect to the web server, I get this console output:
>
> 2020-03-09 09:45:22.344: MainThread: Starting DECnet/Python DECnet/Python V1.0-487
> 2020-03-09 09:45:38.533: Thread-1: Exception handling http GET of /
> Traceback (most recent call last):
> File "/usr/local/lib/python3.7/dist-packages/decnet-1.0-py3.7.egg/decnet/http.py", line 192, in do_GET
> nodeidx, tnode, parts = self.findnode ()
> File "/usr/local/lib/python3.7/dist-packages/decnet-1.0-py3.7.egg/decnet/http.py", line 174, in findnode
> return 0, nodelist[0], parts
> IndexError: list index out of range
>
> and this error in my browser:
>
> Error response
>
> Error code: 500
>
> Message: Internal Server Error.
>
> Error code explanation: 500 - Exception during server processing.<p><pre>Traceback (most recent call last): File "/usr/local/lib/python3.7/dist-packages/decnet-1.0-py3.7.egg/decnet/http.py", line 192, in do_GET nodeidx, tnode, parts = self.findnode () File "/usr/local/lib/python3.7/dist-packages/decnet-1.0-py3.7.egg/decnet/http.py", line 174, in findnode return 0, nodelist[0], parts IndexError: list index out of range </pre>.
The error handling clearly is bad here. The issue is that you're using an old config file pattern that is no longer valid. I think I contributed to this by not cleaning up old config examples until recently.
Some time ago I introduced the ability for a single PyDECnet process to run multiple DECnet nodes (systems), and for that matter bridges as well. This is done by using a config file per system. In the process, I didn't want HTTP access to be per node, so I pulled it into a separate part of the process. The way it works (see doc/config.txt) is that you may have several config files, and each contains an element that says what sort of thing it defines. Quoting config.txt:
Each top level config file defines either a
DECnet node (instance of "routing"), an Ethernet bridge, or the HTTP
access feature. So each config file must contain either a "routing",
a "bridge", or an "http" component -- one but not more than one of
these.
So what happened is that you started PyDECnet with an HTTP server but without nodes or bridges, so it has nothing to talk about. The config lines "circuit" and "node" and "system" are not relevant to the case of configuring the HTTP server so they were ignored.
The bad error handling is that PyDECnet should complain if you didn't define at least one node or bridge. It would be nice if it also rejected lines that aren't relevant (such as circuit definitions in an HTTP server config file) but that's tricky because there isn't any order requirement for the config lines. In the example you gave, the type of config (http) isn't given until the last line.
paul