[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation,
[[!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
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
## Those Listed on [[Open_Issues]]
## 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
## 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
<pinotree> that is, make it go away (settrans -fg)
<rekado> Ah, I see.
<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
<rekado> How can I figure out which of the four network devices is actually
<braunr> rekado: the file system is used to open files, i.e. access
<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
[1;5C[1;5C[1;5C[1;5Cnew 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
<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
<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.
### 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> 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
<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
<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
<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
<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
### 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
<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
## 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
# Reimplementation, [[!GNU_Savannah_task 5469]]
## 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
<youpi> well, whatever is easy to maintain up to date actually
<braunr> netbsd's focus on general portability normally makes it easy to
<braunr> the author of the rump project was able to make netbsd code run in
<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> though liblwip is exactly the same portability focus :)
<braunr> apparently, for embedded systems
<youpi> but bsd's code is probably better
<braunr> i think so, more general purpose, larger user base
<youpi> I used it for the stubdomains in Xen
<youpi> (it = lwip)