From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 19662 invoked from network); 3 Oct 2023 21:30:25 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 3 Oct 2023 21:30:25 -0000 Received: from pb-smtp1.pobox.com ([64.147.108.70]) by 9front; Tue Oct 3 17:29:02 -0400 2023 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 607BE1985E0 for <9front@9front.org>; Tue, 3 Oct 2023 17:28:57 -0400 (EDT) (envelope-from unobe@cpan.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=message-id :to:from:subject:date:mime-version:content-type :content-transfer-encoding; s=sasl; bh=eB6LlqL3PKfAoCZsTzSnMx9BD E78rK6F1cieOYIQwPM=; b=C9v3/OMrV5MBVJgB1kcS5tVh0jnfADxaf1NG/EOje LkQhaOP4ceu56KYzZzBj3hb6D88JFAHmaP5IUcD+sHhTgs/Yx+bEJWGO2beLkPZM ZGEY4/V8dzsylnr+3W9ZS4jMZeQAYEX87ZALFzBNVZwotemsYzZ5gSxwHZHZmgFp hI= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 599171985DF for <9front@9front.org>; Tue, 3 Oct 2023 17:28:57 -0400 (EDT) (envelope-from unobe@cpan.org) Received: from strider.localdomain (unknown [75.237.252.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 29AA41985DE for <9front@9front.org>; Tue, 3 Oct 2023 17:28:56 -0400 (EDT) (envelope-from unobe@cpan.org) Message-ID: To: 9front@9front.org From: Romano Date: Tue, 03 Oct 2023 14:28:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: DBA61EFC-6233-11EE-887B-78DCEB2EC81B-09620299!pb-smtp1.pobox.com List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: advanced virtualized module table-aware hypervisor manager Subject: [9front] DNS/ICMP via sshnet(4) or drawterm Reply-To: 9front@9front.org Precedence: bulk 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?