FreeLists / openbeosnetteam / [openbeosnetteam] Re: r18408 moved to network

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

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...

> > BTW interfaces currently don't like to be taken down too much - as 
> > we
> > reference them in the buffers (and probably elsewhere), we have to 
> > add
> > reference counting to them as well, I think.
> Yes, we should definitely do that, now that the destination interface 
> is put 
> into the buffer again. However, the reason why I temporarily disabled 
> that in 
> ipv4_reveive_data() was that I thought buffer->interface was 
> referring to the 
> source interface (the one through which the buffer came into the 
> stack). The 
> use in ipv4.cpp indicated that was the destination interface, though. 
> This is 
> in contrast with icmp.cpp, which (in receive_data()) treats buffer->
> interface 
> as the source interface. 
> I suppose it makes more sense to store the source interface into the 
> buffer, 
> but what do you think?

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? :-)
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...

> > 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.

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?

Bye,
   Axel.