[[!meta copyright="Copyright © 2000, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] The `pfinet` server is a hacked Linux internet implementation with a glue layer translating between the Hurd [[RPC]]s and the middle layer of the Linux implementation. # Bugs ## Those Listed on [[Open_Issues]] ## [[IPv6]] ## IRC, freenode, #hurd, 2013-04-03 youpi: there are indeed historical bugs with small packets and tcp_nodelay in linux 2.0/2.2 tcp/ip oh http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html ## MAC Addresses [[!tag open_issue_hurd]] ### IRC, freenode, #hurd, 2013-09-21 what command will show me the MAC address of an interface? ah, too bad inetutils-ifconfig doesn't seem to be showing it I don't think we already have a tool for that it would be a matter of patching inetutils-ifconfig ## Routing Tables [[!tag open_issue_hurd]] ### IRC, freenode, #hurd, 2013-09-21 Hmmm, OK I can work around that, what about routing tables, can I see them? can I add routes besides the pfinet -g default route? I don't think there is a tool for that yet it's not plugged inside pfinet anyway ## IRC, freenode, #hurd, 2014-01-15 2014-01-14 23:06:38 IPv4 socket creation failed: Computer bought the farm :O hum :) perhaps related with your change for "lo" performance? unlikely I don't see what would have changed in pfinet otherwise mig generated code if i'm right lib*fs libfshelp looks plenty enough teythoon's output has been quite high, it's not so suprising to spot such integration issues ### IRC, freenode, #hurd, 2014-01-16 teythoon: so, did you see we have bugs on the latest hurd packages :) for some reason, exim4 starts nicely on darnassus, but not on another test vm and there is a "deallocate invalid name" error at boot time it's also present with your packages yes not being able to start exim4 and other servers on some machines, apparently randomly, is a bit frightening to me as the message says, "most probably a bug" yes so we have to get rid of it as soon as possible so we can get to the more interesting stuff but there is no way to attribute this message to a process well, for those at boot time, there is ? if i disable exim, i don't get it :p oh ? but again, it doesn't occur on all machines and that part is the one i don't like at all still, is it in exim, pfinet, pflocal, ... ? no way to answer that ah right sorry it's probably pfinet, since exim says computer bought the farm on a socket pflocal had its same pid ok and after an upgrade, i don't reproduce that good, in a way there still is the one, after auth yes i'm seeing that too (as in "exec init proc auth" shouldn't be too hard to fix i'll settle on this one after i'm done with libps (15:21:34) braunr: it's probably pfinet, since exim says computer bought the farm on a socket: remember my having problems with removing a socket file, maybe related, probably not pfinet then? gnu_srs: unlikely that pfinet bug may have been completely transient fixed by upgrading packages braunr: k! and exim4 keeps crashing on my hurd instance at home (pfinet actually) uh, ok, a stupid typo .. teythoon: --natmask in the /servers/socket/2 node, but correct options in the 26 one .... :) ### IRC, freenode, #hurd, 2014-01-17 braunr: *phew* # Reimplementation, [[!GNU_Savannah_task 5469]] ## [[community/gsoc/project_ideas/tcp_ip_stack]] ## IRC, freenode, #hurd, 2013-04-03 [[!tag open_issue_hurd]] I was thinking about just using liblwip this afternoon, btw what is it ? hm, why not i would still prefer using code from netbsd especially now with the rump kernel project making it even easier [[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel and Rump Kernels*. well, whatever is easy to maintain up to date actually netbsd's focus on general portability normally makes it easy to maintain the author of the rump project was able to make netbsd code run in browsers :) and he actually showed clients using the networking stack on windows, remotely (not in the same process) so that's very close to what we want indeed though liblwip is exactly the same portability focus :) apparently, for embedded systems but bsd's code is probably better yes i think so, more general purpose, larger user base I used it for the stubdomains in Xen (it = lwip) ok Cloudius OSv apparently have isolated/re-used a BSD networking stack, , . ## IRC, freenode, #hurd, 2014-02-06 Hello Everyone! Just set up my Hurd system. I need some help now, in selecting a project on which i can work, and delving further into this. akshay1994: what are you interested in ? I was going through the project ideas. Found TCP/IP Stack, and CD Audio grabbing interesting. cd audio grabbing ? hm why not akshay1994: you have to understand that, when it come to drivers, we prefer reusing existing implementations in contained servers than rewriting ourselves the networking stack project would be very interesting, yes Yes. I was indeed reading about the network stack. So we need an easily modularise-able userspace stack, which we can run as a server for now. And split into different protocol layers later. hum no we probably want to stick to the model we're currently using with pfinet for network drivers, yes i strongly suspect we want the whole IPv4/IPv6 networking stack in a single server and writing glue code so that it works on the hurd then, you may want to add hooks for firewall/qos/etc... (although i think qos should be embedded to) sjbalaji: i also suggest reusing the netbsd networking stack, since netbsd is well known for its clean portable code, and it has a rather large user base (compared to us or other less known projects) and is well maintained the rump project might make porting even easier [[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel and Rump Kernels*. okay! I was reading the project idea, where they mention that a true hurdish stack will use a set of translator processes , each implementing a different protocol layer a true hurdish stack would i strongly doubt we'll ever have the man power to write one i don't really see the point either to be honest :/ haha! but others have better vision than me for these things so i don't know So, what are the problems we are facing with the current pfinet implementation? it's old meaning it doesn't implement some features that may be important, and has a few bugs due to lack of maintenance maintenance here being updating the code base with a newer version, and we don't particularly want to continue grabbing code from linux 2.2 :) I see. I was just skimming through google, about userspace network stacks, but I think I might need to first understand how the current one works and interacts with the system, before proceeding further! yes the very idea of a userspace stack itself has little implications it basically means it doesn't run in system mode, and instead of directly calling functions, it uses RPCs to communicate with other parts of the system braunr: I looked at the netBSD net-stack, and also how hurd (and mach) work. I'm starting with the hacking guide. Seems a little difficult :p But i feel, I'll get over it. Any tips? akshay1994: it's not straightforward I know. Browsing through pfinet gave me an idea, how complex a thing I'm trying to deal with in first try :p ### IRC, freenode, #hurd, 2014-02-09 braunr: the point of a hurdisch network stack is the same as a hurdish block layer, and in fact anything hurdish: you can do things like tunelling in a natural manner, rather than needing special loopback code and complex control interfaces antrik: i don't see how something like the current pfinet would prevent that # IRC, freenode, #hurd, 2013-10-31 looks like there is a deadlock in pfinet maybe triggered or caused by my thread destruction patch [[open_issues/libpthread/t/fix_have_kernel_resources]].