stack/routing kernel modification - consult needed
I committed to a fairly complex project to run on Linux while assuming that the Linux stack implementation would provide equivalent functionality to that of the BSD-style stacks I am familiar with. At this point, quite far down the design path, I looked at what I thought would be trivial details and I am facing two major roadblocks. Problem #1 The physical driver layer which itself is quite complex and does additional routing, needs access to the destination (next hop) IP address in order to transmit the packet. Under BSD, the ip output method passes down the IP address, but under Linux that does not seem to be the case. I need some method of getting hold of the IP address. Note that there is no protocol address resolution on these interfaces, but there are multiple hosts to be addressed. The physical layer does the necessary addressing and additional routing, but it needs the IP address of where the packet is being forwarded. Problem #2 This device is a routing class device, i.e., it routes network traffic on some network segment. As such, it must be able to handle both public (e.g., 18.x.x.x) and private (e.g., 192.168.x.x) IP addresses. The device itself has multiple, loosely-coupled cards that communicate via TCP/IP sockets. To separate the "device internal" TCP traffic from the external "real" network traffic, the standard BSD solution is to subnet the 127/8 "lo" interface to 127.0/16 for "lo" and e.g., 127.1/16 for a driver accessing the other cards. Unfortunately, the Linux stack does not seem to allow subnetting of the 127 net. Assuming that my observation are accurate (please feel free to indicate otherwise), it would appear to me that I have two options: 1. Hack the Linux kernel/stack to add the required functionality (pass IP on transmit, allow 127/16 subnets). This would be the preferred solution given the late stage of the project, but I am not familiar (obviously) with the Linux stack code. I am now also nervous about other possible surprises (I got VLANs, multiple interfaces with same IP address, multiple proxy ARPs on the same processor etc.) 2. Scrap the project and restart under BSD. This is quite an expensive option; the only advantage would be my certainty that all of the concepts will work as architected because they were based on such stack. I am looking for advice, and, if possible, help. Any pointers addressing any of the above will be quite useful to me. If you are familiar with the relevant kernel code, and would be willing to help me with the modifications, please let me know. If you could do it, but think it would take too much of your time, please let me know, too, I'd be glad to set up a paid consulting arrangement if that would help. BTW, this is being developed on the 2.4.25 kernel. Please respond to me directly: zdenek at rcn.com Thanks, -Zdenek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
stack/routing kernel modification - consult needed
I committed to a fairly complex project to run on Linux while assuming that the Linux stack implementation would provide equivalent functionality to that of the BSD-style stacks I am familiar with. At this point, quite far down the design path, I looked at what I thought would be trivial details and I am facing two major roadblocks. Problem #1 The physical driver layer which itself is quite complex and does additional routing, needs access to the destination (next hop) IP address in order to transmit the packet. Under BSD, the ip output method passes down the IP address, but under Linux that does not seem to be the case. I need some method of getting hold of the IP address. Note that there is no protocol address resolution on these interfaces, but there are multiple hosts to be addressed. The physical layer does the necessary addressing and additional routing, but it needs the IP address of where the packet is being forwarded. Problem #2 This device is a routing class device, i.e., it routes network traffic on some network segment. As such, it must be able to handle both public (e.g., 18.x.x.x) and private (e.g., 192.168.x.x) IP addresses. The device itself has multiple, loosely-coupled cards that communicate via TCP/IP sockets. To separate the device internal TCP traffic from the external real network traffic, the standard BSD solution is to subnet the 127/8 lo interface to 127.0/16 for lo and e.g., 127.1/16 for a driver accessing the other cards. Unfortunately, the Linux stack does not seem to allow subnetting of the 127 net. Assuming that my observation are accurate (please feel free to indicate otherwise), it would appear to me that I have two options: 1. Hack the Linux kernel/stack to add the required functionality (pass IP on transmit, allow 127/16 subnets). This would be the preferred solution given the late stage of the project, but I am not familiar (obviously) with the Linux stack code. I am now also nervous about other possible surprises (I got VLANs, multiple interfaces with same IP address, multiple proxy ARPs on the same processor etc.) 2. Scrap the project and restart under BSD. This is quite an expensive option; the only advantage would be my certainty that all of the concepts will work as architected because they were based on such stack. I am looking for advice, and, if possible, help. Any pointers addressing any of the above will be quite useful to me. If you are familiar with the relevant kernel code, and would be willing to help me with the modifications, please let me know. If you could do it, but think it would take too much of your time, please let me know, too, I'd be glad to set up a paid consulting arrangement if that would help. BTW, this is being developed on the 2.4.25 kernel. Please respond to me directly: zdenek at rcn.com Thanks, -Zdenek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: routing kernel
Adam <[EMAIL PROTECTED]> said: > I had been using 2.0.35preX for like 630 days and it worked > relatively fine. I'd suggest getting the latest 2.0.x (there is a pre-series too). Otherwise, your userland would probably need a lot of upgrading. Or get one of the micro-distributions optimized for routers, and install that. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: routing kernel
> I'm looking for good support for both routing as well as NAT. > I heard the 2.0.x is one of the best kernels in terms of > VM management, what might matter considering the router is to > be P75 w/ 16mb ram. I run a trio of 486 DX2/66s each with 16mb ram and 500mb HDs as routers/NAT boxes - I've had no downtime in about 18 months on any of the machines. Each one runs 2.0.36 as RedHat patched it for their 5.2 release (I've never had to recompile the kernel for any of them, so I don't know who much this may vary from stock 2.0.36). HTH, Mo. -- Mo McKinlay Chief Software Architect inter/open Labs - GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
routing kernel
Hello, I was wondering what would be most recommended as routing kernel. I had been using 2.0.35preX for like 630 days and it worked relatively fine. Now, I'm wondering what would be next best kernel I would want to put there? Should I use latest 2.0.X kernel or latest 2.2.x kernel or maybe 2.4.0-test kernels? I'm looking for good support for both routing as well as NAT. I heard the 2.0.x is one of the best kernels in terms of VM management, what might matter considering the router is to be P75 w/ 16mb ram. obtw: before someone suggest alternative solutions, the machine in question is a laptop with two "New Media Live Wire" NIC's and only Linux supports those (and yes, PCMCIA NIC is not great performace but it should be adquate for current needs). -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
