M. Koehrer wrote: > Hi everybody, > > I just switch over to the latest version of rtnet. Before I worked fairly long > with the "historic" 0.6.0 with some patches. > > I have found one issue that worked with the old version but does not work with > the latest version: > I am using two eepro100 adapters as two real time network devices. > I want to access two non-rtnet embedded devices that have both the same fix > IP address. > > In previous versions of rtnet the routing was done using the source and the > destination address, now only the destination address is in use for routing. > That means, that it is not possible in my setup to distinguish between > the two embedded devices. > In the previous version, I set a different IP address to each of the NICs and > this > allowed me to access both embedded devices (the source address was relevant). > > > What can I do? I looked into the code and found out, that this issue > is not a trivial one as a extension of the routing (including API interface) > has to be done.
Ok, I see your problem and I agree that a solution is not trivial but also not too complicated. In fact, this source routing check has been "optimised" out during the revision of IPv4-routing. Typical RTnet setups do not require this, but some do, and we should not exclude them. I currently have in mind to re-introduce the related checks to rt_ip_route_output, but make this optional. Just needs a wrapping macro (to switch the number of arguments), an extension of all rt_ip_route_output invocations (passing INADDR_ANY when unsure), and of course the additional test against the source address itself. I don't think further quirks are hidden (famous last words...). Mathias, if you could already spend a bit time on this, I would add missing bits and merge it into trunk before 0.9.3. Unfortunately, my time is limited. Jan
signature.asc
Description: OpenPGP digital signature
