Re: Windows CE .NET 4.2 x86 with Cisco 350 WLAN... No IP Address
From: Ten (spam_at_spam.com)
Date: 03/19/04
- Next message: Rémi de Gravelaine: "Kbdgen.exe output potential problem for numpad (4.2 keyboard drivers)"
- Previous message: Ten: "Re: Windows CE .NET 4.2 x86 with Cisco 350 WLAN... No IP Address"
- In reply to: Paul G. Tobey [eMVP]: "Re: Windows CE .NET 4.2 x86 with Cisco 350 WLAN... No IP Address"
- Next in thread: Ten: "Re: Windows CE .NET 4.2 x86 with Cisco 350 WLAN... No IP Address"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 19 Mar 2004 10:10:08 -0500
We encountered a few problems that are very similar to what you've
described. Ours turned out to be an interrupt conflict on our Geode SC2200
(x86) based SBC (PC 104 form factor) when using PB to download and debug an
image.
Our SBC test platform has two wired ethernet ports (both connected) and a
two-slot PCMCIA adapter. Our test set up was to have both wired ethernet
ports connected, a PCMCIA->CF adapter in slot 1 and the cisco card in slot
2. By trial and error we found that whatever was in slot 2 did not work
when downloading an image from PB. If we "flashed" the OS image to the
device then booted from it, there was no conflict.
Once we noticed this, a quick look in the reference guide for our SBC showed
that the PCMCIA adapter slots (A & B) shared IRQs with ethernet ports 1 and
2 respectively. Some research into PB gave us information about how PB used
the debug ethernet port.
Armed with this information we were able to configure the platform so there
was no conflict. We disabled one of the wired ethernet ports (the final
product isn't spec'd for two wired ports anyway), allowed debug and normal
traffic on one wired ethernet port (something to do with BSP_NOSHAREETH I
think) and put the cisco card in the slot that shared the interrupt with the
disabled wired ethernet port.
Since you are receiving the OS image from a third party, you are probably
not using PB but there still may be a conflict.
Nick.
"Paul G. Tobey [eMVP]" <ptobey_no_spam@instrument_no_spam.com> wrote in
message news:%23wRrubSDEHA.3664@TK2MSFTNGP10.phx.gbl...
> Our ARM-based Windows CE.NET devices include the Microsoft-provided 350
card
> support, which works fine and has no problem getting addresses.
>
> Under Windows CE 3.0 on x86 devices, we've also used the CISCO-provided
> 340/350 card drivers and those work fine, also.
>
> Can you get the serial debug messages? Perhaps the driver or the TCP/IP
> stack is telling you what's wrong, but you're not listening. You don't
have
> to do anything special to assign an Ethernet address to your CISCO
hardware
> do you? An invalid Enet address might cause you problems.
>
> Paul T.
>
> "Chris Adamson" <cadamson-spam-me-not-@lotsofspamidentecsolutions.com>
wrote
> in message news:eonI9USDEHA.3344@tk2msftngp13.phx.gbl...
> > Hi Paul,
> >
> > Wow thanks for the quick response.
> >
> > We are actually having Advantech (http://www.advantech.com) build the
> image
> > for us. They have developed their own solution for persisting the
registry
> > and it appears that all the Cisco information is being stored (username,
> > password SSID etc). And it *does* leap authenticate upon reboot. We just
> > cannot get the device to take an IP address (manual or DHCP).
> >
> > We did add the registry key you suggested just to see if it would help.
> > After a reboot it did not make any difference. This key was not part of
> the
> > image build and we added it through the PC 104 itself via "regcedit".
> >
> > Paul, have you had success with integrating Cisco drivers?
> >
> > Has anyone successfully integrated Cisco drivers into an x86 CE .NET
> device?
> > If so we would really appreciate some help, hints contact info etc.
We've
> > hit this wall for two weeks now.
> >
> > Thanks!
> > -Chris
> >
> > "Paul G. Tobey [eMVP]" <ptobey_no_spam@instrument_no_spam.com> wrote in
> > message news:eW40tFSDEHA.3836@TK2MSFTNGP09.phx.gbl...
> > > The 'key' information for the authentication may be getting lost
during
> > the
> > > reboot because the object store is not persisted or something along
> those
> > > lines. We have to set the following registry entry on our devices in
> > order
> > > to make this type of thing work:
> > >
> > > ;021028_Q329102 - Platforms that use the object store registry and
> > implement
> > > ;a registry persistence solution using
> > > WriteRegistryToOEM/ReadRegistryFromOEM
> > > ;are unable to decrypt data in the registry that has been encrypted
> using
> > > Cryp
> > > ;ProtectData(). This is because the key files are stored in the file
> > system
> > > by
> > > ;default and there is no provision to restore these files on a cold
> boot.
> > >
> > > ;To enable this feature, the OEM needs to set the following registry
> key:
> > >
> > > [HKEY_LOCAL_MACHINE\Init\BootVars]
> > > "MasterKeysInRegistry"=dword:1
> > >
> > > Paul T.
> > >
> > > "Chris Adamson" <cadamson-spam-me-not-@lotsofspamidentecsolutions.com>
> > wrote
> > > in message news:uPhcx%23RDEHA.1240@TK2MSFTNGP10.phx.gbl...
> > > > Hi,
> > > >
> > > > We are having a problem building a Windows CE .NET 4.2 image on a
> PC104
> > > with
> > > > an x86 processor. The problem we are encountering is that we are
> trying
> > to
> > > > build into the image Cisco WLAN drivers w/LEAP so that the PC104 can
> > LEAP
> > > > authenticate onto the network (Air-PCM350 series). The unit will not
> > have
> > > a
> > > > keyboard, monitor, or mouse after it has been initially setup so all
> the
> > > > will be saved to the registry.
> > > > We've downloaded the latest x86 drivers (released this month) from
> Cisco
> > > and
> > > > extracted all the dll's, exe's and registry entries accordingly and
> > > included
> > > > them in the build.
> > > >
> > > > On first boot we enter in all the login info into the ACU utility
> > > including
> > > > login credentials, SSID, LEAP etc.. We also specify an IP number to
> the
> > > > Cisco Card. With all this set we can manually bring up the login
> module
> > > and
> > > > login. The ACU reports that the unit has authenticated. We can also
> > verify
> > > > that the radio has authenticated by checking the Access Point. The
> unit
> > > does
> > > > not however show an IP address whether we statically assign one try
to
> > get
> > > > one through DHCP.
> > > >
> > > > We tried rebooting the system and it does not automatically login
nor
> > does
> > > > it get an IP address via DHCP (IPCONFIG shows 0.0.0.0, "release" and
> > > "renew"
> > > > tried several times over).
> > > >
> > > > We are using the latest drivers from Cisco and the WLAN cards have
> been
> > > > updated to the latest firmware. The files for the build were
> extracted
> > > from
> > > > the CE.NET_x86.cab file downloaded from Cisco's website.
> > > >
> > > > We had no problems integrating our "Active RFID" PCMCIA reader's
> driver
> > > into
> > > > the build and were disappointed that the Cisco stuff is what has
been
> > > > holding us back ;)
> > > >
> > > > Any ideas or suggestions would be greatly appreciated as we are
> totally
> > > > stumped at the moment.
> > > >
> > > > If you have any contact info or would like to contact me directly
> please
> > > > remove the anti-spam letters from my email. Or via
> > > 183y67b02@sneakemail.com
> > > >
> > > > Thank you for your time!
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Rémi de Gravelaine: "Kbdgen.exe output potential problem for numpad (4.2 keyboard drivers)"
- Previous message: Ten: "Re: Windows CE .NET 4.2 x86 with Cisco 350 WLAN... No IP Address"
- In reply to: Paul G. Tobey [eMVP]: "Re: Windows CE .NET 4.2 x86 with Cisco 350 WLAN... No IP Address"
- Next in thread: Ten: "Re: Windows CE .NET 4.2 x86 with Cisco 350 WLAN... No IP Address"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|