9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] DNS/ICMP via sshnet(4) or drawterm
@ 2023-10-03 21:28 Romano
  2023-10-03 22:42 ` ori
  0 siblings, 1 reply; 8+ messages in thread
From: Romano @ 2023-10-03 21:28 UTC (permalink / raw)
  To: 9front

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?


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] DNS/ICMP via sshnet(4) or drawterm
  2023-10-03 21:28 [9front] DNS/ICMP via sshnet(4) or drawterm Romano
@ 2023-10-03 22:42 ` ori
  2023-10-03 23:02   ` unobe
  0 siblings, 1 reply; 8+ messages in thread
From: ori @ 2023-10-03 22:42 UTC (permalink / raw)
  To: 9front

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?
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] DNS/ICMP via sshnet(4) or drawterm
  2023-10-03 22:42 ` ori
@ 2023-10-03 23:02   ` unobe
  2023-10-04  1:04     ` ori
  2023-10-27 11:28     ` mkf9
  0 siblings, 2 replies; 8+ messages in thread
From: unobe @ 2023-10-03 23:02 UTC (permalink / raw)
  To: 9front

Quoth ori@eigenstate.org:
> if the goal is dns, it may be better to simply make us
> fall back to dns-over-tcp.

Thanks for pointing that out, Ori. I didn't know about dns-over-tcp;
I never had to do a request that required it, apparently.  That would
entail modifying ndb/dns*, yeah?

My other major use case is ping.  I see that there is such a thing as
ping-over-tcp.  I suppose one of the use cases for providing
ping-over-tcp is seeing if packet-shaping is having an impact on a
connection.  That would suggest to me that ip/ping would be modified,
or just a separate utility.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] DNS/ICMP via sshnet(4) or drawterm
  2023-10-03 23:02   ` unobe
@ 2023-10-04  1:04     ` ori
  2023-10-04  1:14       ` unobe
  2023-10-27 11:28     ` mkf9
  1 sibling, 1 reply; 8+ messages in thread
From: ori @ 2023-10-04  1:04 UTC (permalink / raw)
  To: 9front

Quoth unobe@cpan.org:
> Quoth ori@eigenstate.org:
> > if the goal is dns, it may be better to simply make us
> > fall back to dns-over-tcp.
> 
> Thanks for pointing that out, Ori. I didn't know about dns-over-tcp;
> I never had to do a request that required it, apparently.  That would
> entail modifying ndb/dns*, yeah?
> 
> My other major use case is ping.  I see that there is such a thing as
> ping-over-tcp.  I suppose one of the use cases for providing
> ping-over-tcp is seeing if packet-shaping is having an impact on a
> connection.  That would suggest to me that ip/ping would be modified,
> or just a separate utility.
> 

I don't think ICMP forwarding is worth the effort;
it's ok to just not have it.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] DNS/ICMP via sshnet(4) or drawterm
  2023-10-04  1:04     ` ori
@ 2023-10-04  1:14       ` unobe
  2023-10-04  8:35         ` hiro
  0 siblings, 1 reply; 8+ messages in thread
From: unobe @ 2023-10-04  1:14 UTC (permalink / raw)
  To: 9front

Quoth ori@eigenstate.org:
> > My other major use case is ping.  I see that there is such a thing as
> > ping-over-tcp.  I suppose one of the use cases for providing
> > ping-over-tcp is seeing if packet-shaping is having an impact on a
> > connection.  That would suggest to me that ip/ping would be modified,
> > or just a separate utility.
> > 
> 
> I don't think ICMP forwarding is worth the effort;
> it's ok to just not have it.

Right, I wasn't thinking of ICMP forwarding proper, but from what I
read online it's sending an ACK or SYN packet and measure the respones
time.  Maybe there's something that already does that, or it's trivial
to do.

Anyway, thanks again for the reply re: DNS-overTCP.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] DNS/ICMP via sshnet(4) or drawterm
  2023-10-04  1:14       ` unobe
@ 2023-10-04  8:35         ` hiro
  0 siblings, 0 replies; 8+ messages in thread
From: hiro @ 2023-10-04  8:35 UTC (permalink / raw)
  To: 9front

i think the udp stuff should work, debug it again?
i managed to tftp-boot a machine to 9front over drawterm once.

i guess the icmp is missing in drawterm, but it's possible to add
that. it's not very complicated to forward it in the same way as UDP.
the hardest part is finding the right interfaces on each of the
drawterm host platforms (win32, unix, etc)

On 10/4/23, unobe@cpan.org <unobe@cpan.org> wrote:
> Quoth ori@eigenstate.org:
>> > My other major use case is ping.  I see that there is such a thing as
>> > ping-over-tcp.  I suppose one of the use cases for providing
>> > ping-over-tcp is seeing if packet-shaping is having an impact on a
>> > connection.  That would suggest to me that ip/ping would be modified,
>> > or just a separate utility.
>> >
>>
>> I don't think ICMP forwarding is worth the effort;
>> it's ok to just not have it.
>
> Right, I wasn't thinking of ICMP forwarding proper, but from what I
> read online it's sending an ACK or SYN packet and measure the respones
> time.  Maybe there's something that already does that, or it's trivial
> to do.
>
> Anyway, thanks again for the reply re: DNS-overTCP.
>
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] DNS/ICMP via sshnet(4) or drawterm
  2023-10-03 23:02   ` unobe
  2023-10-04  1:04     ` ori
@ 2023-10-27 11:28     ` mkf9
  2023-10-27 13:59       ` ori
  1 sibling, 1 reply; 8+ messages in thread
From: mkf9 @ 2023-10-27 11:28 UTC (permalink / raw)
  To: 9front

unobe@cpan.org wrote:
> Quoth ori@eigenstate.org:
>> if the goal is dns, it may be better to simply make us
>> fall back to dns-over-tcp.
> 
> Thanks for pointing that out, Ori. I didn't know about dns-over-tcp;
> I never had to do a request that required it, apparently.  That would
> entail modifying ndb/dns*, yeah?
I'm not sure if clients need change, but we have a ndb/dnstcp server 
that seems to work.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] DNS/ICMP via sshnet(4) or drawterm
  2023-10-27 11:28     ` mkf9
@ 2023-10-27 13:59       ` ori
  0 siblings, 0 replies; 8+ messages in thread
From: ori @ 2023-10-27 13:59 UTC (permalink / raw)
  To: 9front

Quoth mkf9 <mkf9@riseup.net>:
> unobe@cpan.org wrote:
> > Quoth ori@eigenstate.org:
> >> if the goal is dns, it may be better to simply make us
> >> fall back to dns-over-tcp.
> > 
> > Thanks for pointing that out, Ori. I didn't know about dns-over-tcp;
> > I never had to do a request that required it, apparently.  That would
> > entail modifying ndb/dns*, yeah?
> I'm not sure if clients need change, but we have a ndb/dnstcp server 
> that seems to work.

also, for sshnet: we *have* a /net/cs; we should not be
emitting dns packets directly.


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2023-10-27 14:01 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-03 21:28 [9front] DNS/ICMP via sshnet(4) or drawterm Romano
2023-10-03 22:42 ` ori
2023-10-03 23:02   ` unobe
2023-10-04  1:04     ` ori
2023-10-04  1:14       ` unobe
2023-10-04  8:35         ` hiro
2023-10-27 11:28     ` mkf9
2023-10-27 13:59       ` ori

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).