nrparms: SIOCADDRT: Inappropriate ioctl for device

Question

I am learning about the Linux amateur radio protocol stack. I'm trying to connect to a remote node using netrom. My axports file looks like:

radio   N1LKS   9600    128     4       Primary RF link

My nrports file looks like:

# name  callsign        alias   paclen  description
nrnod   N1LKS-1 MYNOD  128     Netrom node port
nrbbs   N1LKS-2 MYBBS  128     Netrom bbs

Active interfaces look like:

14: ax0: <BROADCAST,UP,LOWER_UP> mtu 128 qdisc pfifo_fast state UNKNOWN group default qlen 10
    link/ax25 N1LKS-0 brd QST-0 permaddr LINUX-1
15: nr0: <NOARP,UP,LOWER_UP> mtu 128 qdisc noqueue state UNKNOWN group default qlen 1000
    link/netrom N1LKS-1 brd *
16: nr1: <NOARP,UP,LOWER_UP> mtu 128 qdisc noqueue state UNKNOWN group default qlen 1000
    link/netrom N1LKS-2 brd *
17: nr2: <NOARP> mtu 236 qdisc noop state DOWN group default qlen 1000
    link/netrom * brd *
18: nr3: <NOARP> mtu 236 qdisc noop state DOWN group default qlen 1000
    link/netrom * brd *

I want to connect using netrom to a node identified by the alias FOONOD associated with callsign K1ABC-3 (callsigns changed for the purpose of this question). If I just run:

axcall nrnod FOONOD

or:

axcall nrnod K1ABC-3

I get:

call: NET/ROM callsign or alias not found

...which is expected, I guess, since there are no routes yet. I tried adding a node using nrparms like this:`

nrparms -nodes K1ABC-3 + FOONOD 192 6 radio K1ABC-3

Which fails with:

nrparms: SIOCADDRT: Inappropriate ioctl for device

What's wrong with this command and why is it failing?

Answer 1

Looking at the kernel code, I see four things that can make an "add node" ioctl on a netrom socket return -EINVAL:

1. The route has more than 8 digipeaters. Doesn't look like this is the case, and nrparms would refuse a too-long route before it submitted it to the kernel anyway.

2. The alias given is more than 7 characters. Again, nope, and again, nrparms would error before the kernel got a chance to see it.

3. The port name specified for the route somehow resolves to a network interface that doesn't exist, isn't an ax25 device, or isn't up. This doesn't seem like it's the case, but maybe it could be if you did something weird like edit axports after kissattach was started? The easiest way to debug this is probably to reboot and start from scratch.

4. The destination callsign of the route is a callsign that's configured on the local machine. This is conceivable, depending on your "callsigns changed to protect the innocent".