The pfinet server is a hacked Linux internet implementation with a glue layer translating between the Hurd RPCs and the middle layer of the Linux implementation.

Bugs

Those Listed on Open Issues

IPv6

IRC, freenode, #hurd, 2013-04-03

<braunr> youpi: there are indeed historical bugs with small packets and
  tcp_nodelay in linux 2.0/2.2 tcp/ip
<youpi> oh
<braunr> http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html

MAC Addresses

IRC, freenode, #hurd, 2013-09-21

<jproulx> what command will show me the MAC address of an interface?
<youpi> ah, too bad inetutils-ifconfig doesn't seem to be showing it
<youpi> I don't think we already have a tool for that
<youpi> it would be a matter of patching inetutils-ifconfig

Routing Tables

IRC, freenode, #hurd, 2013-09-21

<jproulx> 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?
<youpi> I don't think there is a tool for that yet
<youpi> it's not plugged inside pfinet anyway

IRC, freenode, #hurd, 2014-01-15

<braunr> 2014-01-14 23:06:38 IPv4 socket creation failed: Computer bought
  the farm
<braunr> :O
<youpi> hum :)
<youpi> perhaps related with your change for "lo" performance?
<braunr> unlikely
<youpi> I don't see what would have changed in pfinet otherwise
<braunr> mig generated code if i'm right
<braunr> lib*fs
<braunr> libfshelp
<braunr> looks plenty enough
<braunr> teythoon's output has been quite high, it's not so suprising to
  spot such integration issues

IRC, freenode, #hurd, 2014-01-16

<braunr> teythoon: so, did you see we have bugs on the latest hurd packages
  :)
<braunr> for some reason, exim4 starts nicely on darnassus, but not on
  another test vm
<braunr> and there is a "deallocate invalid name" error at boot time
<braunr> it's also present with your packages
<teythoon> yes

<braunr> not being able to start exim4 and other servers on some machines,
  apparently randomly, is a bit frightening to me
<braunr> as the message says, "most probably a bug"
<teythoon> yes
<braunr> so we have to get rid of it as soon as possible so we can get to
  the more interesting stuff
<teythoon> but there is no way to attribute this message to a process
<braunr> well, for those at boot time, there is
<teythoon> ?
<braunr> if i disable exim, i don't get it :p
<teythoon> oh ?
<braunr> but again, it doesn't occur on all machines
<braunr> and that part is the one i don't like at all
<teythoon> still, is it in exim, pfinet, pflocal, ... ?
<teythoon> no way to answer that
<braunr> ah right sorry
<braunr> it's probably pfinet, since exim says computer bought the farm on
  a socket
<braunr> pflocal had its same pid
<teythoon> ok
<braunr> and after an upgrade, i don't reproduce that
<braunr> good, in a way
<braunr> there still is the one, after auth
<teythoon> yes
<teythoon> i'm seeing that too
<braunr> (as in "exec init proc auth"
<braunr> shouldn't be too hard to fix
<braunr> i'll settle on this one after i'm done with libps
<gnu_srs> (15:21:34) braunr: it's probably pfinet, since exim says computer
  bought the farm on a socket:
<gnu_srs> remember my having problems with removing a socket file, maybe
  related, probably not pfinet then?
<braunr> gnu_srs: unlikely
<braunr> that pfinet bug may have been completely transient
<braunr> fixed by upgrading packages
<gnu_srs> braunr: k!

<braunr> and exim4 keeps crashing on my hurd instance at home
<braunr> (pfinet actually)
<braunr> uh, ok, a stupid typo ..
<braunr> teythoon: --natmask in the /servers/socket/2 node, but correct
  options in the 26 one .... :)

IRC, freenode, #hurd, 2014-01-17

<teythoon> braunr: *phew*

Reimplementation, GNU Savannah task #5469

tcp ip stack

IRC, freenode, #hurd, 2013-04-03

<youpi> I was thinking about just using liblwip this afternoon, btw
<braunr> what is it ?
<braunr> hm, why not
<braunr> i would still prefer using code from netbsd
<braunr> especially now with the rump kernel project making it even easier

user-space device drivers, External Projects, The Anykernel and Rump Kernels.

<youpi> well, whatever is easy to maintain up to date actually
<braunr> netbsd's focus on general portability normally makes it easy to
  maintain
<braunr> the author of the rump project was able to make netbsd code run in
  browsers :)
<braunr> and he actually showed clients using the networking stack on
  windows, remotely (not in the same process)
<braunr> so that's very close to what we want
<youpi> indeed
<youpi> though liblwip is exactly the same portability focus :)
<braunr> apparently, for embedded systems
<youpi> but bsd's code is probably better
<youpi> yes
<braunr> i think so, more general purpose, larger user base
<youpi> I used it for the stubdomains in Xen
<youpi> (it = lwip)
<braunr> ok

Cloudius OSv apparently have isolated/re-used a BSD networking stack, http://www.osv.io/, https://github.com/cloudius-systems/osv.

IRC, freenode, #hurd, 2014-02-06

<akshay1994> 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. 
<braunr> akshay1994: what are you interested in ?
<akshay1994> I was going through the project ideas. Found TCP/IP Stack, and
  CD Audio grabbing interesting.
<braunr> cd audio grabbing ?
<braunr> hm why not
<braunr> akshay1994: you have to understand that, when it come to drivers,
  we prefer reusing existing implementations in contained servers than
  rewriting ourselves
<braunr> the networking stack project would be very interesting, yes
<akshay1994> Yes. I was indeed reading about the network stack. 
<akshay1994> So we need an easily modularise-able userspace stack, which we
  can run as a server for now. 
<akshay1994> And split into different protocol layers later.
<braunr> hum no
<braunr> we probably want to stick to the model we're currently using with
  pfinet
<braunr> for network drivers, yes
<braunr> i strongly suspect we want the whole IPv4/IPv6 networking stack in
  a single server
<braunr> and writing glue code so that it works on the hurd
<braunr> then, you may want to add hooks for firewall/qos/etc...
<braunr> (although i think qos should be embedded to)
<braunr> 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
<braunr> the rump project might make porting even easier

user-space device drivers, External Projects, The Anykernel and Rump Kernels.

<akshay1994> 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
<braunr> a true hurdish stack would
<braunr> i strongly doubt we'll ever have the man power to write one
<braunr> i don't really see the point either to be honest :/
<akshay1994> haha! 
<braunr> but others have better vision than me for these things so i don't
  know
<akshay1994> So, what are the problems we are facing with the current
  pfinet implementation?
<braunr> it's old
<braunr> meaning it doesn't implement some features that may be important,
  and has a few bugs due to lack of maintenance
<braunr> 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 :)
<akshay1994> 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!
<braunr> yes
<braunr> the very idea of a userspace stack itself has little implications
<braunr> 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

<akshay1994> 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
<akshay1994> But i feel, I'll get over it. Any tips?
<braunr> akshay1994: it's not straightforward
<akshay1994> 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

<antrik> 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
<braunr> antrik: i don't see how something like the current pfinet would
  prevent that

IRC, freenode, #hurd, 2013-10-31

<braunr> looks like there is a deadlock in pfinet
<braunr> maybe triggered or caused by my thread destruction patch

?fix have kernel resources.