Michal 'hramrach' Suchanek <[EMAIL PROTECTED]> writes: > On Wed, Nov 06, 2002 at 02:52:25PM +0100, Niels M?ller wrote: > > Olivier P?ningault <[EMAIL PROTECTED]> writes: > > > > > You didn't understand correctly. Layer 2 translator performs ethernet + > > > arp, not ip ! > If you do not do IP int L2, how can you tell which L3 gets the packet?
The interface for reading raw ethernet frames should primarily filter on ethernet type code and ethernet addresses. If there are several processes (say, two completely independent ip-stacks) that want to use the same ethernet hardware and the same ethernet address, then the simplest way is to have the ethernet driver deliver each received frames to *both* processes. Or you can do something more clever with filters that look into packet contents (I've heard that some network cards even has some hardware support for that), but if you do that I think you want a nice general interface, and not code knowledge about the inside of ip packets into the ethernet driver. > > You also need to understand some of layer 4. If you have a received > > icmp packet and a bunch of clients, then you need some more > > information about your clients, like "client 1 sends tcp-packets from > > address 1.2.3.4" or "client 2 sends udp-packets from address 5.6.7.8, > > port 47". > But that is why they register their IPs with L2, isn't it? You need the > same for an ordinary ip packet. They layer 4 code will register the ip addresses it's interested in, in some way or the other, with the layer 3 code. But I don't think the layer three code should need to know about port numbers (just like I don't think the ethernet driver should need to know about ip addresses). In both cases a general interface for matching packet contents would be nice, but it shouldn't be added unless it's really needed. > This will be needed for routing. But for packets that are used by > connections to/from local machine you are usually not interested in protocol > specific details. But it may be easier to cope with them than designing > a protocol independent abstraction ;) I'm not sure I understand this point. For local communication, one usually either use AF_INET socket and connect to localhost/127.0.0.1, thus exercising all of the ip-stack except the ethernet card, or use AF_UNIX sockets. > I do not completely agree with this. Ip address is just a few numbers, port > is another number. You may choose to interpret som numbers in one layer and > other numbers elsewhere. But I do not see any reason for this as the numbers > are all available at the same level. All the packet data is available to the ethernet driver, sure. The problem is not the raw data, but the knowledge (including code) needed interpret the data. If possible, knowledge of different parts of the chain should be isolated to separate processes. > As for generating icmp packets: It is not very consistent if some program > generates host-unreachable and other connection-refused. But with your > separation of ip:s from ports the knowledge about ip and port is divided > unneccessarily. I don't see that as a problem. In fact I would expect the generation of host-unreachable and connection-refused to usually happen at different *machines* (the destination of my packets, and some router on the (broken) path across the network, respectively). So having them sometimes be generated by different processes on the same machine doesn't seem odd to me at all. Regards, /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
