Re: [9front] DNS/ICMP via sshnet(4) or drawterm

[ori@eigenstate.org]

if the goal is dns, it may be better to simply make us
fall back to dns-over-tcp.

Quoth Romano <unobe@cpan.org>:
> Hi y'all,
> 
> I'm interested in getting DNS/ICMP working over sshnet(4) or
> drawterm and want to get feedback to make sure it's not a fool's
> errand. A simple 'No.' would suffice.
> 
> First, I saw that drawterm provides /mnt/term/net/udp/, and so
> attempted to do the following within drawterm as a proof-of-concept,
> to see if I could use drawterm instead of sshnet:
> 	bind /mnt/term/net /net echo -n INTERNAL_DNS_SERVER >
> 	/env/DNSSERVER ndb/dnsgetip INTERNAL_HOST_NAME
> but get:
> 	ndb/dnsgetip: INTERNAL_HOST_NAME: dns failure: server failure
> I thought that kern/devip-posix.c would have properly passed on udp
> packets.  So my first question is: has anyone has done something like
> this using drawterm, and if so, how?
> 
> (If my understanding is correct, drawterm would be sending everything
> over 9p, which adds another layer than just using sshnet(4), but might
> not make a difference immediately if I'm just trying for DNS)
> 
> Re: sshnet(4), it'd be more complicated because the different
> solutions I've seen on linux hosts use socat and nc to start listening
> on a specific port on the remote host, then set up a pipe between the
> tcp-over-ssh port to whatever udp host and port on the remote host's
> side.  So by necessity, sshnet(4) would have to do something similar.
> My initial thought is to use ssh(1) to execute port listening on
> remote host that would then send to a specific udp port/host.  So
> maybe something like:
> 
> 1.  Add a flag to sshnet(4) called -u, which specifies a script to
> call using ssh(1) on the same remote host to setup tcp-over-udp port
> forwarding.
> 
> 2.  The script would be mere commands to run on the remote host, so
> could be targeted based on the remote host.
> 
> 3.  The command on the remote host would be executed to implement the
> UDP messages described in ip(3) (i.e., the script would handle the
> ctl, data, err, etc.  messaging).
> 
> For the script, a stock one might be provided at some point for common
> remote host OSes/setups.  Does something like that look practically
> feasible?
>