[9fans] Serving tftp on a second interface

[9fans] Serving tftp on a second interface

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

I'm trying to isolate my plan9 network from the other things running in my
house.
I have two ports in the back of my cpu/auth box, which I am going to use as
the bridge as well, and a network switch.  The switch is connected to the
port on my cpu/auth box that should serve the 192.168.0.0 subnet; the other
port goes to my household router on 192.168.1.0 .

Things *almost* work.  In an attempt not to mess my world too much, I'm
setting up my plan9 network on ether1, bound into /net.alt.  From there I
successfully serve DHCP to hosts that are connected to my switch by running
this:

bind -b '#l1' /net.alt
bind -b '#I1' /net.alt

ip/ipconfig -x /net.alt ether /net.alt/ether1 add 192.168.0.2 255.255.255.0
ndb/cs -x /net.alt -f /lib/ndb/local

ip/dhcpd -x /net.alt 192.168.0.32 16

But tftp is escaping me.
When running tftpd I get:

fluxcpu% ip/tftpd -x /net.alt
ip/tftpd: announcing on /net.alt/udp!*!tftp: announce opening
/net.alt/udp/clone: file does not exist: '/net.alt/udp'


But /net.alt/udp is clearly there:

fluxcpu% ls /net.alt/udp
/net.alt/udp/0
/net.alt/udp/1
/net.alt/udp/2
/net.alt/udp/clone
/net.alt/udp/stats

Any pointers?

Thanks,
  Paul

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M262362461b0c96d257b4caea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2535 bytes --]

Re: [9fans] Serving tftp on a second interface

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

run it under ratrace, let's see what it thinks it's doing.
don't forget: you can do what tftp is doing via echo commands in rc, and,
sometimes, that's a fast debug path.

On Mon, Apr 7, 2025 at 1:13 PM Paul Lalonde <paul.a.lalonde@gmail.com>
wrote:

> I'm trying to isolate my plan9 network from the other things running in my
> house.
> I have two ports in the back of my cpu/auth box, which I am going to use
> as the bridge as well, and a network switch.  The switch is connected to
> the port on my cpu/auth box that should serve the 192.168.0.0 subnet; the
> other port goes to my household router on 192.168.1.0 .
>
> Things *almost* work.  In an attempt not to mess my world too much, I'm
> setting up my plan9 network on ether1, bound into /net.alt.  From there I
> successfully serve DHCP to hosts that are connected to my switch by running
> this:
>
> bind -b '#l1' /net.alt
> bind -b '#I1' /net.alt
>
> ip/ipconfig -x /net.alt ether /net.alt/ether1 add 192.168.0.2 255.255.255.0
> ndb/cs -x /net.alt -f /lib/ndb/local
>
> ip/dhcpd -x /net.alt 192.168.0.32 16
>
> But tftp is escaping me.
> When running tftpd I get:
>
> fluxcpu% ip/tftpd -x /net.alt
> ip/tftpd: announcing on /net.alt/udp!*!tftp: announce opening
> /net.alt/udp/clone: file does not exist: '/net.alt/udp'
>
>
> But /net.alt/udp is clearly there:
>
> fluxcpu% ls /net.alt/udp
> /net.alt/udp/0
> /net.alt/udp/1
> /net.alt/udp/2
> /net.alt/udp/clone
> /net.alt/udp/stats
>
> Any pointers?
>
> Thanks,
>   Paul
>
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M262362461b0c96d257b4caea>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mce0c29912744047023b84a6b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3219 bytes --]

Re: [9fans] Serving tftp on a second interface

[Skip Tavakkolian]

I think a blank namespace is getting built before accessing anything.
looking at the code, it looks like newns() gets called before
announce().

On Mon, Apr 7, 2025 at 1:13 PM Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
>
> I'm trying to isolate my plan9 network from the other things running in my house.
> I have two ports in the back of my cpu/auth box, which I am going to use as the bridge as well, and a network switch.  The switch is connected to the port on my cpu/auth box that should serve the 192.168.0.0 subnet; the other port goes to my household router on 192.168.1.0 .
>
> Things *almost* work.  In an attempt not to mess my world too much, I'm setting up my plan9 network on ether1, bound into /net.alt.  From there I successfully serve DHCP to hosts that are connected to my switch by running this:
>
> bind -b '#l1' /net.alt
> bind -b '#I1' /net.alt
>
> ip/ipconfig -x /net.alt ether /net.alt/ether1 add 192.168.0.2 255.255.255.0
> ndb/cs -x /net.alt -f /lib/ndb/local
>
> ip/dhcpd -x /net.alt 192.168.0.32 16
>
> But tftp is escaping me.
> When running tftpd I get:
>
> fluxcpu% ip/tftpd -x /net.alt
> ip/tftpd: announcing on /net.alt/udp!*!tftp: announce opening /net.alt/udp/clone: file does not exist: '/net.alt/udp'
>
>
> But /net.alt/udp is clearly there:
>
> fluxcpu% ls /net.alt/udp
> /net.alt/udp/0
> /net.alt/udp/1
> /net.alt/udp/2
> /net.alt/udp/clone
> /net.alt/udp/stats
>
> Any pointers?
>
> Thanks,
>   Paul
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M34f8bd72bcb39bac959c06f1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Serving tftp on a second interface

[Paul Lalonde]

[-- Attachment #1.1: Type: text/plain, Size: 2540 bytes --]

Skip has the right of it.  Found Skip's email just after I figured out from
Ron's ratrace hint that it's building a fresh namespace, which means that
all my careful network stack setup is for naught.

Now, I don't know *why* it makes up a fresh namespace before binding to
/net.alt, but go figure.

I think this is a bug in tftpd, which should establish connections *before*
rebuilding the namespace.

Attached is a patch which does this by moving the setuser() chdir() to
after establishing a connection.

Feedback?

Paul

On Mon, Apr 7, 2025 at 2:15 PM Skip Tavakkolian <skip.tavakkolian@gmail.com>
wrote:

> I think a blank namespace is getting built before accessing anything.
> looking at the code, it looks like newns() gets called before
> announce().
>
> On Mon, Apr 7, 2025 at 1:13 PM Paul Lalonde <paul.a.lalonde@gmail.com>
> wrote:
> >
> > I'm trying to isolate my plan9 network from the other things running in
> my house.
> > I have two ports in the back of my cpu/auth box, which I am going to use
> as the bridge as well, and a network switch.  The switch is connected to
> the port on my cpu/auth box that should serve the 192.168.0.0 subnet; the
> other port goes to my household router on 192.168.1.0 .
> >
> > Things *almost* work.  In an attempt not to mess my world too much, I'm
> setting up my plan9 network on ether1, bound into /net.alt.  From there I
> successfully serve DHCP to hosts that are connected to my switch by running
> this:
> >
> > bind -b '#l1' /net.alt
> > bind -b '#I1' /net.alt
> >
> > ip/ipconfig -x /net.alt ether /net.alt/ether1 add 192.168.0.2
> 255.255.255.0
> > ndb/cs -x /net.alt -f /lib/ndb/local
> >
> > ip/dhcpd -x /net.alt 192.168.0.32 16
> >
> > But tftp is escaping me.
> > When running tftpd I get:
> >
> > fluxcpu% ip/tftpd -x /net.alt
> > ip/tftpd: announcing on /net.alt/udp!*!tftp: announce opening
> /net.alt/udp/clone: file does not exist: '/net.alt/udp'
> >
> >
> > But /net.alt/udp is clearly there:
> >
> > fluxcpu% ls /net.alt/udp
> > /net.alt/udp/0
> > /net.alt/udp/1
> > /net.alt/udp/2
> > /net.alt/udp/clone
> > /net.alt/udp/stats
> >
> > Any pointers?
> >
> > Thanks,
> >   Paul
> >
> > 9fans / 9fans / see discussions + participants + delivery options
> Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mf4824bcedd0727a874e81ce6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #1.2: Type: text/html, Size: 4279 bytes --]

[-- Attachment #2: fix_tftpd.patch --]
[-- Type: application/octet-stream, Size: 1252 bytes --]

From: Paul Lalonde <plalonde@acm.org>
Date: Mon, 07 Apr 2025 21:29:35 +0000
Subject: [PATCH] Change user/namespace on connection instead of ahead of listening.


This means not losing any network setup in the parent namespace before listening for connections,
but still adequately limiting service to files accessible by "none".
---
diff 8a8a271fe4f2ea935c733c1ccd14ef9a51ed3ea9 e392db19c1c49befd5e3a79f0aa26b8f72208046
--- a/sys/src/cmd/ip/tftpd.c
+++ b/sys/src/cmd/ip/tftpd.c
@@ -170,14 +170,6 @@
 	fmtinstall('E', eipfmt);
 	fmtinstall('I', eipfmt);
 
-	/*
-	 * setuser calls newns, and typical /lib/namespace files contain
-	 * "cd /usr/$user", so call setuser before chdir.
-	 */
-	setuser();
-	if(chdir(homedir) < 0)
-		sysfatal("can't get to directory %s: %r", homedir);
-
 	if(!dbg)
 		switch(rfork(RFNOTEG|RFPROC|RFFDG)) {
 		case -1:
@@ -210,6 +202,13 @@
 			pid = getpid();
 			syslog(0, flog, "tftpd %d connection from %s dir %s",
 				pid, raddr, ldir);
+			/*
+			 * setuser calls newns, and typical /lib/namespace files contain
+			 * "cd /usr/$user", so call setuser before chdir.
+			 */
+			setuser();
+			if(chdir(homedir) < 0)
+				sysfatal("can't get to directory %s: %r", homedir);
 			doserve(dfd);
 			exits("done");
 			break;

Re: [9fans] Serving tftp on a second interface

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]

recall that "tfpt" is pronounced "slow, insecure protocol designed to
enhance monster in the middle" and it may make more sense.

On Mon, Apr 7, 2025 at 2:34 PM Paul Lalonde <paul.a.lalonde@gmail.com>
wrote:

> Skip has the right of it.  Found Skip's email just after I figured out
> from Ron's ratrace hint that it's building a fresh namespace, which means
> that all my careful network stack setup is for naught.
>
> Now, I don't know *why* it makes up a fresh namespace before binding to
> /net.alt, but go figure.
>
> I think this is a bug in tftpd, which should establish connections
> *before* rebuilding the namespace.
>
> Attached is a patch which does this by moving the setuser() chdir() to
> after establishing a connection.
>
> Feedback?
>
> Paul
>
> On Mon, Apr 7, 2025 at 2:15 PM Skip Tavakkolian <
> skip.tavakkolian@gmail.com> wrote:
>
>> I think a blank namespace is getting built before accessing anything.
>> looking at the code, it looks like newns() gets called before
>> announce().
>>
>> On Mon, Apr 7, 2025 at 1:13 PM Paul Lalonde <paul.a.lalonde@gmail.com>
>> wrote:
>> >
>> > I'm trying to isolate my plan9 network from the other things running in
>> my house.
>> > I have two ports in the back of my cpu/auth box, which I am going to
>> use as the bridge as well, and a network switch.  The switch is connected
>> to the port on my cpu/auth box that should serve the 192.168.0.0 subnet;
>> the other port goes to my household router on 192.168.1.0 .
>> >
>> > Things *almost* work.  In an attempt not to mess my world too much, I'm
>> setting up my plan9 network on ether1, bound into /net.alt.  From there I
>> successfully serve DHCP to hosts that are connected to my switch by running
>> this:
>> >
>> > bind -b '#l1' /net.alt
>> > bind -b '#I1' /net.alt
>> >
>> > ip/ipconfig -x /net.alt ether /net.alt/ether1 add 192.168.0.2
>> 255.255.255.0
>> > ndb/cs -x /net.alt -f /lib/ndb/local
>> >
>> > ip/dhcpd -x /net.alt 192.168.0.32 16
>> >
>> > But tftp is escaping me.
>> > When running tftpd I get:
>> >
>> > fluxcpu% ip/tftpd -x /net.alt
>> > ip/tftpd: announcing on /net.alt/udp!*!tftp: announce opening
>> /net.alt/udp/clone: file does not exist: '/net.alt/udp'
>> >
>> >
>> > But /net.alt/udp is clearly there:
>> >
>> > fluxcpu% ls /net.alt/udp
>> > /net.alt/udp/0
>> > /net.alt/udp/1
>> > /net.alt/udp/2
>> > /net.alt/udp/clone
>> > /net.alt/udp/stats
>> >
>> > Any pointers?
>> >
>> > Thanks,
>> >   Paul
>> >
>> > 9fans / 9fans / see discussions + participants + delivery options
>> Permalink
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mf4824bcedd0727a874e81ce6>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M5a5970bd72485064824ed761
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4907 bytes --]

Re: [9fans] Serving tftp on a second interface

[Skip Tavakkolian]

Another way is to provide a namespace file to newns that builds
exactly what's required for the app. It might be the more flexible way
of fixing it, but I'm not sure.

On Mon, Apr 7, 2025 at 2:34 PM Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
>
> Skip has the right of it.  Found Skip's email just after I figured out from Ron's ratrace hint that it's building a fresh namespace, which means that all my careful network stack setup is for naught.
>
> Now, I don't know *why* it makes up a fresh namespace before binding to /net.alt, but go figure.
>
> I think this is a bug in tftpd, which should establish connections *before* rebuilding the namespace.
>
> Attached is a patch which does this by moving the setuser() chdir() to after establishing a connection.
>
> Feedback?
>
> Paul
>
> On Mon, Apr 7, 2025 at 2:15 PM Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
>>
>> I think a blank namespace is getting built before accessing anything.
>> looking at the code, it looks like newns() gets called before
>> announce().
>>
>> On Mon, Apr 7, 2025 at 1:13 PM Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
>> >
>> > I'm trying to isolate my plan9 network from the other things running in my house.
>> > I have two ports in the back of my cpu/auth box, which I am going to use as the bridge as well, and a network switch.  The switch is connected to the port on my cpu/auth box that should serve the 192.168.0.0 subnet; the other port goes to my household router on 192.168.1.0 .
>> >
>> > Things *almost* work.  In an attempt not to mess my world too much, I'm setting up my plan9 network on ether1, bound into /net.alt.  From there I successfully serve DHCP to hosts that are connected to my switch by running this:
>> >
>> > bind -b '#l1' /net.alt
>> > bind -b '#I1' /net.alt
>> >
>> > ip/ipconfig -x /net.alt ether /net.alt/ether1 add 192.168.0.2 255.255.255.0
>> > ndb/cs -x /net.alt -f /lib/ndb/local
>> >
>> > ip/dhcpd -x /net.alt 192.168.0.32 16
>> >
>> > But tftp is escaping me.
>> > When running tftpd I get:
>> >
>> > fluxcpu% ip/tftpd -x /net.alt
>> > ip/tftpd: announcing on /net.alt/udp!*!tftp: announce opening /net.alt/udp/clone: file does not exist: '/net.alt/udp'
>> >
>> >
>> > But /net.alt/udp is clearly there:
>> >
>> > fluxcpu% ls /net.alt/udp
>> > /net.alt/udp/0
>> > /net.alt/udp/1
>> > /net.alt/udp/2
>> > /net.alt/udp/clone
>> > /net.alt/udp/stats
>> >
>> > Any pointers?
>> >
>> > Thanks,
>> >   Paul
>> >
>> > 9fans / 9fans / see discussions + participants + delivery options Permalink
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mf48b2a125fc6ab218c30a68a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Serving tftp on a second interface

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 3834 bytes --]

It's easy enough to add /net.alt's setup into the namespace being
constructed - there's a few places to do so.
But this misses that pulling the network stack from the new namespace
completely bypasses every namespace composition tool used in the rest of
Plan9.
Ron's warning on the safety of the tftp protocol is sensible.  Frankly,
that argues for dumping tftp from the distro entirely ;-)
The rest of the world has moved on to https service for these files.
That's sensible enough that I'll do that as soon as I figure out how to
manage my certificate chain.  Which sadly, for my internal-facing boot
operations, is likely to be never.

Paul

On Mon, Apr 7, 2025 at 3:48 PM Skip Tavakkolian <skip.tavakkolian@gmail.com>
wrote:

> Another way is to provide a namespace file to newns that builds
> exactly what's required for the app. It might be the more flexible way
> of fixing it, but I'm not sure.
>
> On Mon, Apr 7, 2025 at 2:34 PM Paul Lalonde <paul.a.lalonde@gmail.com>
> wrote:
> >
> > Skip has the right of it.  Found Skip's email just after I figured out
> from Ron's ratrace hint that it's building a fresh namespace, which means
> that all my careful network stack setup is for naught.
> >
> > Now, I don't know *why* it makes up a fresh namespace before binding to
> /net.alt, but go figure.
> >
> > I think this is a bug in tftpd, which should establish connections
> *before* rebuilding the namespace.
> >
> > Attached is a patch which does this by moving the setuser() chdir() to
> after establishing a connection.
> >
> > Feedback?
> >
> > Paul
> >
> > On Mon, Apr 7, 2025 at 2:15 PM Skip Tavakkolian <
> skip.tavakkolian@gmail.com> wrote:
> >>
> >> I think a blank namespace is getting built before accessing anything.
> >> looking at the code, it looks like newns() gets called before
> >> announce().
> >>
> >> On Mon, Apr 7, 2025 at 1:13 PM Paul Lalonde <paul.a.lalonde@gmail.com>
> wrote:
> >> >
> >> > I'm trying to isolate my plan9 network from the other things running
> in my house.
> >> > I have two ports in the back of my cpu/auth box, which I am going to
> use as the bridge as well, and a network switch.  The switch is connected
> to the port on my cpu/auth box that should serve the 192.168.0.0 subnet;
> the other port goes to my household router on 192.168.1.0 .
> >> >
> >> > Things *almost* work.  In an attempt not to mess my world too much,
> I'm setting up my plan9 network on ether1, bound into /net.alt.  From there
> I successfully serve DHCP to hosts that are connected to my switch by
> running this:
> >> >
> >> > bind -b '#l1' /net.alt
> >> > bind -b '#I1' /net.alt
> >> >
> >> > ip/ipconfig -x /net.alt ether /net.alt/ether1 add 192.168.0.2
> 255.255.255.0
> >> > ndb/cs -x /net.alt -f /lib/ndb/local
> >> >
> >> > ip/dhcpd -x /net.alt 192.168.0.32 16
> >> >
> >> > But tftp is escaping me.
> >> > When running tftpd I get:
> >> >
> >> > fluxcpu% ip/tftpd -x /net.alt
> >> > ip/tftpd: announcing on /net.alt/udp!*!tftp: announce opening
> /net.alt/udp/clone: file does not exist: '/net.alt/udp'
> >> >
> >> >
> >> > But /net.alt/udp is clearly there:
> >> >
> >> > fluxcpu% ls /net.alt/udp
> >> > /net.alt/udp/0
> >> > /net.alt/udp/1
> >> > /net.alt/udp/2
> >> > /net.alt/udp/clone
> >> > /net.alt/udp/stats
> >> >
> >> > Any pointers?
> >> >
> >> > Thanks,
> >> >   Paul
> >> >
> >> > 9fans / 9fans / see discussions + participants + delivery options
> Permalink
> >
> > 9fans / 9fans / see discussions + participants + delivery options
> Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M8119f9f04fa292dbbb816866
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6049 bytes --]

Re: [9fans] Serving tftp on a second interface

[tlaronde]

On Mon, Apr 07, 2025 at 03:53:03PM -0700, Paul Lalonde wrote:
> It's easy enough to add /net.alt's setup into the namespace being
> constructed - there's a few places to do so.
> But this misses that pulling the network stack from the new namespace
> completely bypasses every namespace composition tool used in the rest of
> Plan9.
> Ron's warning on the safety of the tftp protocol is sensible.  Frankly,
> that argues for dumping tftp from the distro entirely ;-)
> The rest of the world has moved on to https service for these files.

Even for network booting (PXE)?

> That's sensible enough that I'll do that as soon as I figure out how to
> manage my certificate chain.  Which sadly, for my internal-facing boot
> operations, is likely to be never.
> 
> Paul
> 
> On Mon, Apr 7, 2025 at 3:48?PM Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
> 
> > Another way is to provide a namespace file to newns that builds
> > exactly what's required for the app. It might be the more flexible way
> > of fixing it, but I'm not sure.
> >
> > On Mon, Apr 7, 2025 at 2:34?PM Paul Lalonde <paul.a.lalonde@gmail.com>
> > wrote:
> > >
> > > Skip has the right of it.  Found Skip's email just after I figured out
> > from Ron's ratrace hint that it's building a fresh namespace, which means
> > that all my careful network stack setup is for naught.
> > >
> > > Now, I don't know *why* it makes up a fresh namespace before binding to
> > /net.alt, but go figure.
> > >
> > > I think this is a bug in tftpd, which should establish connections
> > *before* rebuilding the namespace.
> > >
> > > Attached is a patch which does this by moving the setuser() chdir() to
> > after establishing a connection.
> > >
> > > Feedback?
> > >
> > > Paul
> > >
> > > On Mon, Apr 7, 2025 at 2:15?PM Skip Tavakkolian <
> > skip.tavakkolian@gmail.com> wrote:
> > >>
> > >> I think a blank namespace is getting built before accessing anything.
> > >> looking at the code, it looks like newns() gets called before
> > >> announce().
> > >>
> > >> On Mon, Apr 7, 2025 at 1:13?PM Paul Lalonde <paul.a.lalonde@gmail.com>
> > wrote:
> > >> >
> > >> > I'm trying to isolate my plan9 network from the other things running
> > in my house.
> > >> > I have two ports in the back of my cpu/auth box, which I am going to
> > use as the bridge as well, and a network switch.  The switch is connected
> > to the port on my cpu/auth box that should serve the 192.168.0.0 subnet;
> > the other port goes to my household router on 192.168.1.0 .
> > >> >
> > >> > Things *almost* work.  In an attempt not to mess my world too much,
> > I'm setting up my plan9 network on ether1, bound into /net.alt.  From there
> > I successfully serve DHCP to hosts that are connected to my switch by
> > running this:
> > >> >
> > >> > bind -b '#l1' /net.alt
> > >> > bind -b '#I1' /net.alt
> > >> >
> > >> > ip/ipconfig -x /net.alt ether /net.alt/ether1 add 192.168.0.2
> > 255.255.255.0
> > >> > ndb/cs -x /net.alt -f /lib/ndb/local
> > >> >
> > >> > ip/dhcpd -x /net.alt 192.168.0.32 16
> > >> >
> > >> > But tftp is escaping me.
> > >> > When running tftpd I get:
> > >> >
> > >> > fluxcpu% ip/tftpd -x /net.alt
> > >> > ip/tftpd: announcing on /net.alt/udp!*!tftp: announce opening
> > /net.alt/udp/clone: file does not exist: '/net.alt/udp'
> > >> >
> > >> >
> > >> > But /net.alt/udp is clearly there:
> > >> >
> > >> > fluxcpu% ls /net.alt/udp
> > >> > /net.alt/udp/0
> > >> > /net.alt/udp/1
> > >> > /net.alt/udp/2
> > >> > /net.alt/udp/clone
> > >> > /net.alt/udp/stats
> > >> >
> > >> > Any pointers?
> > >> >
> > >> > Thanks,
> > >> >   Paul
> > >> >
> > >> > 9fans / 9fans / see discussions + participants + delivery options
> > Permalink
> > >
> > > 9fans / 9fans / see discussions + participants + delivery options
> > Permalink

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M96988b039c28f36b4677935a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Serving tftp on a second interface

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 5034 bytes --]

absolutely for network booting, people have moved from tftp to https. tftp
is slow, inefficient, and insecure: pick any 3. Anybody who does network
boot for serious commercial purposes stopped using tftp some time ago.

nobody should have been using tftp for netboot for the last 10 years, but
change takes time. We got Google off it a while back as part of the NERF
project.



On Tue, Apr 8, 2025 at 5:28 AM <tlaronde@kergis.com> wrote:

> On Mon, Apr 07, 2025 at 03:53:03PM -0700, Paul Lalonde wrote:
> > It's easy enough to add /net.alt's setup into the namespace being
> > constructed - there's a few places to do so.
> > But this misses that pulling the network stack from the new namespace
> > completely bypasses every namespace composition tool used in the rest of
> > Plan9.
> > Ron's warning on the safety of the tftp protocol is sensible.  Frankly,
> > that argues for dumping tftp from the distro entirely ;-)
> > The rest of the world has moved on to https service for these files.
>
> Even for network booting (PXE)?
>
> > That's sensible enough that I'll do that as soon as I figure out how to
> > manage my certificate chain.  Which sadly, for my internal-facing boot
> > operations, is likely to be never.
> >
> > Paul
> >
> > On Mon, Apr 7, 2025 at 3:48?PM Skip Tavakkolian <
> skip.tavakkolian@gmail.com>
> > wrote:
> >
> > > Another way is to provide a namespace file to newns that builds
> > > exactly what's required for the app. It might be the more flexible way
> > > of fixing it, but I'm not sure.
> > >
> > > On Mon, Apr 7, 2025 at 2:34?PM Paul Lalonde <paul.a.lalonde@gmail.com>
> > > wrote:
> > > >
> > > > Skip has the right of it.  Found Skip's email just after I figured
> out
> > > from Ron's ratrace hint that it's building a fresh namespace, which
> means
> > > that all my careful network stack setup is for naught.
> > > >
> > > > Now, I don't know *why* it makes up a fresh namespace before binding
> to
> > > /net.alt, but go figure.
> > > >
> > > > I think this is a bug in tftpd, which should establish connections
> > > *before* rebuilding the namespace.
> > > >
> > > > Attached is a patch which does this by moving the setuser() chdir()
> to
> > > after establishing a connection.
> > > >
> > > > Feedback?
> > > >
> > > > Paul
> > > >
> > > > On Mon, Apr 7, 2025 at 2:15?PM Skip Tavakkolian <
> > > skip.tavakkolian@gmail.com> wrote:
> > > >>
> > > >> I think a blank namespace is getting built before accessing
> anything.
> > > >> looking at the code, it looks like newns() gets called before
> > > >> announce().
> > > >>
> > > >> On Mon, Apr 7, 2025 at 1:13?PM Paul Lalonde <
> paul.a.lalonde@gmail.com>
> > > wrote:
> > > >> >
> > > >> > I'm trying to isolate my plan9 network from the other things
> running
> > > in my house.
> > > >> > I have two ports in the back of my cpu/auth box, which I am going
> to
> > > use as the bridge as well, and a network switch.  The switch is
> connected
> > > to the port on my cpu/auth box that should serve the 192.168.0.0
> subnet;
> > > the other port goes to my household router on 192.168.1.0 .
> > > >> >
> > > >> > Things *almost* work.  In an attempt not to mess my world too
> much,
> > > I'm setting up my plan9 network on ether1, bound into /net.alt.  From
> there
> > > I successfully serve DHCP to hosts that are connected to my switch by
> > > running this:
> > > >> >
> > > >> > bind -b '#l1' /net.alt
> > > >> > bind -b '#I1' /net.alt
> > > >> >
> > > >> > ip/ipconfig -x /net.alt ether /net.alt/ether1 add 192.168.0.2
> > > 255.255.255.0
> > > >> > ndb/cs -x /net.alt -f /lib/ndb/local
> > > >> >
> > > >> > ip/dhcpd -x /net.alt 192.168.0.32 16
> > > >> >
> > > >> > But tftp is escaping me.
> > > >> > When running tftpd I get:
> > > >> >
> > > >> > fluxcpu% ip/tftpd -x /net.alt
> > > >> > ip/tftpd: announcing on /net.alt/udp!*!tftp: announce opening
> > > /net.alt/udp/clone: file does not exist: '/net.alt/udp'
> > > >> >
> > > >> >
> > > >> > But /net.alt/udp is clearly there:
> > > >> >
> > > >> > fluxcpu% ls /net.alt/udp
> > > >> > /net.alt/udp/0
> > > >> > /net.alt/udp/1
> > > >> > /net.alt/udp/2
> > > >> > /net.alt/udp/clone
> > > >> > /net.alt/udp/stats
> > > >> >
> > > >> > Any pointers?
> > > >> >
> > > >> > Thanks,
> > > >> >   Paul
> > > >> >
> > > >> > 9fans / 9fans / see discussions + participants + delivery options
> > > Permalink
> > > >
> > > > 9fans / 9fans / see discussions + participants + delivery options
> > > Permalink
> 
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mffe095e53cd6ef98bf9875f6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 8394 bytes --]

Re: [9fans] Serving tftp on a second interface

[Kurt H Maier via 9fans]

On Tue, Apr 08, 2025 at 08:20:20AM +0200, tlaronde@kergis.com wrote:
> On Mon, Apr 07, 2025 at 03:53:03PM -0700, Paul Lalonde wrote:
> > It's easy enough to add /net.alt's setup into the namespace being
> > constructed - there's a few places to do so.
> > But this misses that pulling the network stack from the new namespace
> > completely bypasses every namespace composition tool used in the rest of
> > Plan9.
> > Ron's warning on the safety of the tftp protocol is sensible.  Frankly,
> > that argues for dumping tftp from the distro entirely ;-)
> > The rest of the world has moved on to https service for these files.
> 
> Even for network booting (PXE)?

Here is the UEFI info for HTTP boot:
https://uefi.org/specs/UEFI/2.11/24_Network_Protocols_SNP_PXE_BIS.html#http-boot

Most serious computer manufacturers support this by now; the ARM SBC
jungle is, as usual, a crap shoot.  The past decade in the datacenter
has been the long slow battle to move from ipmi and pxe to redfish and
httpboot.

Sadly, a lot of the networking side is still PXE-based, but progress is
happening even there.

khm

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M7ea2a3369bb118794912fcb8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Serving tftp on a second interface

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

Ok, on to my next problem: Though I can get dhcpd and tftpd to serve
happily from /net.alt, apparently I can't get aux/listen to do so.

When my terminal tries to dial tcp!192.168.1.2!17020 I get a connection
refused.  This is the same IP that's serving dhcp and tftp.
How do I get aux/listen to pay attention there?  It's listening correctly
on my other interface, where drawterm connects quite happily.

Any suggestions?

Paul

On Tue, Apr 8, 2025 at 9:34 AM Kurt H Maier via 9fans <9fans@9fans.net>
wrote:

> On Tue, Apr 08, 2025 at 08:20:20AM +0200, tlaronde@kergis.com wrote:
> > On Mon, Apr 07, 2025 at 03:53:03PM -0700, Paul Lalonde wrote:
> > > It's easy enough to add /net.alt's setup into the namespace being
> > > constructed - there's a few places to do so.
> > > But this misses that pulling the network stack from the new namespace
> > > completely bypasses every namespace composition tool used in the rest
> of
> > > Plan9.
> > > Ron's warning on the safety of the tftp protocol is sensible.  Frankly,
> > > that argues for dumping tftp from the distro entirely ;-)
> > > The rest of the world has moved on to https service for these files.
> >
> > Even for network booting (PXE)?
> 
> Here is the UEFI info for HTTP boot:
> 
> https://uefi.org/specs/UEFI/2.11/24_Network_Protocols_SNP_PXE_BIS.html#http-boot
> 
> Most serious computer manufacturers support this by now; the ARM SBC
> jungle is, as usual, a crap shoot.  The past decade in the datacenter
> has been the long slow battle to move from ipmi and pxe to redfish and
> httpboot.
> 
> Sadly, a lot of the networking side is still PXE-based, but progress is
> happening even there.
> 
> khm

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mc12565de1c7f640c0a18af4f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3602 bytes --]

Re: [9fans] Serving tftp on a second interface

[Skip Tavakkolian]

I'm guessing that maybe /net.alt isn't given as the last param ot aux/listen?

On Tue, Apr 8, 2025 at 1:44 PM Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
>
> Ok, on to my next problem: Though I can get dhcpd and tftpd to serve happily from /net.alt, apparently I can't get aux/listen to do so.
>
> When my terminal tries to dial tcp!192.168.1.2!17020 I get a connection refused.  This is the same IP that's serving dhcp and tftp.
> How do I get aux/listen to pay attention there?  It's listening correctly on my other interface, where drawterm connects quite happily.
>
> Any suggestions?
>
> Paul
>
> On Tue, Apr 8, 2025 at 9:34 AM Kurt H Maier via 9fans <9fans@9fans.net> wrote:
>>
>> On Tue, Apr 08, 2025 at 08:20:20AM +0200, tlaronde@kergis.com wrote:
>> > On Mon, Apr 07, 2025 at 03:53:03PM -0700, Paul Lalonde wrote:
>> > > It's easy enough to add /net.alt's setup into the namespace being
>> > > constructed - there's a few places to do so.
>> > > But this misses that pulling the network stack from the new namespace
>> > > completely bypasses every namespace composition tool used in the rest of
>> > > Plan9.
>> > > Ron's warning on the safety of the tftp protocol is sensible.  Frankly,
>> > > that argues for dumping tftp from the distro entirely ;-)
>> > > The rest of the world has moved on to https service for these files.
>> >
>> > Even for network booting (PXE)?
>> 
>> Here is the UEFI info for HTTP boot:
>> https://uefi.org/specs/UEFI/2.11/24_Network_Protocols_SNP_PXE_BIS.html#http-boot
>> 
>> Most serious computer manufacturers support this by now; the ARM SBC
>> jungle is, as usual, a crap shoot.  The past decade in the datacenter
>> has been the long slow battle to move from ipmi and pxe to redfish and
>> httpboot.
>> 
>> Sadly, a lot of the networking side is still PXE-based, but progress is
>> happening even there.
>> 
>> khm
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mac65d4be4be8b396e7774151
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Serving tftp on a second interface

[Jacob Moody]

aux/listen lacks a -x, but in your /cfg/$sysname/cpustart you could do something like:

@{
  rfork n
  bind '#I1' /net
  aux/listen -q
}

Bit of a workaround, but it should work. Maybe a discussion can be had about doing this better.

On 4/8/25 15:43, Paul Lalonde wrote:
> Ok, on to my next problem: Though I can get dhcpd and tftpd to serve happily from /net.alt, apparently I can't get aux/listen to do so.
> 
> When my terminal tries to dial tcp!192.168.1.2!17020 I get a connection refused.  This is the same IP that's serving dhcp and tftp.
> How do I get aux/listen to pay attention there?  It's listening correctly on my other interface, where drawterm connects quite happily.
> 
> Any suggestions?
> 
> Paul
> 
> On Tue, Apr 8, 2025 at 9:34 AM Kurt H Maier via 9fans <9fans@9fans.net <mailto:9fans@9fans.net>> wrote:
> 
>     On Tue, Apr 08, 2025 at 08:20:20AM +0200, tlaronde@kergis.com <mailto:tlaronde@kergis.com> wrote:
>     > On Mon, Apr 07, 2025 at 03:53:03PM -0700, Paul Lalonde wrote:
>     > > It's easy enough to add /net.alt's setup into the namespace being
>     > > constructed - there's a few places to do so.
>     > > But this misses that pulling the network stack from the new namespace
>     > > completely bypasses every namespace composition tool used in the rest of
>     > > Plan9.
>     > > Ron's warning on the safety of the tftp protocol is sensible.  Frankly,
>     > > that argues for dumping tftp from the distro entirely ;-)
>     > > The rest of the world has moved on to https service for these files.
>     >
>     > Even for network booting (PXE)?
> 
>     Here is the UEFI info for HTTP boot:
>     https://uefi.org/specs/UEFI/2.11/24_Network_Protocols_SNP_PXE_BIS.html#http-boot <https://uefi.org/specs/UEFI/2.11/24_Network_Protocols_SNP_PXE_BIS.html#http-boot>
> 
>     Most serious computer manufacturers support this by now; the ARM SBC
>     jungle is, as usual, a crap shoot.  The past decade in the datacenter
>     has been the long slow battle to move from ipmi and pxe to redfish and
>     httpboot.
> 
>     Sadly, a lot of the networking side is still PXE-based, but progress is
>     happening even there.
> 
>     khm
> 
>     ------------------------------------------
>     9fans: 9fans
>     Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M7ea2a3369bb118794912fcb8 <https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M7ea2a3369bb118794912fcb8>
>     Delivery options: https://9fans.topicbox.com/groups/9fans/subscription <https://9fans.topicbox.com/groups/9fans/subscription>
> 
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription> Permalink <https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mc12565de1c7f640c0a18af4f>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mb330da7bfe51ebd670f3433a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Serving tftp on a second interface

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 3957 bytes --]

I'd tried something similar, but had forgotten the rfork.
But I still get no joy.  Dial hangs there.  Looking at ratrace -c
aux/listen ..., there is no progress in aux/listen even when trying to dial
it locally from my host (fluxcpu, on 192.168.0.2/ether1 and
192.168.1.200/ether0)
fluxcpu% aux/dial tcp!192.168.0.2!17020

Whereas on my other interface:
fluxcpu% aux/dial tcp!192.168.1.200!17020
dp9ik@FluxDomfluxcpu%
exactly as expected.

I fear I'm doing something daft.

Paul



On Tue, Apr 8, 2025 at 1:58 PM Jacob Moody <moody@posixcafe.org> wrote:

> aux/listen lacks a -x, but in your /cfg/$sysname/cpustart you could do
> something like:
>
> @{
>   rfork n
>   bind '#I1' /net
>   aux/listen -q
> }
>
> Bit of a workaround, but it should work. Maybe a discussion can be had
> about doing this better.
>
> On 4/8/25 15:43, Paul Lalonde wrote:
> > Ok, on to my next problem: Though I can get dhcpd and tftpd to serve
> happily from /net.alt, apparently I can't get aux/listen to do so.
> >
> > When my terminal tries to dial tcp!192.168.1.2!17020 I get a connection
> refused.  This is the same IP that's serving dhcp and tftp.
> > How do I get aux/listen to pay attention there?  It's listening
> correctly on my other interface, where drawterm connects quite happily.
> >
> > Any suggestions?
> >
> > Paul
> >
> > On Tue, Apr 8, 2025 at 9:34 AM Kurt H Maier via 9fans <9fans@9fans.net
> <mailto:9fans@9fans.net>> wrote:
> >
> >     On Tue, Apr 08, 2025 at 08:20:20AM +0200, tlaronde@kergis.com
> <mailto:tlaronde@kergis.com> wrote:
> >     > On Mon, Apr 07, 2025 at 03:53:03PM -0700, Paul Lalonde wrote:
> >     > > It's easy enough to add /net.alt's setup into the namespace being
> >     > > constructed - there's a few places to do so.
> >     > > But this misses that pulling the network stack from the new
> namespace
> >     > > completely bypasses every namespace composition tool used in the
> rest of
> >     > > Plan9.
> >     > > Ron's warning on the safety of the tftp protocol is sensible.
> Frankly,
> >     > > that argues for dumping tftp from the distro entirely ;-)
> >     > > The rest of the world has moved on to https service for these
> files.
> >     >
> >     > Even for network booting (PXE)?
> >
> >     Here is the UEFI info for HTTP boot:
> >
> https://uefi.org/specs/UEFI/2.11/24_Network_Protocols_SNP_PXE_BIS.html#http-boot
> <
> https://uefi.org/specs/UEFI/2.11/24_Network_Protocols_SNP_PXE_BIS.html#http-boot
> >
> >
> >     Most serious computer manufacturers support this by now; the ARM SBC
> >     jungle is, as usual, a crap shoot.  The past decade in the datacenter
> >     has been the long slow battle to move from ipmi and pxe to redfish
> and
> >     httpboot.
> >
> >     Sadly, a lot of the networking side is still PXE-based, but progress
> is
> >     happening even there.
> >
> >     khm
> >
> >     ------------------------------------------
> >     9fans: 9fans
> >     Permalink:
> https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M7ea2a3369bb118794912fcb8
> <
> https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M7ea2a3369bb118794912fcb8
> >
> >     Delivery options:
> https://9fans.topicbox.com/groups/9fans/subscription <
> https://9fans.topicbox.com/groups/9fans/subscription>
> >
> > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions <
> https://9fans.topicbox.com/groups/9fans> + participants <
> https://9fans.topicbox.com/groups/9fans/members> + delivery options <
> https://9fans.topicbox.com/groups/9fans/subscription> Permalink <
> https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mc12565de1c7f640c0a18af4f

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M820b2106a357f6f479561398
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 7683 bytes --]

Re: [9fans] Serving tftp on a second interface

[ori]

Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> Ok, on to my next problem: Though I can get dhcpd and tftpd to serve
> happily from /net.alt, apparently I can't get aux/listen to do so.
> 
> When my terminal tries to dial tcp!192.168.1.2!17020 I get a connection
> refused.  This is the same IP that's serving dhcp and tftp.
> How do I get aux/listen to pay attention there?  It's listening correctly
> on my other interface, where drawterm connects quite happily.
> 
> Any suggestions?
> 

aux/listen doesn't have a '-x' option but it does have a final arg that lets
you pass the protocol and netstack.

        aux/listen ... /net.alt/tcp

should work.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Md3e5b349da831d84973397aa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Serving tftp on a second interface

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

I've tried that one as well, also to the same no-contact.
So ipxe sees my host, at 192.169.0.2, but my Plan9 system doesn't.  When
everything was plugged into the same subnet (ie, not using 2 interfaces on
my host) I mounted files fine from there.
I'm guessing I have a problem lower down in my stack.  I'll delve deeper.

Paul

On Tue, Apr 8, 2025, 3:01 p.m. <ori@eigenstate.org> wrote:

> Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> > Ok, on to my next problem: Though I can get dhcpd and tftpd to serve
> > happily from /net.alt, apparently I can't get aux/listen to do so.
> >
> > When my terminal tries to dial tcp!192.168.1.2!17020 I get a connection
> > refused.  This is the same IP that's serving dhcp and tftp.
> > How do I get aux/listen to pay attention there?  It's listening correctly
> > on my other interface, where drawterm connects quite happily.
> >
> > Any suggestions?
> >
> 
> aux/listen doesn't have a '-x' option but it does have a final arg that
> lets
> you pass the protocol and netstack.
> 
> aux/listen ... /net.alt/tcp
> 
> should work.
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M8f8fbcdbdafec8a69ad46c67
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2917 bytes --]

Re: [9fans] Serving tftp on a second interface

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 2314 bytes --]

Ok, I keep re-learning the hardest lesson:  tail doesn't tail a live file
but cat does.
Anyhow, I seem to have narrowed my problem down to the tls trampoline on
tcp17020.
Which, if I'm understanding correctly, means that I've got broken
authentication?

To summarize: Trying to network boot my terminal.  I get my plan9.ini and
kernel successfully from my server.
I'd like the terminal to mount the file system from the server.
When prompted for bootargs, when I provide "tls" I get the error message
"/bin/tlsclient: dial tcp!192.168.0.2!17020: connection refused".
My server runs the file system with options: local!/dev/sdE5/fs -m 7549 -A
-a tcp!*!564
I think that means it will listen on *any* local interface, right?
Or do I need something different to get it to listen on ether1 instead of
ether0's tcp setup?

Thanks,
  Paul

On Tue, Apr 8, 2025 at 3:04 PM Paul Lalonde <paul.a.lalonde@gmail.com>
wrote:

> I've tried that one as well, also to the same no-contact.
> So ipxe sees my host, at 192.169.0.2, but my Plan9 system doesn't.  When
> everything was plugged into the same subnet (ie, not using 2 interfaces on
> my host) I mounted files fine from there.
> I'm guessing I have a problem lower down in my stack.  I'll delve deeper.
>
> Paul
>
> On Tue, Apr 8, 2025, 3:01 p.m. <ori@eigenstate.org> wrote:
>
>> Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
>> > Ok, on to my next problem: Though I can get dhcpd and tftpd to serve
>> > happily from /net.alt, apparently I can't get aux/listen to do so.
>> >
>> > When my terminal tries to dial tcp!192.168.1.2!17020 I get a connection
>> > refused.  This is the same IP that's serving dhcp and tftp.
>> > How do I get aux/listen to pay attention there?  It's listening
>> correctly
>> > on my other interface, where drawterm connects quite happily.
>> >
>> > Any suggestions?
>> >
>> 
>> aux/listen doesn't have a '-x' option but it does have a final arg that
>> lets
>> you pass the protocol and netstack.
>> 
>> aux/listen ... /net.alt/tcp
>> 
>> should work.
>> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mc03582e769649c2cb2099728
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4340 bytes --]

Re: [9fans] Serving tftp on a second interface

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 2939 bytes --]

But is it only listening on 564?
 local!/dev/sdE5/fs -m 7549 -A -a tcp!*!564

no 17020 there?

On Wed, Apr 9, 2025 at 3:36 PM Paul Lalonde <paul.a.lalonde@gmail.com>
wrote:

> Ok, I keep re-learning the hardest lesson:  tail doesn't tail a live file
> but cat does.
> Anyhow, I seem to have narrowed my problem down to the tls trampoline on
> tcp17020.
> Which, if I'm understanding correctly, means that I've got broken
> authentication?
>
> To summarize: Trying to network boot my terminal.  I get my plan9.ini and
> kernel successfully from my server.
> I'd like the terminal to mount the file system from the server.
> When prompted for bootargs, when I provide "tls" I get the error message
> "/bin/tlsclient: dial tcp!192.168.0.2!17020: connection refused".
> My server runs the file system with options: local!/dev/sdE5/fs -m 7549 -A
> -a tcp!*!564
> I think that means it will listen on *any* local interface, right?
> Or do I need something different to get it to listen on ether1 instead of
> ether0's tcp setup?
>
> Thanks,
>   Paul
>
> On Tue, Apr 8, 2025 at 3:04 PM Paul Lalonde <paul.a.lalonde@gmail.com>
> wrote:
>
>> I've tried that one as well, also to the same no-contact.
>> So ipxe sees my host, at 192.169.0.2, but my Plan9 system doesn't.  When
>> everything was plugged into the same subnet (ie, not using 2 interfaces on
>> my host) I mounted files fine from there.
>> I'm guessing I have a problem lower down in my stack.  I'll delve deeper.
>>
>> Paul
>>
>> On Tue, Apr 8, 2025, 3:01 p.m. <ori@eigenstate.org> wrote:
>>
>>> Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
>>> > Ok, on to my next problem: Though I can get dhcpd and tftpd to serve
>>> > happily from /net.alt, apparently I can't get aux/listen to do so.
>>> >
>>> > When my terminal tries to dial tcp!192.168.1.2!17020 I get a connection
>>> > refused.  This is the same IP that's serving dhcp and tftp.
>>> > How do I get aux/listen to pay attention there?  It's listening
>>> correctly
>>> > on my other interface, where drawterm connects quite happily.
>>> >
>>> > Any suggestions?
>>> >
>>> 
>>> aux/listen doesn't have a '-x' option but it does have a final arg that
>>> lets
>>> you pass the protocol and netstack.
>>> 
>>> aux/listen ... /net.alt/tcp
>>> 
>>> should work.
>>> 
>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mc03582e769649c2cb2099728>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M10157ad538948263a6e0aa31
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 5002 bytes --]

Re: [9fans] Serving tftp on a second interface

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 3245 bytes --]

I neglected to add that tcp17020 is the tls trampoline that redirects to
564.

So I suspect my tls handshake but don't know how to debug it.

Paul

On Wed, Apr 9, 2025, 4:29 p.m. ron minnich <rminnich@gmail.com> wrote:

> But is it only listening on 564?
>  local!/dev/sdE5/fs -m 7549 -A -a tcp!*!564
>
> no 17020 there?
>
> On Wed, Apr 9, 2025 at 3:36 PM Paul Lalonde <paul.a.lalonde@gmail.com>
> wrote:
>
>> Ok, I keep re-learning the hardest lesson:  tail doesn't tail a live file
>> but cat does.
>> Anyhow, I seem to have narrowed my problem down to the tls trampoline on
>> tcp17020.
>> Which, if I'm understanding correctly, means that I've got broken
>> authentication?
>>
>> To summarize: Trying to network boot my terminal.  I get my plan9.ini and
>> kernel successfully from my server.
>> I'd like the terminal to mount the file system from the server.
>> When prompted for bootargs, when I provide "tls" I get the error message
>> "/bin/tlsclient: dial tcp!192.168.0.2!17020: connection refused".
>> My server runs the file system with options: local!/dev/sdE5/fs -m 7549
>> -A -a tcp!*!564
>> I think that means it will listen on *any* local interface, right?
>> Or do I need something different to get it to listen on ether1 instead of
>> ether0's tcp setup?
>>
>> Thanks,
>>   Paul
>>
>> On Tue, Apr 8, 2025 at 3:04 PM Paul Lalonde <paul.a.lalonde@gmail.com>
>> wrote:
>>
>>> I've tried that one as well, also to the same no-contact.
>>> So ipxe sees my host, at 192.169.0.2, but my Plan9 system doesn't.  When
>>> everything was plugged into the same subnet (ie, not using 2 interfaces on
>>> my host) I mounted files fine from there.
>>> I'm guessing I have a problem lower down in my stack.  I'll delve deeper.
>>>
>>> Paul
>>>
>>> On Tue, Apr 8, 2025, 3:01 p.m. <ori@eigenstate.org> wrote:
>>>
>>>> Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
>>>> > Ok, on to my next problem: Though I can get dhcpd and tftpd to serve
>>>> > happily from /net.alt, apparently I can't get aux/listen to do so.
>>>> >
>>>> > When my terminal tries to dial tcp!192.168.1.2!17020 I get a
>>>> connection
>>>> > refused.  This is the same IP that's serving dhcp and tftp.
>>>> > How do I get aux/listen to pay attention there?  It's listening
>>>> correctly
>>>> > on my other interface, where drawterm connects quite happily.
>>>> >
>>>> > Any suggestions?
>>>> >
>>>> 
>>>> aux/listen doesn't have a '-x' option but it does have a final arg that
>>>> lets
>>>> you pass the protocol and netstack.
>>>> 
>>>> aux/listen ... /net.alt/tcp
>>>> 
>>>> should work.
>>>> 
>>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M10157ad538948263a6e0aa31>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M42ed63229831b6f4156a90fd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 5719 bytes --]

Re: [9fans] Serving tftp on a second interface

[arnold]

Paul Lalonde <paul.a.lalonde@gmail.com> wrote:

> I neglected to add that tcp17020 is the tls trampoline that redirects to
> 564.
>
> So I suspect my tls handshake but don't know how to debug it.

Um, wireshark on Linux?

Arnold

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M18c36b96112f99466ceb5b67
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Serving tftp on a second interface

[Thaddeus Woskowiak]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

On Thu, Apr 10, 2025, 1:28 AM <arnold@skeeve.com> wrote:

> Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
>
> > I neglected to add that tcp17020 is the tls trampoline that redirects to
> > 564.
> >
> > So I suspect my tls handshake but don't know how to debug it.
> 
> Um, wireshark on Linux?
> 
> Arnold


snoopy(8) does the same thing without the Linux.

>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-M72bb5f1118669468eb0cc4e5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2257 bytes --]

Re: [9fans] Serving tftp on a second interface

[ori]

Quoth Thaddeus Woskowiak <tswoskowiak@gmail.com>:
> 
> snoopy(8) does the same thing without the Linux.

veering off topic -- also, snoopy can dump packets
into a pcap you can load in wireshark (and other
unix protocol analysis tools); this is useful for
the protocols snoopy isn't aware of.

(of course, if you're stubborn enough to add protocols
to snoopy, that's *very( appreciated)


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7d0bba710659dc0-Mcd1adfa375968375d9785498
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription