From eccdd13dd3c812b8f0b3d046ef9d8738df00562a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 25 Sep 2013 21:45:38 +0200 Subject: IRC. --- hurd/translator/pfinet/implementation.mdwn | 164 +++++++++++++++++++++++++++++ 1 file changed, 164 insertions(+) (limited to 'hurd/translator/pfinet') diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn index 9bcf62ef..2361615a 100644 --- a/hurd/translator/pfinet/implementation.mdwn +++ b/hurd/translator/pfinet/implementation.mdwn @@ -27,6 +27,170 @@ implementation. 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]] -- cgit v1.2.3