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 <[email protected]> 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 <[email protected]> > 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 < > [email protected]> 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 <[email protected]> > 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
