[[!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

    <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

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

In context of the item on [[/contributing]].

    <rekado> About this task: "Make pfinet OK with the ethernet device going
      away." --- how can I test this? How can I remove the ethernet device?
    <pinotree> settrans on the ethernet device, handled by the netdde
      translator
    <pinotree> that is, make it go away (settrans -fg)
    <rekado> Ah, I see.
    <rekado> Thanks
    <pinotree> check its status before with showtrans
    <pinotree> then, after having made it go away, set it again
    <rekado> I don't think I'm doing this right... After `settrans -fg
      /dev/eth0` I should not be able to access the network anymore, but it
      still works.
    <rekado> How can I figure out which of the four network devices is actually
      used?
    <braunr> rekado: the file system is used to open files, i.e. access
      services
    <braunr> it's not used to revoke access
    <braunr> once pfinet has obtained a port to the network device, it keeps it
    <rekado> oh, yes, of course.  Sorry, this is all very
      new to me.
    <rekado> I'm not sure what the problem is that this task describes.  In
      what way is pfinet "not OK" with the ethernet device going away?
    <braunr> rekado: the idea is to make pfinet able to cope with a driver
      crash
    <rekado> Can I trigger a driver crash for test purposes? (Or do I have to
      build a purposefully broken driver first?)
    <braunr> use kill
    <rekado> Oh, good.
    <braunr> iirc, netdde doesn't restart correctly :x
    <braunr> you'll probably have to fix it a bit
    <braunr> i guess there is some persistent state that prevents it from
      reinitializing correctly
    <rekado> okay
    <rekado> I may need one more pointer: where can I find the netdde code?
      Grep'ing around I only see it only mentioned as an argument to
      /hurd/devnode; also: should I work in some incubator branch or directly
      in the hurd repo?
    <braunr> rekado: incubator branch
    <rekado> Okay. Thank you for your patience.  I'll play with this in the
      next few days.
    <braunr> enjoy
    <rekado> :)


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

    <rekado> When I kill the /hurd/netdde process I can no longer access the
      network (as expected);
    <rekado> To restore connectivity I run "settrans -g eth0 /hurd/devnode -M
      /dev/netdde eth0" from the /dev directory.
    <rekado> When I access the network again everything is fine. (I do see a
      message telling me "irq handler 11: release an dead delivery port"
    <rekado> )
    <rekado> Is it the goal to avoid having to run settrans again to run netdde
      after it crashes or is killed?
    <youpi> you don't need to run settrans again
    <youpi> that should get triggered automatically
    <rekado> Hmm, after killing netdde I get "Resource lost" when using wget.
    <rekado> It doesn't seem to be restarted automatically.
    <youpi> try again
    <youpi> the first wget makes pfinet try to use netdde and fail, thus crash
    <youpi> the second wil respawn pfinet
    <youpi> ideally pfinet shouldn't die, that's a TODO mentioned in the
      "contributing page"
    <rekado> Ah, so that's what should be prevented.
    <youpi> it's just a matter of making pfinet be fine with errors from the
      eth translator, and simply reopen it instead of dying
    <rekado> That's the thing I've been trying to figure out.
    <rekado> when I run wget a second (or third) time I get a different error;
      "Name or service not known."
    <rekado> It's only okay again when I use settrans
    <youpi> maybe the devnode translator also needs some fixing
    <youpi> it's odd that I don't have the issue though
    <rekado> I'm using the qemu image, updated just yesterday.
    <youpi> same here
    <youpi> anyway, now you know where to put your hands :)
    <rekado> yes, thanks a lot.


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

    <rekado> in pfinet/ethernet.c:ethernet_open there's an assertion:
      edev->ether_port == MACH_PORT_NULL
    <rekado> This is violated when netdde was killed and the device is
      reopened.
    <rekado> I'm not sure what should be done: destroy the port before
      reopening or drop the assertion?
    <rekado> If I drop the assertion, Mach seems to handle this just fine.
    <rekado> Says "irq handler 11: release an [sic] dead delivery port" and
      then carries on without problems.
    <rekado> Is this a warning or an error, or can this be ignored?
    <rekado> (or none of the above?)


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

    <rekado> I have a simple patch for pfinet that lets it recover from an
      error in ethernet_xmit when /hurd/netdde and /hurd/devnode have been
      killed.
    <rekado> It doesn't work, though, when only netdde has been killed.
    <rekado> With devnode still around device_open fails with "(ipc/send)
      invalid destination port"
    <rekado> I don't know where device_open is defined and why this error is
      returned.
    <rekado> I guess the error refers to the "master_device" port returned by
      file_name_lookup() in ethernet_open()
    <rekado> Why would file_name_lookup() return an invalid port when netdde is
      dead but devnode is still running?
    <braunr> rekado: maybe because devnode needs to perform a fresh lookup as
      well


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

    <rekado> braunr: re devnode: devnode only performs a single lookup in
      parse_opt(), i.e. at start-up.
    <rekado> I'll try to understand devnode enough to patch it.
    <braunr> rekado: that's the problem
    <braunr> it should perform a lookup every time it's opened

[[!message-id "1378730237-8091-1-git-send-email-rekado@elephly.net"]],
[[!message-id "1378731824-8928-1-git-send-email-rekado@elephly.net"]].

    <rekado> I submitted two patches to the mailing list.  I've tested them on
      Debian GNU/Hurd but based them on the incubator/dde branch.
    <teythoon> rekado: awesome, reliability fixes are very much welcome


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

    <rekado> youpi: my apologies for the delay in getting back to you with
      improvements to my pfinet/devnode patches. Been very busy.
    <braunr> rekado: development pace on the hurd has always been slow, no need
      to apologize


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

    <braunr> youpi: btw, the patch you finally decided to write yourself making
      pfinet continue on driver failure is as expected quite handy :)
    <youpi> :)


## MAC Addresses

[[!tag open_issue_hurd]]


### 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

[[!tag open_issue_hurd]]


### 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]]

## [[community/gsoc/project_ideas/tcp_ip_stack]]

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

[[!tag open_issue_hurd]]

    <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

[[open_issues/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

[[open_issues/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

[[open_issues/libpthread/t/fix_have_kernel_resources]].