David
Wed Mar 02 05:57:29 CST 2005
Hi John,
Thanks for your response.
The subnet masks are both 255.255.255.0, so that part should be ok.
I tried testing with CETK as you suggested, not a lot of luck so far.
The One-Card Network Card Mini-Port Driver test fails, but with a 0-sized
log file, so I can't get any info on what is wrong. I can't use the 2-Card
test because I only have the 2 ports.
The driver is the Intel E100CE for 82551, and in normal operation it seems
fine, I am driving a PLC directly from it, and have had continuous operation
over one port for weeks without fault, although that doesn't rule out some
conflict when using both at once, I guess. But they both seem to work
together ok until I forward something between them.
I don't know much about IP6 and UPNP, so I haven't done anything to
configure them, just in as they came across from the catalog.
This is rather frustrating, something that seems so simple has held the
project up for over a week. I've asked for support from Kontron (Germany)
who provide the hardware and BSP, but nothing has come back so far. We did
wast a month trying to track down software problems with the first 3 units
they supplied, which turned out to be a hardware fault in that batch, but in
this case it feels more like software...
Any more advice much appreciated.
David
"John Spaith [MS]" <jspaith@ONLINE.microsoft.com> wrote in message
news:ODdjCGqHFHA.2276@TK2MSFTNGP15.phx.gbl...
> I've asked around and none of my coworkers are fimiliar with this problem.
> (The giving out the DHCP packet address on the public interface is a known
> issue but isn't causing this).
>
> Some thoughts for further investigation:
> * The IP addresses 192.168.0.1 and 192.168.221.58 might be confusing the
> routing part if the subnet masks on the two interfaces allow for overlap.
> * Run the CETK platform validation tests to rule out BSP/driver issues.
>
>
> --
> John Spaith
> Software Design Engineer, Windows CE
> Microsoft Corporation
>
> Check out the new CE Networking Team Blog at
http://blogs.msdn.com/cenet/.
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> You assume all risk for your use. © 2003 Microsoft Corporation. All rights
> reserved.
>
> "David Varley" <David.Varley@cborn.com> wrote in message
> news:OY08HfeHFHA.400@TK2MSFTNGP14.phx.gbl...
> >I have a Kontron ThinkIO with Kontron CE 4.2 BSP (modified CEPC)
Industrial
> > Controller, which has been working successfully for some time. The
device
> > has 2 Ethernet ports, and I've added the gateway components (NAT, ICS,
> > UPNP
> > + IGD, firewall, DHCP allocator, etc). the private interface is set up
as
> > 192.168.0.1, and on that side is a Rockwell L34 PLC, statically assigned
> > at
> > 192.168.0.2. I've configured port forwarding, so that from the public
> > interface port 8080 TCP forwards to internal 192.168.0.2:80, also the
> > EthernetIP port 44818 (TCP and UCP) are forwarded to the internal PLC.
> > This works, such that when I point my external web browser at port 8080
on
> > the public interface (DHCP allocated at 192.168.221.58), it brings up
the
> > startup page of the PLC's http interface. However thats all I see, the
CE
> > OS
> > immediately locks up. I don't get ant diagnostic debug messages on the
> > serial port, and don't know what's happening. The lockup also happens
when
> > I
> > connect a laptop to the hub on the private side. It get DHCP allocation,
> > and
> > I can ping devices on the public side (NAT translation works), but if I
> > tracert I get 3 hits on the CE interface (192.168.0.1), then one from
the
> > device on the public side (eg 192.168.221.4) and then CE locks up again.
> > I suspect something in NAT if forwarding to itself in a tight loop, but
I
> > can't diagnose with the debugger, as the BSP doesn't support KITL over
> > serial, or VMINI with the two Ethernet interfaces in use, as far as I
can
> > ascertain.
> > Does anyone have any suggestions here, have I missed something?
> > One other clue, early on in bootup the CE box actually sends two DHCP
> > packets (the second an offer) with a source address of 192.168.0.1 out
> > over
> > the 192.168.221.58 public interface, which should never happen...
> >
> > Thanks for any assistance,
> >
> > David
> >
> >
>
>