[openbeosnetteam] Re: r18408 moved to network
- From: Oliver Tappe <openbeos@xxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sun, 06 Aug 2006 22:27:47 +0200
On 2006-08-06 at 19:50:52 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> Hi Oliver,
>
> I moved this discussion to the networking list, now that we go into the
> details ;-)
>
> > > Actually, I don't like that too much, and for a number of reasons:
> > > 1) it hides that the device in /dev/net/ is actually used for this
> > > interface; it disconnects information for no good reason
> > > 2) it clashes with the use of the ":x" notation we intended to
> > > implement (to have more than one address per device)
> > > 3) ifconfig is not a tool you won't be using regularly anymore when
> > > we
> > > have a GUI, hence it will probably only used to change
> > > functionality
> > > that the GUI doesn't allow for.
> > > 4) the device module detection currently works using pattern
> > > matching,
> > > ie. the ethernet device module will accept anything that starts
> > > with "/
> > > dev/net/", the loopback device will use anything that starts with
> > > "loop".
> > > 5) you can use tab completion to get the /dev/net/rtl8139/0
> > > interface :
> > > -)
> > >
> > > What do you think?
> > Well, it was just an idea >;o) esp. argument 4) suggests to leave it
> > as is.
>
> Well, I don't want to convince you otherwise, but ifconfig could handle
> this, if it wanted to; when creating an interface, you can select a
> driver name independent from the actual interface name...
Yes, I thought so, but your reasoning has convinced me that we should leave
it as is currently, it works and there's so much stuff that doesn't work...
We can always come back and improve ifconfig if we feel the need, can't we?
[ ... ]
> There is no real difference, I think - the buffer entered the stack
> coming from a device, not an interface. Depending of its target
> address, IPv4 is able to assign an interface to that buffer - how else
> could that work? Am I missing something, again? :-)
No, I was >;o) You are right, of course: a buffer enters the stack through a
device or through a local socket and it is being assigned a matching
interface by the domain protocol. That interface is either the one matching
the buffer's destination address or the interface is empty (in case the
packet does not match any local address and needs to be forwarded or dropped).
So it is good as is.
> I am also not sure if it's absolutely needed to have this pointer - it
> just came in handy when doing the ICMP echo reply...
And it is very handy when dealing with broadcasts, too, as you need to access
the interface's mask in order to do it.
> > > When you say you wanted to work on ICMP, do you mean redirects,
> > > path
> > > MTU discovery and the like? :-)
> > Well, I intended to start with implementing 'port unreachable' and
> > other
> > error messages first >;o) When simple error messages are done, I
> > could then
> > proceed with redirects and MTU discovery, but I suppose it would be
> > better to
> > start working on DHCP and name resolution, what do you think?
>
> I had thought you'd need TCP for DNS, but then, I dunno if it's really
> required.
Yes, I suppose you need TCP for a full DNS implementation but most queries
are handled via UDP AFAIK. Furthermore, I'd like to look into the required
infrastructure, a.k.a. the resolver (cache, access to .../etc/hosts if we
want to support that)? Or is that already in place (haven't checked at all)?
> But IIRC someone wrote a DHCP client for us, and we might want to have
> a look at it before porting something. I just have no idea where it is
> in the repository, though.
> Does anybody know this?
I'll check out David's stuff during the next days.
cheers,
Oliver
Other related posts:
