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/
