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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > > > > On Tue, Apr 08, 2025 at 08:20:20AM +0200, [email protected] > <mailto:[email protected]> 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
