DHCP Client invisible dependency

[Henry Markov]

I created a configuration for a new board that I am evaluating. I first
installed XP desktop, used tap.exe, etc. to create a HW macro. I included
TCP/IP networking components, the DHCP client, and NIC drivers with TD and
automatically resolved all dependencies however when I deployed my system I
found that the DHCP client would immediately fail with exit code 1747
(RPC_S_UNKNOWN_AUTHN_SERVICE). After much grief I finally found that the
DHCP client was failing because Client for Microsoft Networks was not in the
configuration.

If Client for Microsoft Networks or some similar component is needed to make
the DHCP Client work, why isn't there a dependency that would have alerted
me to this problem when TD resolved dependencies? Oh well, another week
down the drain.

HM

 

[Mike Warren]

If Client for Microsoft Networks or some similar component is needed
to make the DHCP Client work, why isn't there a dependency that would
have alerted me to this problem when TD resolved dependencies? Oh
well, another week down the drain.

I've always had similar problems and they seem to be worse with rollup
1. I guess it gets more complicated as they try to break the components
up further.

 

[Andy Allred [MS]]

Sorry for the confusion Henry, but if we look closely at the components
available in Target Designer right next to TCP/IP Networking is the 'TCP/IP
Networking with Client For MS Networks' component.

This component is bold because it's a macro component and simply depends on
other components to make your jobs as a developer a little easier. If you
instantiate this component in TD's configuration to examine it and click
it's settings node it shows us that it has a dependency on 'Client for
Microsoft Networks' and would satisfy this networking dependency for you
without having to go hunt down the other components.

The reason it's like this and not built into the 'TCP/IP Networking'
component you used is because many embedded devices will reside in
non-Microsoft environments which don't require the Client for MS Networks
service on the client side. So the TCP/IP Networking component is optimized
to be agnostic for the environment it's in. It would appear that your test
environment is probably using an MS DHCP Server so your test machine needs
the extra components in order to function.

I'm a Tester, I would recommend the environment the device is being tested
in is the same as (or as close as possible) to the environment it's designed
for.

You don't need to answer that, it's just a tip.

Take care,
Andy

 

[Mike Warren]

The reason it's like this and not built into the 'TCP/IP Networking'
component you used is because many embedded devices will reside in
non-Microsoft environments which don't require the Client for MS
Networks service on the client side. So the TCP/IP Networking
component is optimized to be agnostic for the environment it's in. It
would appear that your test environment is probably using an MS DHCP
Server so your test machine needs the extra components in order to
function.

I can't get DHCP to work in a system using the DHCP server in an ADSL
router without including Client for MS Networks.

Does that make sense to you?

I do not want any MS networking in my image but need to be able to
connect to the Internet with my software without manual configuration.

 

[Henry Markov]

Andy,
Thanks for the response and thanks for your contributions to this NG which
is indispensable. However I really think you missed the point. I selected
TCP/IP networking components and the DHCP Client component but after
deployment the DHCP Client service immediately failed when the system was
booted. That's just wrong -- case closed. As a person who is interested in
writing a networking application in an open manner, how and why should I
know anything about 'Microsoft Networks?' I can't even find a definition of
Microsoft Networks in MSDN. The idea that a DHCP client can only work if
some unneeded and proprietary MS components are also dumped into the system
is ludicrous however if this requirement does exist then TD should identify
it.

I think this issue is illustrative of why XPe is hard to learn and use. You
design a system with everything you actually want and dependency resolution
throws in a lot of junk that you have no intention to use but it silently
leaves something out that makes the system fail. Seems to happen just about
every time.

HM