1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
[[!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
<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
[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
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
## 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
# 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
<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>.
|
