Discussion:
Forwarding between NICs with Windows XP Embedded
(too old to reply)
Michael Gebis
2010-05-08 00:36:01 UTC
Permalink
The simplest configuration of the system we sell comprises two PCs running
windows, I'll call them A and B. A can run almost any windows variant, lets
assume XP Professional SP3. B is running XP embedded, with an ethernet
connection to the A and another NIC to a proprietary network (using our own
driver). The proprietary network contains a number of embedded CPUs running
Linux.

Let's use 10.10.0.0/16 for the ethernet and 10.51.0.0/16 for the proprietary
network.

We traditionally use a proxy on the embedded XP system for all direct
connections between A and the linux CPUs. New third party applications are
requiring direct connections without support for the proxy.

We have routing set up appropriately so that A has a gateway for
10.51.0.0/16 to the ethernet NIC on B and the linux cpus have a default route
to the proprietary interface on B.

The problem is that even with IpEnableRouter
(http://technet.microsoft.com/en-us/library/cc962461.aspx) set to zero we see
packets forwarding just fine through B. A can ping the linux CPUs and the
Linux CPUs can ping A.

Other than a socks proxy, there is no firewall/routing software installed.

This is the behaviour we want but the problem is it isn't reliable. We have
seen systems that suddenly stop forwarding even through reboots. Fixing them
requires enabling the above key.

We need to understand how this fowarding is occuring so we can control it
and have it be reliable. We can't mandate IpEnableRouter on all systems
without considerable, multiple customer consultation.

Thanks,
Michael
henry markov
2010-05-10 18:04:00 UTC
Permalink
10.10.0.0/16 and 10.51.0.0/16 denote Class A networks subnetted to Class B,
i.e. you are trying to take advantage of CIDR. One debug strategy I would
try is to use true Class B networks. Without knowing details of your
network parameters and proprietary software, it could be that some elements
of your network do not behave properly when CIDR is used. We have seen this
with older stacks in embedded OS systems.

HM
Post by Michael Gebis
The simplest configuration of the system we sell comprises two PCs running
windows, I'll call them A and B. A can run almost any windows variant, lets
assume XP Professional SP3. B is running XP embedded, with an ethernet
connection to the A and another NIC to a proprietary network (using our own
driver). The proprietary network contains a number of embedded CPUs running
Linux.
Let's use 10.10.0.0/16 for the ethernet and 10.51.0.0/16 for the proprietary
network.
We traditionally use a proxy on the embedded XP system for all direct
connections between A and the linux CPUs. New third party applications are
requiring direct connections without support for the proxy.
We have routing set up appropriately so that A has a gateway for
10.51.0.0/16 to the ethernet NIC on B and the linux cpus have a default route
to the proprietary interface on B.
The problem is that even with IpEnableRouter
(http://technet.microsoft.com/en-us/library/cc962461.aspx) set to zero we see
packets forwarding just fine through B. A can ping the linux CPUs and the
Linux CPUs can ping A.
Other than a socks proxy, there is no firewall/routing software installed.
This is the behaviour we want but the problem is it isn't reliable. We have
seen systems that suddenly stop forwarding even through reboots. Fixing them
requires enabling the above key.
We need to understand how this fowarding is occuring so we can control it
and have it be reliable. We can't mandate IpEnableRouter on all systems
without considerable, multiple customer consultation.
Thanks,
Michael
Loading...