[[!meta copyright="Copyright © 2000, 2008, 2013 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 ## IRC, freenode, #hurd, 2013-09-03 In context of the item on [[/contributing]]. About this task: "Make pfinet OK with the ethernet device going away." --- how can I test this? How can I remove the ethernet device? settrans on the ethernet device, handled by the netdde translator that is, make it go away (settrans -fg) Ah, I see. Thanks check its status before with showtrans then, after having made it go away, set it again 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. How can I figure out which of the four network devices is actually used? rekado: the file system is used to open files, i.e. access services it's not used to revoke access once pfinet has obtained a port to the network device, it keeps it oh, yes, of course. Sorry, this is all very new to me. 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? rekado: the idea is to make pfinet able to cope with a driver crash Can I trigger a driver crash for test purposes? (Or do I have to build a purposefully broken driver first?) use kill Oh, good. iirc, netdde doesn't restart correctly :x you'll probably have to fix it a bit i guess there is some persistent state that prevents it from reinitializing correctly okay 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? rekado: incubator branch Okay. Thank you for your patience. I'll play with this in the next few days. enjoy :) ### IRC, freenode, #hurd, 2013-09-05 When I kill the /hurd/netdde process I can no longer access the network (as expected); To restore connectivity I run "settrans -g eth0 /hurd/devnode -M /dev/netdde eth0" from the /dev directory. When I access the network again everything is fine. (I do see a message telling me "irq handler 11: release an dead delivery port" ) Is it the goal to avoid having to run settrans again to run netdde after it crashes or is killed? you don't need to run settrans again that should get triggered automatically Hmm, after killing netdde I get "Resource lost" when using wget. It doesn't seem to be restarted automatically. try again the first wget makes pfinet try to use netdde and fail, thus crash the second wil respawn pfinet ideally pfinet shouldn't die, that's a TODO mentioned in the "contributing page" Ah, so that's what should be prevented. it's just a matter of making pfinet be fine with errors from the eth translator, and simply reopen it instead of dying That's the thing I've been trying to figure out. when I run wget a second (or third) time I get a different error; "Name or service not known." It's only okay again when I use settrans maybe the devnode translator also needs some fixing it's odd that I don't have the issue though I'm using the qemu image, updated just yesterday. same here anyway, now you know where to put your hands :) yes, thanks a lot. ### IRC, freenode, #hurd, 2013-09-07 in pfinet/ethernet.c:ethernet_open there's an assertion: edev->ether_port == MACH_PORT_NULL This is violated when netdde was killed and the device is reopened. I'm not sure what should be done: destroy the port before reopening or drop the assertion? If I drop the assertion, Mach seems to handle this just fine. Says "irq handler 11: release an [sic] dead delivery port" and then carries on without problems. Is this a warning or an error, or can this be ignored? (or none of the above?) ### IRC, freenode, #hurd, 2013-09-08 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. It doesn't work, though, when only netdde has been killed. With devnode still around device_open fails with "(ipc/send) invalid destination port" I don't know where device_open is defined and why this error is returned. I guess the error refers to the "master_device" port returned by file_name_lookup() in ethernet_open() Why would file_name_lookup() return an invalid port when netdde is dead but devnode is still running? rekado: maybe because devnode needs to perform a fresh lookup as well ### IRC, freenode, #hurd, 2013-09-09 braunr: re devnode: devnode only performs a single lookup in parse_opt(), i.e. at start-up. I'll try to understand devnode enough to patch it. rekado: that's the problem 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"]]. I submitted two patches to the mailing list. I've tested them on Debian GNU/Hurd but based them on the incubator/dde branch. rekado: awesome, reliability fixes are very much welcome ### IRC, freenode, #hurd, 2013-09-18 youpi: my apologies for the delay in getting back to you with improvements to my pfinet/devnode patches. Been very busy. rekado: development pace on the hurd has always been slow, no need to apologize ## 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 # 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 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, , .