Search This Blog

Sunday, September 24, 2017

The DECnet-Linux Experience: It Works!

Supratim Sanyal's Blog: DECnet Linux Communication Between two Linux nodes
Ubuntu 14.04 Linux Twins FEDACH (1.553) and FOMFOR (1.554) Talk over DECnet
I was aware of an implementation of the DECnet Phase IV network protocol on the Linux kernel for quite a while now, and recently decided to take the plunge and give it a shot, with additional motivation from this inspiring Retrocomp post.

It was not going well initially because of a bad call I made to try to install ancient releases of Linux distributions from Debian and Fedora from around the time DECnet-Linux was first announced. As a result, I spent many sleepless nights trying to find the packages and dependencies for Linux distros featuring DECnet from the first few years of the new millennium.

Eventually I did what I should have started off with: check if modern Linux distributions still include DECnet-Linux. A search of the kernel of the bleeding-edge Ubuntu 17 "Zesty Zapus" looked promising; DECnet-Linux was indeed compiled right intoUbuntu 17's mainline 4.10 kernel build and the required libdnet, dnet-common and dnprogs packages were available for Ubuntu 17.

Unfortunately, Ubuntu 17's support for DECnet-Linux turned out to be dysfunctional. I created two virtual machines with Ubuntu 17 and installed the DECnet tools, but could not get any farther than the dneigh command showing the other node. FAL, Phone, sethost, etc. would simply not work and would sometimes lock up the virtual machines.

Frustrated, I posted the question to the fabulous folks at the comp.os.vms newgroup. Within a day, I had a path forward; it was clear from John E. Malmberg and "hb" that I needed to try Ubuntu 14.04 or earlier; DECnet-Linux was definitely broken after Ubuntu 14.04.

Re-energized, I proceeded to install the 32-bit release of Ubuntu 14.04.5 LTS (Trusty Tahr) on two virtual machines using the lightweight lubuntu flavor from the Desktop ISO CD image. Then apt-get install dnprogs brought in everything I needed to get DECnet-linux mostly up (the official Ubuntu 14 repositories still work at the time of writing, no need to look for mysterious archives of no-longer supported releases yet.)

However, I still had to make a couple of little tweaks to have DECnet-Linux work all the way. Here are the things I did over and after the default install of DECnet-Linux from Ubuntu 14.04 repositories.

1. The official dnprogs and family of packages from Ubuntu 14.04 repos installed versions of /usr/sbin/dnetnml and /usr/sbin/ctermd that did not work well. The dnetnml program was not responding correctly by showing executor, line, or circuit etc. characteristics when requested by other nodes. Also, attempts to SET HOST from other nodes resulted in the official ctermd program to look for a non-existent local "pty" device and fail.

To get around these problems, I downloaded the source code tarball dnprogs_2.62.tar.gz which is available in practically all Ubuntu 14 mirrors including here. I then built the entire DECnet program suite locally, and then replaced the /usr/sbin/dnetnml and /usr/sbin/ctermd binaries with the ones built locally from source.

2. The official dnprogs installation was not filling in the correct DECnet address in the file /proc/sys/net/decnet/node_address; this file always had 0.0 despite the correct DECnet executor address being defined in the /etc/decnet.conf configuration file. This was resulting in some strange behavior indicatng Linux-DECnet was not using the adjacent router node to reach nodes outside the local network, but trying to access them directly and failing. I added a simple command in the /etc/rc.local file (and made it executable and exit with 0) to force the correct DECnet address:
# -- rc.local DECnet kludge - /proc/sys/net/decnet/node_address has 0.0; force it
echo 1.554 > /proc/sys/net/decnet/node_address
# --

My two Ubuntu 14.04 virtual machines are named FEDACH and FOMFOR after the twin sons of Macha, daughter of Aodh Ruad. FEDACH has a DECnet address of 1.553 and FOMFOR has 1.554. They are now both connected to HECnet - the global hobbyist DECnet. They are configured to use DECnet on the eth1 network adapter (eth0 is dedicated to IP); the eth1 adapter has the correct MAC address corresponding to the DECnet address as required by DECnet:

1.553 => aa:00:04:00:29:06
1.554 => aa:00:04:00:2a:06

Also, as DECnet uses all available NICs by default, I modified /etc/default/decnet to have DECnet on eth1 only, and increase verbosity of logging by the dnetd daemon. In addition, I modified the /etc/decnet.conf and /etc/decnet.proxy files as recommended by DECnet-linux documentation and man pages. Here is the output of "ip address show" for eth1 on the two nodes:


3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether aa:00:04:00:29:06 brd ff:ff:ff:ff:ff:ff
    dnet 1.553 peer 1.553/16 scope global eth1


3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether aa:00:04:00:2a:06 brd ff:ff:ff:ff:ff:ff
    dnet 1.554 peer 1.554/16 scope global eth1

Lastly, I created a "decnet" user account for FAL etc. to use by default as configured in /etc/decnet.proxy. Interactive logins are disabled for this "decnet" account.

Usual DECnet network access commands all work from an external OpenVMS VAX 7.3 Node:


Node Volatile Characteristics as of 25-SEP-2017 00:32:23

Executor node = 1.553 (FEDACH)

Circuit                  = eth1
State                    = on
Identification           = DECnet for Linux V3.13.0-129-generic on i686




Total of 3 files.
CTERM Version 1.0.6
DECnet for Linux

fedach login:


The DECnet-Linux configuration files for my two nodes along with the Ubuntu 14 CD ISO and dnprogs_2.62.tar.gz source files and binaries built on my nodes are available from my google drive here.


/etc/dnetd.conf (Identical for FEDACH and FOMFOR)

/etc/decnet.proxy (Identical for FEDACH and FOMFOR)

/etc/default/decnet (Identical for FEDACH and FOMFOR)

/etc/decnet.conf (FEDACH)

/etc/decnet.conf (FOMFOR)


Tuesday, September 12, 2017

DECnet Phase IV: copy node database from remote host and share it with other nodes over network with Digital DEC servers

Figure: Phase IV Consists of Eight Layers That Map to the OSI Layers
Source - Cisco Wiki | Figure: Phase IV Consists of Eight Layers That Map to the OSI Layers

DECnet Phase IV on OpenVMS VAX 7.3

To copy the nodes database from a remote host and make it available to other nodes to copy from my node, I use the command file at the bottom. Here <REMOTE-NODE> is the DECnet node name / address of the host I copy my node database from.

After copying over the remote node database from another server (a PDP-11/24 running RSX-11M Plus that serves HECnet the world-wide hobbyist DECnet in this case), I basically copy SYS$SYSTEM:NETNODE_LOCAL.DAT and SYS$SYSTEM:NETNODE_REMOTE.DAT to SYS$COMMON:[SYSEXE] and grant them world-read permission.

Before doing this, other nodes that tried to copy the node database from my node (1.559) used to get this error, which does not happen any more:
Known Node Permanent Summary as of 12-SEP-2017 18:29:00
%NCP-W-FILOPE, File open error , Permanent database
-RMS-E-FNF, file not found

I also played around with enabling the NML proxy before running the commands in the DCL command file at bottom. I am not sure if I had enabled the NML proxy during installation of DECnet Phase IV and if these were required, but just doing these did not solve the problem. They may be required part of the solution, though.


Here is the DCL script:

$ MC NCP copy known nodes from <REMOTE-NODE> using volatile to BOTH

Saturday, September 9, 2017

From Supernova to Intel Xeon L2 CPU Cache: My Own Machine Check Event (MCE) Glitch!

Supratim Sanyal's Blog: A Supernova Causes a MCE Machine Check Event on Intel Processor
Less than thirteen and a three-quarters of a billion years ago, a star the size of about fifteen times our own sun ran out of hydrogen fuel in its core to burn into helium.

Undeterred and left with prodigious amounts of helium, it non-nonchalantly started on the helium to burn to carbon for a few billion years. Then it lit up the carbon, and spent billions of years to continue up the periodic table - aluminum, silicon, nickel, copper, lead ... all the while pushing the lighter stuff outwards in layers and getting heavier in the middle where gravity kept getting happier. In another few billion years, gravity betrayed a little smile when the star crossed over the Chandrasekhar Limit. For gravity had won again, as it always does; all the energy of the burning core could no longer hold the star up. The collapse started.

The unrelenting crush of gravity then continued to make that star's core so dense and so hot that, more importantly than human equations trying to compute it starting to fail, something had to give.

After billions of years of cooking the elements, it took barely one and a half minutes for the core to explode, lighting up the universe with such brightness that it would be clearly visible to naked human eyes in daytime when that light would reach planet Earth.

The supernova explosion scattered the periodic table into space. Some of that ejected matter coagulated into a scary collection of mostly hydrogen and carbon-based molecules which would be labeled together as "Supratim Sanyal". 

The explosion also fired off, at light speed in all directions, billions of little monsters - atomic nuclei with no electrons, alpha particles, electrons and friends. One of these - a hydrogen nucleus, which is just a proton, traveled unchallenged a few billion light years only to finally get arrested by the L2 cache of the 8th Xeon CPU in my Dell PowerEdge 2950 in the basement.

Supratim Sanyal's Blog: Machine Check Event (MCE) Error - Intel Xeon L2 Cache Error
Machine Check Event (MCE)
I have never faced a Machine Check Event before.

I logged into my old faithful and rock-solid Dell PowerEdge 2950 blade server just now, and was informed:

ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1504666020

Okay, so I ran the recommended command, and got:

# abrt-cli list --since 1504666020
id ea6720f12a431197ca717b7bcd90f43f7a92d366
reason:         mce: [Hardware Error]: Machine check events logged
time:           Thu 07 Sep 2017 07:28:16 PM UTC
cmdline:        BOOT_IMAGE=/vmlinuz-3.10.0-514.26.2.el7.x86_64 root=/dev/mapper/centos_dellpoweredge2950-root ro rhgb quiet LANG=en_US.UTF-8
package:        kernel
uid:            0 (root)
count:          1
Directory:      /var/spool/abrt/oops-2017-09-07-19:28:16-12996-0
Reported:       cannot be reported

The Autoreporting feature is disabled. Please consider enabling it by issuing
'abrt-auto-reporting enabled' as a user with root privileges

At this point, I googled "Machine Check Event" and learned that one of the reasons a MCE could happen is cosmic rays! Unless, of course, the processor or hardware or bus or some such thing is really going bad; the PowerEdge 2950 is a decade old anyway.

The forums also recommended running "mcelog", which I did not have, but was readily available in the repos.

# yum install mcelog

Now I could run mcelog.

# mcelog
Hardware event. This is not a software error.
ADDR 43f883580
TIME 1504812495 Thu Sep  7 19:28:15 2017
MCG status:
MCi status:
Corrected error
Error enabled
MCi_ADDR register valid
Threshold based error status: green
MCA: Generic CACHE Level-2 Generic Error
STATUS 942000570001010a MCGSTATUS 0
CPUID Vendor Intel Family 6 Model 23

OK, so it clearly says this MCE is not software-related, and whatever it was, it was corrected. It is also probably trying to say the L2 cache on the 8th CPU misfired that time.

A few quick checks with htop, top, iotop, etc. do not indicate any issues. Therefore, I will blame it on cosmic rays this time and let it go. If hardware is indeed failing, I will know soon enough.

It may be worth keeping an eye on eBay for a replacement blade server.

Thursday, September 7, 2017

OpenVMS-Linux-Windows File-Sharing over DECnet using FAL on DEC Pathworks for Windows NT 4.0

Supratim Sanyal's Blog: DEC Pathworks DECnet on Windows NT 4.0 Hobbyist System at SANYALnet Labs
DEC Pathworks: Windows NT as a DECnet node

Thanks to DECnet-Linux on my Ubuntu 14 boxes, DECnet on OpenVMS on a couple of SIMH VAX servers and DECnet on RSX-11M PLUS on a SIMH PDP-11/24 server, it is eminently possible to kick the Internet Protocol (IP) completely off a local LAN and use DECnet for logging in and sharing files across these machines. Windows was the missing piece, and I decided to throw an Windows NT 4.0 server into the mix. I could have chosen Windows 2000, XP, or later - but there is a certain charm in NT4 service-pack 6a + post 6a security rollup - a charm only felt by folks dated to the 8-bit era like me.

The saga of sharing files over DECnet from Windows NT 4.0 starts after I had DEC Pathworks 32 v7.4 up and running on my NT 4.0 workstation. At this point, ENTEE4 (DECnet address 1.557) is happily talking DECnet with two other nodes around my lab, as validated using tshark sniffing on the DECnet-dedicated network from Ubuntu 14 boxes equipped with DECnet-Linux (DECnet addresses 1.553 and 1.554). Everybody is saying hello to everyone else and it is a happy little island world.

$ tshark -i eth1
Capturing on 'eth1'
1930  39.386556        1.554 -> 1.553        DEC DNA 59 msg nr. 2 single segment, bytes this segment: 10, total so far:10
1931  39.386874        1.553 -> 1.554        DEC DNA 60 NSP data ACK message(2)
1932  39.386937        1.554 -> 1.553        DEC DNA 62 msg nr. 3 single segment, bytes this segment: 13, total so far:13
1933  39.387199        1.553 -> 1.554        DEC DNA 60 NSP data ACK message(3)
1934  39.388100        1.554 -> 1.553        DEC DNA 160 msg nr. 4 single segment, bytes this segment: 111, total so far:111
1935  39.388388        1.553 -> 1.554        DEC DNA 60 NSP data ACK message(4)
1936  39.388661        1.553 -> 1.554        DEC DNA 60 NSP disconnect initiate/confirm message
1937  39.388667        1.554 -> 1.553        DEC DNA 45 NSP disconnect initiate/confirm message
1938  39.389347        1.554 -> 1.553        DEC DNA 45 NSP disconnect initiate/confirm message
1939  39.403927        1.553 -> 1.557        DEC DNA 85 NSP connect confirm/initiate message
1940  39.404130        1.557 -> 1.553        DEC DNA 60 NSP connect acknowledgement
1941  39.460844        1.557 -> 1.553        DEC DNA 60 NSP connect confirm/initiate message
1942  39.460988        1.553 -> 1.557        DEC DNA 60 NSP link control message(no change)
1943  39.461152        1.557 -> 1.553        DEC DNA 60 NSP link control message(no change)
1944  39.461156        1.557 -> 1.553        DEC DNA 60 NSP other data ACK message
1945  39.461305        1.553 -> 1.557        DEC DNA 60 NSP other data ACK message
1946  39.461562        1.553 -> 1.557        DEC DNA 66 msg nr. 1 single segment, bytes this segment: 17, total so far:17
1947  39.461566        1.557 -> 1.553        DEC DNA 60 NSP data ACK message(1)
1948  39.462705        1.557 -> 1.553        DEC DNA 64 msg nr. 1 single segment, bytes this segment: 20, total so far:20
1949  39.462725        1.553 -> 1.557        DEC DNA 60 NSP data ACK message(1)
1950  39.462727        1.553 -> 1.557        DEC DNA 64 msg nr. 2 single segment, bytes this segment: 15, total so far:15
1951  39.462728        1.557 -> 1.553        DEC DNA 60 NSP data ACK message(2)
1952  39.492906        1.557 -> 1.553        DEC DNA 1494 msg nr. 2: start of segment, bytes this segment: 1450, total so far:1450
1953  39.492919        1.557 -> 1.553        DEC DNA 1494 msg nr. 3: continuation segment , bytes this segment: 1450, total so far:2900
1954  39.492922        1.557 -> 1.553        DEC DNA 1494 msg nr. 4: continuation segment , bytes this segment: 1450, total so far:4350
1955  39.492941        1.553 -> 1.557        DEC DNA 60 NSP data ACK message(2)
1956  39.492943        1.553 -> 1.557        DEC DNA 60 NSP data ACK message(3)
1957  39.492944        1.553 -> 1.557        DEC DNA 60 NSP data ACK message(4)
1958  39.493239        1.557 -> 1.553        DEC DNA 1494 msg nr. 5: continuation segment , bytes this segment: 1450, total so far:5800
1959  39.493242        1.557 -> 1.553        DEC DNA 1494 msg nr. 6: continuation segment , bytes this segment: 1450, total so far:7250
1960  39.493251        1.557 -> 1.553        DEC DNA 933 msg nr. 7: end of segment, bytes this segment: 889, total so far:8139
1961  39.493254        1.553 -> 1.557        DEC DNA 60 NSP data ACK message(5)
1962  39.493261        1.553 -> 1.557        DEC DNA 60 NSP data ACK message(6)
1963  39.493271        1.553 -> 1.557        DEC DNA 60 NSP data ACK message(7)
1964  39.494324        1.553 -> 1.557        DEC DNA 60 NSP disconnect initiate/confirm message
1965  39.494363        1.557 -> 1.553        DEC DNA 60 NSP disconnect initiate/confirm message
1966  39.999976        1.554 -> DECNET-Phase-IV-end-node-Hello-packets DEC DNA 50 Routing control, Endnode Hello message

Before starting FAL configuration, the two sources of information that I found extremely useful, and where all the information in this post is gleaned from, are

  • Pathworks Installation Guide (still available from Compaq here)
  • Pathworks Information Shelf installed along with Pathworks application files

Now, to get Pathworks FAL operational. First, using the Windows NT User Rights Policy manager, I added the "Log on as a batch job" right to the "Users" group. This is fairly well documented in the Pathworks installation guide. The steps are:

Supratim Sanyal's Blog: DEC Pathworks DECnet FAL configuration - Add "Log on as a batch job" right to "Users" group on Microsoft Windows NT 4.0
Add "Log on as a batch job" right to "Users" group on Microsoft Windows NT 4.0

  • Start -> Programs -> Administrative Tools -> User Manager
  • From the menu bar at top of User Manager, choose Policies -> User Rights. This will pop up a "User Rights Policy" window.
  • Click on the little checkbox at the bottom saying "Show Advanced User Rights"
  • From the "Right" drop-down list in the upper area, choose "Log on as a batch job"
  • Click "Add..." in the bottom right area. This will pop up another window titled "Add users and groups".
  • Choose "Users" in the "Names" area at the top (scroll down to see "Users").
  • Click on "Add" button in the middle. This will add "<computer-name>\Users" in the white text area in the bottom half.
  • Click "OK" at the bottom.
  • You will back at the "User rights policy" window. Click OK.
  • You will be back at the "User Manager" window. From the top menu, click User -> Exit to exit out.

Second step - I created a user called DECNET with home directory C:\DECNET and added this user to the "Users" group that we manipulated previously. The DECNET user thus has the all-important "Log on as a batch job" right.

Supratim Sanyal's Blog: DECnet Windows NT 4.0 Pathworks Setup - Add a DECNET user for Windows NT 4.0 for testing with DEC Pathworks DECnet services
Add a DECNET user for Windows NT 4.0 for testing with DEC Pathworks DECnet services

  • Start -> Programs -> Administrative Tools -> User Manager
  • From the menu bar at top of User Manager, choose "New User...". This will pop up a "New User" window. Fill in the username (DECNET), provide a password that you can remember, and clear all four check-boxes.
  • Click on "Groups" at the bottom. In the "Group Memberships" window that pops up, the user should already be a member of the "Users" group; therefore no more action here. Click on OK to return to the "New User" window.
  • Click on "Profile" at the bottom to open up the "User Environment Profile" pop-up. In the "Home Directory" section in the lower panel, change "Local Path" to "C:\DECNET". Click on OK to return to the "New User" window, and OK again.
  • You will be back at the "User Manager" window. From the top menu, click User -> Exit to exit out.
Third step - grant Administrator access to the user directory. In the prior step, the User Manager created the home directory with access permissions only for the specific user. However, for the FAL object to access the contents of the directory, we need the directory permissions set to allow full Administrator access. This is performed from an Administrator account as follows:

Supratim Sanyal's Blog: DEC Pathworks Windows NT 4.0 FAL server configuration - Give Administrators Full Control on the new home directory for the DECNET user account
Give Administrators Full Control on the new home directory for the DECNET user account

  • From Start -> Windows NT Explorer, Right-Click on the DECNET folder under C: drive.
  • Choose Properties
  • Click on the Security tab
  • Click on Permissions
  • Click on "Add" at the bottom
  • In the "Add Users and Groups" window,  choose "Administrators" in the "Names" area at the top half, and click "Add" in the middle. This will add "<computer name>\Administrators" to the "Add Names" area in the bottom half.
  • In the "Type of Access" drop-down list at the bottom, choose "Full Control"
  • Click on OK, OK and OK to exit out of the three open screens.
  • That's it; now the C:\DECNET folder has full access permissions for both the owner DECNET as well as Administrator group accounts.

Fourth step - configure FAL and NML services on Windows NT 4.0 Pathworks using Network Control Program (NCP). To do this, open a MS-DOS command prompt and issue the command "NCP" to enter the NCP prompt. Then issue NCP commands to define the File Access Listener (FAL) and the Network Management Listener (NML) objects. Keep in mind the object numbers 17 and 19 cannot be changed; they are specifically allocated to FAL and NML objects.

Supratim Sanyal's Blog: DEC Pathworks Windows NT - Configure FAL and NML server objects from NCP - DECnet
DEC Pathworks Windows NT - Configure FAL and NML server objects from NCP


Network Control Program (NCP)   V7.2.019
Copyright 1985, 2000 by Compaq Computer Corporation

 Network Objects  Thu Sep 07 15:52:48 2017

Taskname          #    File               "Arguments"

FAL               17   C:\PW32\FAL32.EXE
NML               19   C:\PW32\NML32.EXE

Log out of the Windows Administrator account, and log in as DECNET. Create a file called INFO.TXT in C:\DECNET to play (i.e. test) with.

All done, now we can talk to Windows NT 4.0 running Pathworks from other DECnet hosts. It all works from DECnet on OpenVMS and PDP-11/24 hosts in my hobbyist lab, and also playing around with my Ubuntu boxes running DECnet-Linux, I can use DECnet-Linux commands to access Windows NT files:

$ dndir 'entee4"DECNET password"::'

Directory of C:[DECNET]


$ dntype -mblock 'entee4"decnet password"::info.txt'
 _______   ________   _________  _______   _______   ___   ___
|\  ___ \ |\   ___  \|\___   ___\\  ___ \ |\  ___ \ |\  \ |\  \
\ \   __/|\ \  \\ \  \|___ \  \_\ \   __/|\ \   __/|\ \  \\_\  \
 \ \  \_|/_\ \  \\ \  \   \ \  \ \ \  \_|/_\ \  \_|/_\ \______  \
  \ \  \_|\ \ \  \\ \  \   \ \  \ \ \  \_|\ \ \  \_|\ \|_____|\  \
   \ \_______\ \__\\ \__\   \ \__\ \ \_______\ \_______\     \ \__\
    \|_______|\|__| \|__|    \|__|  \|_______|\|_______|      \|__|

                   A SANYALnet LABS HOBBYIST SERVER

| Welcome to entee4.sanyalnet.lan.
| This is a Microsoft Windows NT 4.0 Workstation with
| Digital DEC (Compaq) Pathworks. It speaks IP and DECnet.

That concludes my experiment with a DECNET account shared using FAL server object over DECnet on a Windows NT 4.0 server running DEC Pathworks 32. Please share your experiments and results in the comments below!

Tuesday, August 15, 2017

iptables adventures

Supratim Sanyal's Blog: Linux iptables security reference example

I use iptables to secure my Linux-based internet-facing hobbyist servers. The current iptables, residing at one of these servers ( at /etc/sysconfig/iptables, is as below.

This particular server runs on CentOS 7. The iptables rules provide basic network exploit protection from syn flood, nul, christmas and fragmented packets and adds rate-limited DDOS flood protection for ssh, telnet, smtp, dns, http, pop3, ntp, IMAP, https, smtps, starttls, imap-ssl/tls, pop-ssl/tls, dovecot, sieve, managesieve, DECnet bridge (HECnet), stunnel, syslog etc. ports that are usual for any internet-facing server providing public services. It has the following open ports for the services it provides:
  • ssh
  • telnet, forwarded to CLOUDY VAX - the hosted DECVAX-11/780 SIMH simulated Digital VAX server running OpenVMS 7.3
  • SMTP (authenticated, not public)
  • DNS - this DNS server blocks advertising and tracking websites as well as malware
  • http - a basic static web-site is hosted on this server; also reachable over the TOR network at fz2koi5kviaph4bl.onion)
  • POP (authenticated, not public)
  • NTP - this server is an official stratum-2 public NTP server listed and is a member of the NTP Pool Project
  • IMAP (authenticated, not public)
  • https (currently unused)
  • STARTTLS / SMTPS (authenticated, not public)
  • IMAP SSL/TLS (authenticated, not public)
  • POP SSL/TLS (authenticated, not public)
  • Dovecot Sieve / ManageSieve
  • DECnet bridge connecting QCOCAL (SIMH MicroVAX 3900/OpenVMS 7.3 at home), JUICHI (SIMH DEC PDP-11/24 RSX-11M PLUS at home) and CLOUDY VAX (SIMH VAX-11/780 OpenVMS 7.3) to HECnet the global hobbyist DECnet network
  • TOR Proxy service (authenticated, not public)
  • stunnel (secure tunnel) service to syslog daemon for encrypted remote logging
  • syslog
  • TOR relay node (this server is a TOR relay-only node, not a TOR exit node; no TOR traffic is logged at all on this server)

Sunday, August 13, 2017

How to find Solaris device name of NTFS partition on external USB hard drive HDD storage

Instead of running GParted as described in my post on Oracle Solaris 11.3 64-bit installation steps, here is a quicker command-line way to identify the device name corresponding to a NTFS partition on an external USB hard drive connected to a Oracle Solaris 11.3 system.

Unlike my previous post that applies to OpenIndiana, this post applies to true Oracle Solaris 11.3 64 bit.

STEP 1 - Use rmformat and fdisk to identify the device name for the NTFS partition

$ rmformat -l
Looking for devices...
     1. Logical Node: /dev/rdsk/c1t1d0p0
        Physical Node: /pci@0,0/pci-ide@1,1/ide@0/sd@1,0
        Connected Device: VBOX     CD-ROM           1.0
        Device Type: <Unknown>
        Bus: IDE
        Size: <Unknown>
        Label: <Unknown>
        Access permissions: <Unknown>
     2. Logical Node: /dev/rdsk/c2t0d0p0
        Physical Node: /pci@0,0/pci106b,3f@6/storage@1/disk@0,0
        Connected Device: WD       My Book 1110     1030
        Device Type: Removable
        Bus: USB
        Size: 1430.1 GB
        Label: <Unknown>
        Access permissions: <Unknown>
     3. Logical Node: /dev/rdsk/c2t0d1p0
        Physical Node: /pci@0,0/pci106b,3f@6/storage@1/disk@0,1
        Connected Device: WD       Virtual CD 1110  1030
        Device Type: CD Reader
        Bus: USB
        Size: 668.0 MB
        Label: <None>
        Access permissions: <Unknown>
$ sudo fdisk /dev/rdsk/c2t0d0p0
             Total disk size is 60771 cylinders
             Cylinder size is 48195 (512 byte) blocks

      Partition   Status    Type          Start   End   Length    %
      =========   ======    ============  =====   ===   ======   ===
          1                 IFS: NTFS         0  60771    60772    100

   1. Create a partition
   2. Specify the active partition
   3. Delete a partition
   4. Change between Solaris and Solaris2 Partition IDs
   5. Edit/View extended partitions
   6. Exit (update disk configuration and exit)
   7. Cancel (exit without updating disk configuration)
Enter Selection: 7

This tells us the NTFS partition is the first partition on raw device /dev/rdsk/c2t0d0p0. Therefore, the device name for our NTFS partition will be disk partition /dev/dsk/c2t0d0p1 (without the "r" for raw device under /dev).

STEP 2 - Mount it!

$ mkdir /media/USB-Storage
$ sudo /usr/bin/lowntfs-3g -o uid=21,gid=21 /dev/dsk/c2t0d0p1 /media/USB-Storage/

And presto, we can now see the NTFS partition files at /media/USB-Storage.

Installing ntfs-3g on Solaris without introducing instability and kernel panics is tricky. I ended up building ntfs-3g from sources to get a rock-solid stable Oracle Solaris 11.3 server with NTFS-3g; I have documented my approach in a separate post in the section Install the Tools to Mount NTFS Volume: FUSE and NTFS-3G for Solaris 11.

Thursday, August 10, 2017

My tshark cheat-sheet

Supratim Sanyal's Blog: Wireshark

Ever-evolving list of tshark command lines I use for various purposes, with a goal of avoiding trolling through wireshark and tcpdump man pages every time to find the filters. Generally adding a -V, -VV or -VVV switch increases verbosity levels. I also usually prepend the tshark command with nice -n 19 ionice -c3 to try to minimize processor (CPU) and disk I/O usage when running tshark.

  • Monitor DECnet-UDP bridged traffic to HECnet. The following is for the VPS hosting CLOUDY:: and JUICHI:: which bridges DECnet over UDP to HECnet update host and QCOCAL:: hosted on (described in my post here):
    # tshark -i ens33 -f "host" -f "host" -f "udp port 4711" -f "udp port 4712"
  • Capture all NTP traffic:
    # tshark -i ens33 -f "udp port 123"
  • Capture all NTP server traffic. This mostly logs NTP time served by this server to other hosts.
    # tshark -i ens33 -f "udp port 123" | grep "server"
  • To capture all NTP traffic for this host serving time to other hosts, grep like follows:
    # tshark -i ens33 -f "udp port 123" | egrep " ->" | grep server
  • Capture all NTP client traffic. This mostly logs NTP traffic that synchronizes this host from remote clock source hosts.
    # tshark -i ens33 -f "udp port 123" | grep "client"
  • Capture all traffic to SanyalCraft Minecraft server (on port 25565) and our experimental Minecraft server on port 25566:
    # tshark -i ens33 -f "tcp port 25565" -f "tcp port 25566" 

Recommended Products from Amazon