TCP/IP

Redirection of stdout to remote TCP, UDP or IP destinations:

Although not strictly limited to ax25 tcp/ip (it will work anywhere tcp/ip/udp will), this can at times be useful for odd jobs, usually pertaining to one-way datafeeds. The only place I have seen remote redirection documented is an obscure reference to it in the vast work that we know as the bash (1) manpage.

Synopsis: /dev/tcp/host/port /dev/udp/host/port /dev/ip/host/protocol (since at least kernel 2.2.x, maybe earlier)

TCP Example:

some-command parm1 parm2 > /dev/tcp/12.34.56.78/1234

will collect the redirectable stdout from the command, and open a tcp connection to the remote address 12.34.56.78 and port 1234, and deliver the redirected output to whatever process happens to be listening on that port at that remote address. If DNS is available, or if the reference is available in /etc/hosts, a hostname can certainly be used in place of the numeric address. Upon completion of the command, or other EOF/error condition, the connection will be closed down.

It is possible to create arbitrary listen sockets at destinations with netcat (sometimes aliased as nc) and the output from netcat can be redirected to about anything else you might need like file creation, screen display, tar, or whatever. Be careful to watch for security problems with open ports, depending on what you are doing with the destination host system (if you are running ax25 sockets you probably aren't running it on some highly valued host anyhow). You might want to restrict the possible ip addresses that the destination host can be reached from with an iptables filter rule entry. If you are using netcat as a listener, you might want to put the netcat listen command into an endless loop in a simple script, as the netcat listener will terminate on each connection close, if the process needs to take place repetitively.

UDP example:

some-command parm1 parm2 > /dev/udp/12.34.56.78/1234

Same as above, but since UDP is connectionless and stateless, the connection start and teardown process isn't applicable. Netcat has a udp mode as well, and see the netcat(1) documentation for a discussion on some of the fine points of udp listen socket behavior. Use the -u flag with netcat for UDP mode.

A useful example is to inject packets into the UDP listen port of aprsd, usually port 1315. In fact I have used this technique to forward aprs packets from a remote slave aprsd listener daemon to another aprsd process which can forward them to the main internet aprsd network, without the bidirectional overhead of the entire body of aprs traffic just to the remote listener aprsd. I am using it to add site diversity reception to a local aprsd server that feeds the internet aprsd net. Use the one-line script:

netcat localhost 14579 > /dev/udp/remotehost/1315

Netcat will connect to the localhost aprsd output process, and print the local ax25 aprs monitored packets onto stdout, which will be redirected over whatever the tcp/ip/udp medium is to what is expected to be another aprsd process at remotehost listening on udp port 1315. That destination aprsd process needs to be configured to recognize our sending ip address as a trusted source, and you can also put it into an iptables filter rule if you like. When the udp packet is consumed by aprsd, it will handle that packet as any other and forward it to the internet, and the terse tracing of aprsd will indicate that it arrived as a UDP input. There appears to be a subtle difference in the behavior of UDP listen socket behavior with aprsd as compared to netcat, and the aprsd behavior seems to be a little more stable over time, while netcat seems to appear to close the UDP listen socket arbitrarily. Your mileage may vary.

There also is /dev/ip/host/protocol. I haven't found anything useful for this yet, but it also exists. Possibly it could be useful to generate ip packets on protocol 93 or 94 and inject them into ax25ipd or similar listeners. Whatever internal header the target protocol requires in addition to useful data would somehow have to be prepended/appended to each packets data by the process that generates the redirected data to begin with. Maybe pipe it through some intermediate process written for the purpose. It should also be stateless at the IP layer, the target protocol could be a stateful entity depending on what the protocol does.

See also: netcat(1), bash(1), aprsd docs, aprsd.conf

-WB5AOH-