IRC channel logs

<mgjertson>Does GNUboot support the hurd?

<damo22>stick around for longer than 6 minutes and maybe someone will answer your question

<Pellesco1rs>damo22: I saw your recent changes for rumpnet, what is the status currently?

<damo22>status is the driver works, but its slow

<damo22># showtrans /dev/wm0

<damo22>/hurd/devnode -M /dev/rumpnet wm0

<damo22>settrans -fgap /servers/socket/2 /hurd/pfinet -i /dev/wm0

<damo22>showtrans /dev/rumpnet

<damo22>/hurd/rumpnet.static

<damo22>then ifup /dev/wm0

<damo22>* f66b62b9 (zammit/rumpnet) rumpnet: Ignore rcv errors due to not enough bandwidth in software stack

<damo22>it seems to work in full smp as well but just as slow

<damo22>ah my server is down :(

<damo22>fixed

<damo22>Pellesco1rs: https://git.zammit.org/hurd-sv.git/log/?h=rumpnet

<azert>damo22: now that you fixed the debug symbol issue, it’s probably possible to gprof rumpnet

<azert>to see where it spends its time

<youpi>damo22: what do you mean by "slow" ? is that slower than netdde?

<youpi>possibly it's just pfinet's tcp/ip which is not aggressive enough to reach large bandwidth

<damo22>youpi: its very slow, like kB/s instead of MB/s

<youpi>ok, that's slow :)

<youpi>possibly an issue similar to rumpusbdisk being slow

<damo22>but only on external internet, if i scp to the box its MB/s

<damo22>maybe that uses pflocal?

<youpi>scp uses tcp/ip anyway

<youpi>so it can't be pflocal

<damo22>okay

<youpi>but if lan transfer is fine, it can indeed be a tcp/ip tuning issue

<youpi>can be worth trying lwip

<damo22>btw my server was down again and its fixed now

<damo22>ERROR: ethernet frame has wrong protocol: 0x86dd

<youpi>that's ipv6

<damo22>how do i set up ipv4 on /servers/socket/2 ?

<damo22>with lwip

<youpi>I don't know, I guess it uses the same syntax as pfinet

<youpi>so the same settrans

<damo22>-4 wants a parameter to the socket/x

<damo22>but i am already using settrans

<damo22> -4, --ipv4=NAME Put active IPv4 translator on NAME

<damo22>settrans -fgap /servers/socket/26 /hurd/lwip -i /dev/wm0 -4 /servers/socket/2

<damo22>that still gives me that error

<youpi>I don't think the problem is the way the translator is set up, but most probably merely because nobody tested lwip on a network that has ipv6 packets floating around

<damo22>the error is from my translator

<damo22>because i told it to print that when it sees wrong protocol

<youpi>then fix it?

<damo22>ok so if it sees ipv6 it should continue

<youpi>well, yes?

<youpi>receiving ipv6 is not unexpected

<damo22>ok

<youpi>you could even receive some stp frames, and whatnot

<youpi>it'd be an easy DoS if you crash on any unknown frame type :)

<damo22>it doesnt crash, it returns EPROTO on send_packet

<damo22>so somehow its trying to send ipv6

<damo22>currently i allow ipv4 and arp

<damo22>i dont want an ipv6 stack right now

<youpi>then just ignore it

<damo22>ok i will look at lwip source and see what is going on

<youpi>what do you mean?

<youpi>it's only normal today that a tcp/ip stack tries to do some ipv6

<youpi>you can just ignore it

<damo22>the dhcp client tries to use ipv6 with lwip but not with pfinet

<damo22>settrans -fgap /servers/socket/2 /hurd/lwip -i /dev/wm0

<youpi>dhcp doesn't do ipv6

<youpi>it's the tcp/ip stack which does some neigbor discovery which is only expected

<damo22>ok but the dhcp request fails because it cant send the ipv6 packets, do i just let it send some ipv6?

<youpi>yes

<damo22>DHCPDISCOVER on /dev/wm0 to 255.255.255.255 port 67 interval 5

<damo22>send_packet: No route to host

<damo22>dhclient.c:2600: Failed to send 300 byte long packet over /dev/wm0 interface.

<youpi>juist

<youpi>ignore

<youpi>it

<youpi>DHCPDISCOVER is not ipv6

<damo22>lol

<youpi>it's ipv4

<youpi>possibly you *also* have ipv6 frames floating around

<youpi>but *MOST

<youpi>*

<youpi>probably

<youpi>it's just lwip that happens to do some ipv6

<youpi>just becaus why not

<youpi>just ignore it.

<damo22>ok lwip as a dropin replacement for pfinet fails to send packet for dhcp discover

<damo22>no route to host

<damo22>it does the same with netdde

<Pellescours>damo22: lwip_S_pfinet_getroutes is not implemented, maybe that can have an impact?

<Pellescours>lwip_S_rioctl_siocaddrt and lwip_S_rioctl_siocaddrt (methods to add and delete routes) neither

<youpi>that's not really a problem

<youpi>lwip can still use the simple classical case: one network and one default route

<youpi>here the destionation is 255.255.255.255, that's not related to routes, it's just a broadcast

<diegonc>I've broken the system after updating libc :(

<diegonc>time to update the base image I guess hehe

<diegonc>hmm what happened to /dev/shm? it's no longer a tmpfs (link to /tmp which isn't tmpfs either)

<diegonc>(currently running debian-hurd-amd64-20250624)

<Pellescours>diegonc: tmpfs has issues (with mmap but deleted files lost), so to keep the system stable we can’t use tmpfs for now

<diegonc>Pellescours: thanks for the details :-)

IRC channel logs

2025-07-05.log