IRC channel logs


back to list of logs

***jrtc27_ is now known as jrtc27
***nckx_ is now known as nckx
<biblio>demo22: youpi: I was able to fix build error of libmnl but could not make deb package yet. getting - dpkg-genbuildinfo: error: binary build with no binary artifacts found; .buildinfo is meaningless
<damo22>biblio: how are you compiling the deb pacakge
<biblio>damo22: dpkg-buildpackage -us -uc
<damo22>did you clone from
<biblio>damo22: no I got it from apt-get source libmnl
<damo22>that should work
<biblio>damo22: I also tried by add CPPFLAGS in debian/rules - still could not make it work
<damo22>are you on hurd
<biblio>damo22: adding*
<damo22>or cross building
<biblio>damo22: yes latest img
<biblio>damo22: no inside Hurd
<youpi>biblio: netfilter is linux-only, libmnl won't ever work on the hurd
<youpi>that said it's odd that you don't get an arch:any package built
<biblio>youpi: oh. i saw it is a required package for iproute2 and iproute2 is marked as TODO.
<biblio>youpi: ok i will check other packages from TODO. thanks for the info.
<damo22>im guessing there is something missing in netdde for the translator to accept a route entry?
<youpi>again, netdde only contains drivers
<youpi>it's pfinet that contains the tcp/ip stack
<damo22>what opens pfinet?
<damo22>not the right question
<damo22>what uses servers/socket/* to manipulate pfinet stack?
<youpi>or you mean to configure it?
<youpi>inetutils-ifoncifg and friends
<damo22>yes to configure it
<youpi>(and dhclient)
<biblio>youpi: I could not find any package in inetutils for adding routes.
<biblio>youpi: it would be nice they inetutils provides inetutils-route or something similar.
<youpi>it's a matter of contributing it
<biblio>youpi: ok :)
<damo22>i found ifconfig inside that package with hurd support but it seems turned off
<biblio>damo22: ifconfig works
<biblio>damo22: inetutils-ifconfig
<damo22>how? it does not install on my system
<youpi>it does on my and freshboxes
<biblio>damo22: just install inetutils-tools
<damo22>root@zamhurd:~# apt install inetutils-ifconfig
<damo22>E: Unable to locate package inetutils-ifconfig
<damo22>root@zamhurd:~# apt install inetutils-tools
<damo22>inetutils-tools is already the newest version (2:2.3-4).
<biblio>demo22: dpkg -L netutils-tools
<biblio>demo22: dpkg -L inetutils-tools
<biblio>damo22: :D
<damo22>biblio: ioctl(skfd, SIOCADDRT, &rt)
<damo22>or deleting a route ioctl(skfd, SIOCDELRT, &rt)
<biblio>damo22: got it.
<damo22>just need to populate the rt with the right data
<biblio>damo22: clear.
<damo22>see net-tools/lib/inet_sr.c
<biblio>damo22: ok
<damo22>i cant find the definition for the struct rtentry
<damo22>#define CONFIG_IP_NOSIOCRT 1 /* How convenient. */ in pfinet config.h
<damo22>so hurd's pfinet has no ioctl for setting routes?
<youpi>I guess just nobody took the time to look at it
<damo22>biblio: see hurd-debian/pfinet/linux-src/net/ipv4
<damo22>grep for NOSIOCRT
<biblio>damo22: ok
<biblio>damo22: i am looking in my /user/include which location you is your hurd-debian ?
<damo22>biblio: i mean the debian "hurd" package
<biblio>damo22: ok
<biblio>damo22: i will have a look
<biblio>damo22: could you share the location of the file. I got bit confused now :(
<biblio>damo22: thanks
<damo22>i am going to try rebuilding pfinet with that undeffed
<biblio>damo22: ok
<damo22>ok it fails due to missing SIOCxxxRT definitions
<damo22>but they are just two numbers
<gnu_srs1>damo22: biblio: Isn't it more interesting to replace pfinet with lwip?
<gnu_srs1>Dunno however if lwip supports route.
<damo22>there is no reason to keep it broken
<damo22>so we fix it
<damo22>if i was going to replace pfinet i would use rumpnet
<gnu_srs1>I assumed lwip is the future since pfinet contains Linux code?
<biblio>gnu_srs1: I am new to lwip. thanks for mentioning.
<damo22>im building pfinet having SIOCADDRT
<damo22>and DEL
<damo22>we'll see if it links shortly
<damo22>/usr/bin/ld: fib_frontend.o: in function `ip_rt_ioctl':
<damo22>./build-udeb/pfinet/../../pfinet/linux-src/net/ipv4/fib_frontend.c:263: undefined reference to `rtnl_lock'
<damo22>/usr/bin/ld: ./build-udeb/pfinet/../../pfinet/linux-src/net/ipv4/fib_frontend.c:280: undefined reference to `rtnl_unlock'
<damo22>maybe i can define those as macros with noops
<biblio>damo22: it would be also possible $ apt-cache search linux | grep headers
<biblio>damo22: install # apt-get install linux-headers-5..xx-common in hurd. and then you can check the actual value in latest kernel. I am not sure if it will be best way to do it. Just an idea.
<damo22>there is code already in pfinet
<damo22>we are not using it
<biblio>damo22: ok
<damo22>its turned off behind that #define
<biblio>damo22: ok
<damo22>but im not sure how the ioctl gets hooked up
<damo22>i think i made it compile and link with the existing code
<damo22>which means we can call ip_rt_ioctl somehow
<damo22>it used to be returning EINVAL
***valerius- is now known as valeriusN
<damo22>youpi: i invented two separate ioctls for "default gw" and "static" routing
<damo22>but what do i number them?
<damo22>SIOCADDRT is supposed to do both
<damo22>it was easier to just write two separate functions
<youpi>the structure parameter of SIOCADDRT allows to know between the two, doesn't it?
<damo22>yea but it needs a huge structure
<damo22>actually i cant find the structure it wants
<damo22>but iioctl server has them defined for all other ones
<youpi>isn't it what ip_rt_ioctl manages?
<damo22>we are not using the linux ioctls,
<youpi>so struct rtentry
<damo22>i need to add something to iioctl.defs
<damo22>i implemented these:
<damo22>iioctl-ops.c:S_iioctl_siocaddrt_def_gw (struct sock_user *user,
<damo22>iioctl-ops.c:S_iioctl_siocaddrt_static (struct sock_user *user,
<damo22>iioctl-ops.c:S_iioctl_siocdelrt_def_gw (struct sock_user *user,
<damo22>iioctl-ops.c:S_iioctl_siocdelrt_static (struct sock_user *user,
<damo22>unless i just pass a flag to it to choose
<damo22>and combine them
<damo22>there is no point reusing the old structure for the ioctl surely, it just needs an address and an ifnam and a sock_user, and a flag that says if its a default gw or static route?
<damo22>ok, i think i can handle this, but what number are the two ioctls SIOCADDRT and SIOCDELRT?
<youpi>it's computed automatically from the structure content by the _IOR/W macros
<damo22>ok but there are skips in the iioctl.defs file, i dont want to use a ioctl that has a different meaning just by throwing it on the end?
<youpi>the numbering is following the bsd numbers
<youpi>see SIOCSIFADDR etc. in there
<damo22>found it
<damo22>can pfinet options.c call iioctl_U.h ?
<damo22>or is that making a rpc to itself?
<damo22>i want to deduplicate the routing code from options.c
<youpi>? pfinet is not supposed to make ioctl calls
<youpi>it's glibc on the client side, where ioctl is turned into an iioctl RPC
<youpi>that calls into an iioctl on the server side
<youpi>ending up in S_iioctl_* function call, e.g. in pfinet
<damo22>ok so pfinet has to set up routes etc which is exactly the code in S_iioctl_siocaddrt
<damo22>do i break it out into a function so pfinet internals can call it?
<damo22>the new function
<youpi>what new function?
<damo22>i implemented S_iioctl_siocaddrt from scratch
<damo22>but it needs to be also called from options.c
<youpi>then just call it?
<damo22>as well as being a server implementation
<youpi>then create a function that can be called both from S_iioctl_siocaddrt and from options.c ?
<damo22>it still works! and i refactored options.c
<biblio>damo22: nice
<damo22>hmm how do i generate iioctl_U.h ?
<damo22>what needs to call the iioctl? glibc?
<damo22>how do i test the new rpc
<youpi>damo22: I don't understand where you got that iioctl_U.h name from
<youpi>to call an iioctl, you just have to call the ioctl
<youpi>ioctl() in the glibc happens to turn that into an iioctl call, as I mentioned above
<Pellesco1rs>damo22: can you remember what need to be done with rump to use the rump ide driver instead of the linux one? I remember a discussion about Makefile to separate something into 2 distincts libs
<damo22>currently the symbols are included twice from cd and wd because they are compiled into both
<damo22>ahcisata and piixide
<damo22>they need to be separated into separate libs so we can link them as needed
<Pellesco1rs>so introduce a 3rd lib that ide and ahci will link to, right?
<damo22>probably "ata" as a lib too
<Pellesco1rs>and to run the piixide rump driver, rumpdisk can be modified to use it and expose the cd devices?
<damo22>it only needs to link to the right libs, it will detect the ide card
<Pellesco1rs>Ah found, it’s currently disabled through a #if 0
<Pellesco1rs>I will try to make it working :D
<damo22>in theory we can compile in both libs
<damo22>and it will detect all disks
<damo22>and all controllers for disks
***Pellesco1rs is now known as Pellescours