IRC channel logs

<damo22>youpi: i have a hurd branch that is getting close, rumpnet... it currently fails pfinet with "cannot configure device"

<damo22>if device_set_filter is a no-op, will that allow all packets?

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

<youpi>damo22: depends how you made rumpnet to get packets from the raw socket :)

<ZhaoM>hello

<sneek>ZhaoM, you have 2 messages!

<sneek>ZhaoM, gnucode says: Nicely done! How well does luakit work on the Hurd?

<sneek>ZhaoM, gnucode says: nice job on the rtc by the way! That was a very quick 1st contribution!

<ZhaoM>gnucode: I haven't got much time to use it. What I can say now is it works ;)

<gnucode>ZhaoM: that's awesome!

<gnucode>How hard was it to get it running?

<gnucode>got to go

<ZhaoM>it's not hard, the issue with apt install is version restriction

<ZhaoM>i just compile lua-filesystem luajit and luajit from source

<damo22>root@zamhurd:~# ifup /dev/wm0

<damo22>inetutils-ifconfig: SIOCSIFADDR failed: Error in unknown error system: FFFFF63C

<damo22>ifup: failed to bring up /dev/wm0

<damo22>E_IO_ERROR

<damo22>D_IO_ERROR *

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

<damo22>/hurd/pfinet: ../../pfinet/ethernet.c:299: ethernet_xmit: Unexpected error: Dest

<damo22>ination address required.

<damo22>EDESTADDRREQ

<damo22>it seems like rumpnet doesnt want to use the raw socket to send packets to the NIC, it wants to use its own network stack

<damo22>youpi: i think rump does not support AF_ETHER, ie sending raw ethernet frames to the NIC over a raw socket

<damo22>(06:57:46 PM) mlelstv: there is AF_LINK with SOCK_DGRAM, but it doesn't implement sending or receiving

<damo22>(06:58:37 PM) mlelstv: that's why programs like dhclient use BPF for sending and receiving.

<damo22> https://github.com/NetBSD/src/blob/trunk/external/mpl/dhcp/dist/common/bpf.c this might work

<azert>damo22: do their ip stack uses bpf for everything inside? Or is it just the user programs?

<sneek>azert, you have 3 messages!

<sneek>azert, ZhaoM says: ah indeed they can implement other chips in the same binary. They'd probably add --option so the same translator can act as different rtc drivers. I supposed implmenting a new rtc driver will need to create a new translator.

<sneek>azert, ZhaoM says: thanks for reminding me, I will still call it rtc and submit a new patch.

<sneek>azert, ZhaoM says: but I think for extensibility, I will still modify the name of the server-side implementation file (i.e. pioctl-ops.c to rtc-cmos-pioctl-ops.c) so people can know it's cmos specific

<azert>damo22: it could be that mlelstv didn’t really understand your question, I can understand that they disabled raw packet read write outside bpf for security/encapsulation reasons

<azert>but here we are not talking about userspace, Hurd is the kernel. You could ask if there is a way to hook directly into the device driver behind bpf

<Pellescours>maybe a #define?

<Pellescours>I was doing a git clone, and my WM froze after downloading, during update of files. Activating the debugger, and it seems that the kernel is in an infinite loop at vm_page_balance

<Pellescours>it loop doing: movl 0x8(%ebx),%eax; testl %eax,%eax; jnz vm_page_balance+0x4a0; repe nop; movl 0x8(%ebx),%eax; ...

<Pellescours>stopped at vm_page_balance+0x4a2 (for the movl instruction)

<damo22>azert: AF_LINK with SOCK_DGRAM should be the right pathway, but it doesnt support sending or receiving packets

<damo22>so thats why programs use bpf

<damo22>basically we can rump_sys_open(/dev/bpf) and bind wm0 to that, and use read() and write() to send packets

<damo22>rump_sys_read() *

IRC channel logs

2024-12-01.log