Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/General/DHCP client startup/List of Posts
Forum Topic - DHCP client startup: Page 1 of 2 (28 Items)
   
Update
Paul Kahn
01/21/2009 12:34 PM
post20510
DHCP client startup   
Hi,

I read post5543 and have an additional question. (In the future should I just append to that post?)

We need to implement DHCP client identifiers. It appears that the released client doesn't allow for that in the build. 
So I downloaded the client from SourceForge and re-built it to enable the "-D" option (client identifier support).

That said, I need to start the client with command line parameters. For now, I've added the following to rc.local:

slay dhcp.client
slay dhcp.client
dhcp.client -i en0 -D 02000000
dhcp.client -i en1 -D 03000000
inetd

There are two adapters shown above but that does not matter for this question.

The above is inelegant and I think it poses a race condition WRT to allocation of DHCP lease requests. That is, the 
server sees the first request using a MAC address and then a second (on the same adapter) using the client identifier. 

What I'd like to do is know how do I specify dhcp.client parameters when it is started by netmanager (from post5543)? Is
 that possible?

Thanks...
Robert Craig
01/21/2009 12:50 PM
post20511
RE: DHCP client startup   
Hi Paul:
	When you say "source forge" do you mean "foundry27"?  Just to
make sure that we're talking about the same source base...

It looks like the parameters passed to dhcp.client are hard-coded into
the netmanager source.   

Take a look at:
http://community.qnx.com/integration/viewcvs/viewcvs.cgi/trunk/utils/n/n
etmanager/netmanager.c?root=core_networking&rev=409&system=exsy1001&view
=markup


Look for the "do_dhcp" function.

I think that you'll have to customise the netmanager source to add in
the additional client identifier option.

	Robert.

-----Original Message-----
From: Paul Kahn [mailto:community-noreply@qnx.com] 
Sent: Wednesday, January 21, 2009 12:35 PM
To: general-networking
Subject: DHCP client startup

Hi,

I read post5543 and have an additional question. (In the future should I
just append to that post?)

We need to implement DHCP client identifiers. It appears that the
released client doesn't allow for that in the build. So I downloaded the
client from SourceForge and re-built it to enable the "-D" option
(client identifier support).

That said, I need to start the client with command line parameters. For
now, I've added the following to rc.local:

slay dhcp.client
slay dhcp.client
dhcp.client -i en0 -D 02000000
dhcp.client -i en1 -D 03000000
inetd

There are two adapters shown above but that does not matter for this
question.

The above is inelegant and I think it poses a race condition WRT to
allocation of DHCP lease requests. That is, the server sees the first
request using a MAC address and then a second (on the same adapter)
using the client identifier. 

What I'd like to do is know how do I specify dhcp.client parameters when
it is started by netmanager (from post5543)? Is that possible?

Thanks...

_______________________________________________
General
http://community.qnx.com/sf/go/post20510
Paul Kahn
01/21/2009 1:01 PM
post20513
RE: DHCP client startup   
Hey Robert,

I believe so (I'm still pretty new to the QNX world). Here's the original location SVN reports:
http://community.qnx.com/svn/repos/core_networking/trunk

Thanks for the pointer, I'll download the netmanager code and take a look.

Thanks once again for your help!
--pk
Robert Craig
01/21/2009 1:24 PM
post20514
RE: DHCP client startup   
That's the right repository.   I just wanted to double check.

	Hope it works out for you,
		Robert. 

-----Original Message-----
From: Paul Kahn [mailto:community-noreply@qnx.com] 
Sent: Wednesday, January 21, 2009 1:01 PM
To: general-networking
Subject: RE: DHCP client startup

Hey Robert,

I believe so (I'm still pretty new to the QNX world). Here's the
original location SVN reports:
http://community.qnx.com/svn/repos/core_networking/trunk

Thanks for the pointer, I'll download the netmanager code and take a
look.

Thanks once again for your help!
--pk



_______________________________________________
General
http://community.qnx.com/sf/go/post20513
Paul Kahn
01/21/2009 1:39 PM
post20516
Re: RE: DHCP client startup   
Thanks much, Robert. I'll let you know -- might be a few days...
--pk
Paul Kahn
02/03/2009 3:34 PM
post21348
DHCP client startup -- Build problem   
Hi Robert,

I've downloaded the entire trunk from SourceForge and made the requisite modifications to the dhcp.client and the 
netmanager. I initially extracted only the source files I needed and created a Momentics build for the dhcp.client and 
this worked fine. However, when I attempted to do a similar thing for the netmanager, I realized it had too many 
tentacles into other parts of the source tree. So I think it best that I use the same directory structure and use the 
associated make files.

That said, I've run into a build problem using the sources I've extracted from the repository (no changes to these 
sources). It's a compiler error pertaining to a command line macro "-DVersion". 

One thing that's odd to me is that I have the GCC 3.3.5 compiler installed and I see that the make files are somehow 
deferring to the 2.95.3 version. Both were installed on my machine when I installed QNX632.

Text follows:

===========================================
make[2]: Entering directory `C:/Projects/QNX/Network/Sources.2/lib/bind9'
make -j 1 -Cx86 -fMakefile
make[3]: Entering directory `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86'
make -j 1 -Ca -fMakefile
make[4]: Entering directory `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a'
C:/Programs/QNX632/host/win32/x86/usr/bin/qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses -g -O -DNS_LOCALSTATEDIR=\"
/var\" -DNS_SYSCONFDIR=\"/etc\" -DVERSION=\"9.5.0-P2\" -DWAN
T_IPV6 -DLIBINTERFACE=40 -DLIBREVISION=3 -DLIBAGE=0 -DOPENSSL -DISC_PLATFORM_USETHREADS    -I. -IC:/Projects/QNX/Network
/Sources.2/lib/bind9/x86/a -IC:/Projects/QNX/Network/Sources
.2/lib/bind9/x86 -IC:/Projects/QNX/Network/Sources.2/lib/bind9 -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9 -
IC:/Projects/QNX/Network/Sources.2/services/bind/include -IC
:/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/include -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/unix/
include -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/
include -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/unix/include -IC:/Projects/QNX/Network/Sources.2/dist/bind
/lib/bind9/include -IC:/Projects/QNX/Network/Sources.2/dist/
bind/lib/isccfg/include -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isccc/include -IC:/Projects/QNX/Network/
Sources.2/dist/bind/lib/lwres/include -IC:/Projects/QNX/Network/So
urces.2/dist/bind/lib/lwres/unix/include -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/sec/dst/include -IC:/
Projects/QNX/Network/Sources.2/dist/bind/lib/isc/pthreads/includ
e -IC:/Programs/QNX632/target/qnx6/usr/include -g      -DVARIANT_a -O0 C:/Projects/QNX/Network/Sources.2/dist/bind/lib/
bind9/version.c
C:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9/version.c:26: malformed floating constant
C:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9/version.c:26: `P2' undeclared here (not in a function)
C:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9/version.c:26: array initialized from non-constant array expression

cc: C:/Programs/QNX632/host/win32/x86/usr/lib/gcc-lib/ntox86/2.95.3/cc1 caught signal 33
make[4]: *** [version.o] Error 1
make[4]: Leaving directory `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a'
make[3]: *** [all] Error 2
make[3]: Leaving directory `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86'
make[2]: *** [all] Error 2
make[2]: Leaving directory `C:/Projects/QNX/Network/Sources.2/lib/bind9'
make[1]: *** [all] Error 2
make[1]: Leaving directory `C:/Projects/QNX/Network/Sources.2/lib'
make: *** [all] Error 2
===========================================


I start the make from the root of this tree
"make CPULIST=x86 CCOPTS=-O0 DEBUG=-g".  

I've poked around and see that a number of folks have encountered this error in similar builds (not QNX) but I have yet 
to see a response. I'm sure there's somthing rather stupid I'm doing (I'm still new to the QNX build).

I'd appreciated any ideas...

Oh, couple of other points:
- I'm building on a Vista...
View Full Message
Robert Craig
02/03/2009 3:51 PM
post21349
RE: DHCP client startup -- Build problem   
Hi Paul:

One thing for certain, you have to set up a staging area and you have to
do a "make install" (or, in your case
make CPULIST=x86 CCOPTS=-O0 DEBUG=-g install).  I wonder if it's picking
up an invalid include file as a result of not doing the install?

Let's start off with that. Do a make clean at the top level to begin
with and then the make ... install and see if that changes the
behaviour.  With regards to the compiler, you have to set up your
environment so that the compiler invocation uses 3.3.5.  It doesn't do
so by default.  (And I'm not sure how to do this under windows...)

	Robert.


-----Original Message-----
From: Paul Kahn [mailto:community-noreply@qnx.com] 
Sent: Tuesday, February 03, 2009 3:35 PM
To: general-networking
Subject: DHCP client startup -- Build problem

Hi Robert,

I've downloaded the entire trunk from SourceForge and made the requisite
modifications to the dhcp.client and the netmanager. I initially
extracted only the source files I needed and created a Momentics build
for the dhcp.client and this worked fine. However, when I attempted to
do a similar thing for the netmanager, I realized it had too many
tentacles into other parts of the source tree. So I think it best that I
use the same directory structure and use the associated make files.

That said, I've run into a build problem using the sources I've
extracted from the repository (no changes to these sources). It's a
compiler error pertaining to a command line macro "-DVersion". 

One thing that's odd to me is that I have the GCC 3.3.5 compiler
installed and I see that the make files are somehow deferring to the
2.95.3 version. Both were installed on my machine when I installed
QNX632.

Text follows:

===========================================
make[2]: Entering directory
`C:/Projects/QNX/Network/Sources.2/lib/bind9'
make -j 1 -Cx86 -fMakefile
make[3]: Entering directory
`C:/Projects/QNX/Network/Sources.2/lib/bind9/x86'
make -j 1 -Ca -fMakefile
make[4]: Entering directory
`C:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a'
C:/Programs/QNX632/host/win32/x86/usr/bin/qcc -Vgcc_ntox86 -c -Wc,-Wall
-Wc,-Wno-parentheses -g -O -DNS_LOCALSTATEDIR=\"/var\"
-DNS_SYSCONFDIR=\"/etc\" -DVERSION=\"9.5.0-P2\" -DWAN
T_IPV6 -DLIBINTERFACE=40 -DLIBREVISION=3 -DLIBAGE=0 -DOPENSSL
-DISC_PLATFORM_USETHREADS    -I.
-IC:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a
-IC:/Projects/QNX/Network/Sources
.2/lib/bind9/x86 -IC:/Projects/QNX/Network/Sources.2/lib/bind9
-IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9
-IC:/Projects/QNX/Network/Sources.2/services/bind/include -IC
:/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/include
-IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/unix/include
-IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/
include
-IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/unix/include
-IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9/include
-IC:/Projects/QNX/Network/Sources.2/dist/
bind/lib/isccfg/include
-IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isccc/include
-IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/lwres/include
-IC:/Projects/QNX/Network/So urces.2/dist/bind/lib/lwres/unix/include
-IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/sec/dst/include
-IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/pthreads/includ
e -IC:/Programs/QNX632/target/qnx6/usr/include -g      -DVARIANT_a -O0
C:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9/version.c
C:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9/version.c:26:
malformed floating constant
C:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9/version.c:26: `P2'
undeclared here (not in a function)
C:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9/version.c:26:
array initialized from non-constant array expression
cc: C:/Programs/QNX632/host/win32/x86/usr/lib/gcc-lib/ntox86/2.95.3/cc1
caught signal 33
make[4]: *** [version.o] Error 1
make[4]: Leaving...
View Full Message
Sean Boudreau(deleted)
02/03/2009 4:00 PM
post21351
Re: DHCP client startup -- Build problem   
Sigh, this is probably a windows build issue.  IIRC
the windows environment doesn't like the
CFLAGS+= -DFOO=\"BAR\" construct...

-seanb

On Tue, Feb 03, 2009 at 03:51:24PM -0500, Robert Craig wrote:
> Hi Paul:
> 
> One thing for certain, you have to set up a staging area and you have to
> do a "make install" (or, in your case
> make CPULIST=x86 CCOPTS=-O0 DEBUG=-g install).  I wonder if it's picking
> up an invalid include file as a result of not doing the install?
> 
> Let's start off with that. Do a make clean at the top level to begin
> with and then the make ... install and see if that changes the
> behaviour.  With regards to the compiler, you have to set up your
> environment so that the compiler invocation uses 3.3.5.  It doesn't do
> so by default.  (And I'm not sure how to do this under windows...)
> 
> 	Robert.
> 
> 
> -----Original Message-----
> From: Paul Kahn [mailto:community-noreply@qnx.com] 
> Sent: Tuesday, February 03, 2009 3:35 PM
> To: general-networking
> Subject: DHCP client startup -- Build problem
> 
> Hi Robert,
> 
> I've downloaded the entire trunk from SourceForge and made the requisite
> modifications to the dhcp.client and the netmanager. I initially
> extracted only the source files I needed and created a Momentics build
> for the dhcp.client and this worked fine. However, when I attempted to
> do a similar thing for the netmanager, I realized it had too many
> tentacles into other parts of the source tree. So I think it best that I
> use the same directory structure and use the associated make files.
> 
> That said, I've run into a build problem using the sources I've
> extracted from the repository (no changes to these sources). It's a
> compiler error pertaining to a command line macro "-DVersion". 
> 
> One thing that's odd to me is that I have the GCC 3.3.5 compiler
> installed and I see that the make files are somehow deferring to the
> 2.95.3 version. Both were installed on my machine when I installed
> QNX632.
> 
> Text follows:
> 
> ===========================================
> make[2]: Entering directory
> `C:/Projects/QNX/Network/Sources.2/lib/bind9'
> make -j 1 -Cx86 -fMakefile
> make[3]: Entering directory
> `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86'
> make -j 1 -Ca -fMakefile
> make[4]: Entering directory
> `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a'
> C:/Programs/QNX632/host/win32/x86/usr/bin/qcc -Vgcc_ntox86 -c -Wc,-Wall
> -Wc,-Wno-parentheses -g -O -DNS_LOCALSTATEDIR=\"/var\"
> -DNS_SYSCONFDIR=\"/etc\" -DVERSION=\"9.5.0-P2\" -DWAN
> T_IPV6 -DLIBINTERFACE=40 -DLIBREVISION=3 -DLIBAGE=0 -DOPENSSL
> -DISC_PLATFORM_USETHREADS    -I.
> -IC:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a
> -IC:/Projects/QNX/Network/Sources
> .2/lib/bind9/x86 -IC:/Projects/QNX/Network/Sources.2/lib/bind9
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9
> -IC:/Projects/QNX/Network/Sources.2/services/bind/include -IC
> :/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/unix/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/
> include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/unix/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9/include
> -IC:/Projects/QNX/Network/Sources.2/dist/
> bind/lib/isccfg/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isccc/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/lwres/include
> -IC:/Projects/QNX/Network/So urces.2/dist/bind/lib/lwres/unix/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/sec/dst/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/pthreads/includ
> e...
View Full Message
Robert Craig
02/03/2009 4:07 PM
post21353
RE: DHCP client startup -- Build problem   
Ah yes...  Our Fun With Windows builds...

The bind9 stuff was just recently added and builds fine under both linux
and Neutrino.  Looks like it's time to try a windows build.

In the meantime, perhaps if you drop back to a pre-bind9 version of the
source (rev 763 should do it), you should have more luck.  You can also
download the GA source from the branches directory.

	Robert.


-----Original Message-----
From: Sean Boudreau [mailto:community-noreply@qnx.com] 
Sent: Tuesday, February 03, 2009 4:00 PM
To: general-networking
Subject: Re: DHCP client startup -- Build problem


Sigh, this is probably a windows build issue.  IIRC the windows
environment doesn't like the
CFLAGS+= -DFOO=\"BAR\" construct...

-seanb

On Tue, Feb 03, 2009 at 03:51:24PM -0500, Robert Craig wrote:
> Hi Paul:
> 
> One thing for certain, you have to set up a staging area and you have 
> to do a "make install" (or, in your case make CPULIST=x86 CCOPTS=-O0 
> DEBUG=-g install).  I wonder if it's picking up an invalid include 
> file as a result of not doing the install?
> 
> Let's start off with that. Do a make clean at the top level to begin 
> with and then the make ... install and see if that changes the 
> behaviour.  With regards to the compiler, you have to set up your 
> environment so that the compiler invocation uses 3.3.5.  It doesn't do

> so by default.  (And I'm not sure how to do this under windows...)
> 
> 	Robert.
> 
> 
> -----Original Message-----
> From: Paul Kahn [mailto:community-noreply@qnx.com]
> Sent: Tuesday, February 03, 2009 3:35 PM
> To: general-networking
> Subject: DHCP client startup -- Build problem
> 
> Hi Robert,
> 
> I've downloaded the entire trunk from SourceForge and made the 
> requisite modifications to the dhcp.client and the netmanager. I 
> initially extracted only the source files I needed and created a 
> Momentics build for the dhcp.client and this worked fine. However, 
> when I attempted to do a similar thing for the netmanager, I realized 
> it had too many tentacles into other parts of the source tree. So I 
> think it best that I use the same directory structure and use the
associated make files.
> 
> That said, I've run into a build problem using the sources I've 
> extracted from the repository (no changes to these sources). It's a 
> compiler error pertaining to a command line macro "-DVersion".
> 
> One thing that's odd to me is that I have the GCC 3.3.5 compiler 
> installed and I see that the make files are somehow deferring to the
> 2.95.3 version. Both were installed on my machine when I installed 
> QNX632.
> 
> Text follows:
> 
> ===========================================
> make[2]: Entering directory
> `C:/Projects/QNX/Network/Sources.2/lib/bind9'
> make -j 1 -Cx86 -fMakefile
> make[3]: Entering directory
> `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86'
> make -j 1 -Ca -fMakefile
> make[4]: Entering directory
> `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a'
> C:/Programs/QNX632/host/win32/x86/usr/bin/qcc -Vgcc_ntox86 -c 
> -Wc,-Wall -Wc,-Wno-parentheses -g -O -DNS_LOCALSTATEDIR=\"/var\"
> -DNS_SYSCONFDIR=\"/etc\" -DVERSION=\"9.5.0-P2\" -DWAN
> T_IPV6 -DLIBINTERFACE=40 -DLIBREVISION=3 -DLIBAGE=0 -DOPENSSL
> -DISC_PLATFORM_USETHREADS    -I.
> -IC:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a
> -IC:/Projects/QNX/Network/Sources
> .2/lib/bind9/x86 -IC:/Projects/QNX/Network/Sources.2/lib/bind9
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9
> -IC:/Projects/QNX/Network/Sources.2/services/bind/include -IC 
> :/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/unix/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/
>...
View Full Message
Mario Charest
02/03/2009 4:14 PM
post21355
RE: DHCP client startup -- Build problem   

> -----Original Message-----
> From: Robert Craig [mailto:community-noreply@qnx.com]
> Sent: February-03-09 4:08 PM
> To: general-networking
> Subject: RE: DHCP client startup -- Build problem
> 
> Ah yes...  Our Fun With Windows builds...
> 
> The bind9 stuff was just recently added and builds fine under both
> linux
> and Neutrino.  Looks like it's time to try a windows build.
> 

 
What do you guys use as host NTO or Linux?  I would like to switch to Linux but email is provided via Outlook Exchange ;
-(


> In the meantime, perhaps if you drop back to a pre-bind9 version of the
> source (rev 763 should do it), you should have more luck.  You can also
> download the GA source from the branches directory.
> 
> 	Robert.
> 
> 
> -----Original Message-----
> From: Sean Boudreau [mailto:community-noreply@qnx.com]
> Sent: Tuesday, February 03, 2009 4:00 PM
> To: general-networking
> Subject: Re: DHCP client startup -- Build problem
> 
> 
> Sigh, this is probably a windows build issue.  IIRC the windows
> environment doesn't like the
> CFLAGS+= -DFOO=\"BAR\" construct...
> 
> -seanb
> 
> On Tue, Feb 03, 2009 at 03:51:24PM -0500, Robert Craig wrote:
> > Hi Paul:
> >
> > One thing for certain, you have to set up a staging area and you have
> > to do a "make install" (or, in your case make CPULIST=x86 CCOPTS=-O0
> > DEBUG=-g install).  I wonder if it's picking up an invalid include
> > file as a result of not doing the install?
> >
> > Let's start off with that. Do a make clean at the top level to begin
> > with and then the make ... install and see if that changes the
> > behaviour.  With regards to the compiler, you have to set up your
> > environment so that the compiler invocation uses 3.3.5.  It doesn't
> do
> 
> > so by default.  (And I'm not sure how to do this under windows...)
> >
> > 	Robert.
> >
> >
> > -----Original Message-----
> > From: Paul Kahn [mailto:community-noreply@qnx.com]
> > Sent: Tuesday, February 03, 2009 3:35 PM
> > To: general-networking
> > Subject: DHCP client startup -- Build problem
> >
> > Hi Robert,
> >
> > I've downloaded the entire trunk from SourceForge and made the
> > requisite modifications to the dhcp.client and the netmanager. I
> > initially extracted only the source files I needed and created a
> > Momentics build for the dhcp.client and this worked fine. However,
> > when I attempted to do a similar thing for the netmanager, I realized
> > it had too many tentacles into other parts of the source tree. So I
> > think it best that I use the same directory structure and use the
> associated make files.
> >
> > That said, I've run into a build problem using the sources I've
> > extracted from the repository (no changes to these sources). It's a
> > compiler error pertaining to a command line macro "-DVersion".
> >
> > One thing that's odd to me is that I have the GCC 3.3.5 compiler
> > installed and I see that the make files are somehow deferring to the
> > 2.95.3 version. Both were installed on my machine when I installed
> > QNX632.
> >
> > Text follows:
> >
> > ===========================================
> > make[2]: Entering directory
> > `C:/Projects/QNX/Network/Sources.2/lib/bind9'
> > make -j 1 -Cx86 -fMakefile
> > make[3]: Entering directory
> > `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86'
> > make -j 1 -Ca -fMakefile
> > make[4]: Entering directory
> > `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a'
> > C:/Programs/QNX632/host/win32/x86/usr/bin/qcc -Vgcc_ntox86...
View Full Message
Sean Boudreau(deleted)
02/03/2009 4:16 PM
post21356
Re: DHCP client startup -- Build problem   
>  
> What do you guys use as host NTO or Linux?  I would like to switch to Linux but email is provided via Outlook Exchange
 ;-(

Self hosted 24/7 :)

-seanb
Robert Craig
02/03/2009 4:19 PM
post21357
RE: DHCP client startup -- Build problem   
However, our build farm will be migrating to Linux because of a bunch of
pretty cool front ends for automating and managing the builds.
 
For networking, we definitely support building under Windows, but it's
usually the last one to get checked out.  With other projects, your
mileage may vary :>.

	Robert.

-----Original Message-----
From: Sean Boudreau [mailto:community-noreply@qnx.com] 
Sent: Tuesday, February 03, 2009 4:17 PM
To: general-networking
Subject: Re: DHCP client startup -- Build problem

>  
> What do you guys use as host NTO or Linux?  I would like to switch to 
> Linux but email is provided via Outlook Exchange ;-(

Self hosted 24/7 :)

-seanb

_______________________________________________
General
http://community.qnx.com/sf/go/post21356
Mario Charest
02/03/2009 4:22 PM
post21358
RE: DHCP client startup -- Build problem   
> -----Original Message-----
> From: Sean Boudreau [mailto:community-noreply@qnx.com]
> Sent: February-03-09 4:17 PM
> To: general-networking
> Subject: Re: DHCP client startup -- Build problem
> 
> >
> > What do you guys use as host NTO or Linux?  I would like to switch to
> Linux but email is provided via Outlook Exchange ;-(
> 
> Self hosted 24/7 :)
> 

Here almost everybody switched to Windows, that doubled my work load because now I have to maintain all our build 
scripts and release procedure on two platforms , sigh!

If only I could convince them to use vim ;-)

> -seanb
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post21356
>
Sean Boudreau(deleted)
02/05/2009 10:05 AM
post21482
Re: DHCP client startup -- Build problem   
On Tue, Feb 03, 2009 at 04:07:45PM -0500, Robert Craig wrote:
> Ah yes...  Our Fun With Windows builds...
> 
> The bind9 stuff was just recently added and builds fine under both linux
> and Neutrino.  Looks like it's time to try a windows build.
> 
> In the meantime, perhaps if you drop back to a pre-bind9 version of the
> source (rev 763 should do it), you should have more luck.  You can also
> download the GA source from the branches directory.
> 
> 	Robert.

Windows build should be 'fixed'.

-seanb
Robert Craig
02/03/2009 5:26 PM
post21366
RE: DHCP client startup -- Build problem   
I've just confirmed that it is indeed a problem with the windows build
that we'll have to sort out.
PR65179 has been created to track this.

	Robert. 

-----Original Message-----
From: Sean Boudreau [mailto:community-noreply@qnx.com] 
Sent: Tuesday, February 03, 2009 4:00 PM
To: general-networking
Subject: Re: DHCP client startup -- Build problem


Sigh, this is probably a windows build issue.  IIRC the windows
environment doesn't like the
CFLAGS+= -DFOO=\"BAR\" construct...

-seanb

On Tue, Feb 03, 2009 at 03:51:24PM -0500, Robert Craig wrote:
> Hi Paul:
> 
> One thing for certain, you have to set up a staging area and you have 
> to do a "make install" (or, in your case make CPULIST=x86 CCOPTS=-O0 
> DEBUG=-g install).  I wonder if it's picking up an invalid include 
> file as a result of not doing the install?
> 
> Let's start off with that. Do a make clean at the top level to begin 
> with and then the make ... install and see if that changes the 
> behaviour.  With regards to the compiler, you have to set up your 
> environment so that the compiler invocation uses 3.3.5.  It doesn't do

> so by default.  (And I'm not sure how to do this under windows...)
> 
> 	Robert.
> 
> 
> -----Original Message-----
> From: Paul Kahn [mailto:community-noreply@qnx.com]
> Sent: Tuesday, February 03, 2009 3:35 PM
> To: general-networking
> Subject: DHCP client startup -- Build problem
> 
> Hi Robert,
> 
> I've downloaded the entire trunk from SourceForge and made the 
> requisite modifications to the dhcp.client and the netmanager. I 
> initially extracted only the source files I needed and created a 
> Momentics build for the dhcp.client and this worked fine. However, 
> when I attempted to do a similar thing for the netmanager, I realized 
> it had too many tentacles into other parts of the source tree. So I 
> think it best that I use the same directory structure and use the
associated make files.
> 
> That said, I've run into a build problem using the sources I've 
> extracted from the repository (no changes to these sources). It's a 
> compiler error pertaining to a command line macro "-DVersion".
> 
> One thing that's odd to me is that I have the GCC 3.3.5 compiler 
> installed and I see that the make files are somehow deferring to the
> 2.95.3 version. Both were installed on my machine when I installed 
> QNX632.
> 
> Text follows:
> 
> ===========================================
> make[2]: Entering directory
> `C:/Projects/QNX/Network/Sources.2/lib/bind9'
> make -j 1 -Cx86 -fMakefile
> make[3]: Entering directory
> `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86'
> make -j 1 -Ca -fMakefile
> make[4]: Entering directory
> `C:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a'
> C:/Programs/QNX632/host/win32/x86/usr/bin/qcc -Vgcc_ntox86 -c 
> -Wc,-Wall -Wc,-Wno-parentheses -g -O -DNS_LOCALSTATEDIR=\"/var\"
> -DNS_SYSCONFDIR=\"/etc\" -DVERSION=\"9.5.0-P2\" -DWAN
> T_IPV6 -DLIBINTERFACE=40 -DLIBREVISION=3 -DLIBAGE=0 -DOPENSSL
> -DISC_PLATFORM_USETHREADS    -I.
> -IC:/Projects/QNX/Network/Sources.2/lib/bind9/x86/a
> -IC:/Projects/QNX/Network/Sources
> .2/lib/bind9/x86 -IC:/Projects/QNX/Network/Sources.2/lib/bind9
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9
> -IC:/Projects/QNX/Network/Sources.2/services/bind/include -IC 
> :/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/dns/unix/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/
> include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/isc/unix/include
> -IC:/Projects/QNX/Network/Sources.2/dist/bind/lib/bind9/include
> -IC:/Projects/QNX/Network/Sources.2/dist/
> bind/lib/isccfg/include
>...
View Full Message
Paul Kahn
02/03/2009 5:32 PM
post21368
Re: RE: DHCP client startup -- Build problem   
Good to know...

I've just now finished downloading the R763 sources and am starting the installation build. I'll let ya know how it goes
...

Thanks to both of you Robert / Sean for your help.
Paul Kahn
02/04/2009 9:51 AM
post21403
Re: RE: DHCP client startup -- Build problem   
Hi Robert,

Unfortunately, I don't think this scheme will work. I didn't realize that the source build actually modifies the QNX 
installation as well; it rebuilds libraries and updates include files. 

We are developing for a medical product and there are fairly strict rules with respect to verfication and validation. 
It's not a problem to modify a small OS utility; it becomes a bigger issue if numerous OS libraries and sources are 
modified.

It seems to me I might be able to accomplish what I need by marking all of the Ethernet interfaces as disabled in net.
cfg so that the netmanager does nothing with them during startup. I could then start them up under our software control 
at some point later in the initialization phase.

Perhaps I am over simplifying this, but it appears that for each Ethernet interface, the netmanager:
1) marks the interface as "up" via an ioctl() call
2) starts the DHCP client with paramaters set net.cfg
3) performs some name server tasks (I've not yet studied this in detail). 

Might this scheme work or is it more complicated than I think?

Thanks,
--Paul
Robert Craig
02/04/2009 10:11 AM
post21409
RE: RE: DHCP client startup -- Build problem   
Hi Paul:

	I'm hoping that you've missed out on something :>.  At the end
of the day, the only thing that you need from the build that you've
produced is the new binary that you built.  Nothing else needs to get
updated.  When you do the source build, it builds everything in
networking and installs it to your staging area.  If your QNX
installation is getting modified, then the staging area hasn't been set
up properly.  You should also be able to copy the netmanager source into
your own project and build it independently of the rest of the project
if you like.

I guess on the positive side of things, you've now got the build
working, correct?

Actually, it's also quite easy to NOT have netmanager start up for each
ethernet interface.  The enumerator controls what applications are run
on start up.  If you look under etc/system/enum/devices, you'll see a
"net" file.  Search through the file for your relevant card information.
At the end of the device block, you'll see a "use(symbolic=netmgr)".  If
you replace that with (e.g.) 
driver(/usr/sbin/dhcp.client -t2)

Then this will start up dhcp.client instead of netmanager.  However, if
you run phlip from Photon (or netmanager from the command line), you'll
end up with "undefined behaviour" as two things try to control the
device.


	Robert.

-----Original Message-----
From: Paul Kahn [mailto:community-noreply@qnx.com] 
Sent: Wednesday, February 04, 2009 9:52 AM
To: general-networking
Subject: Re: RE: DHCP client startup -- Build problem

Hi Robert,

Unfortunately, I don't think this scheme will work. I didn't realize
that the source build actually modifies the QNX installation as well; it
rebuilds libraries and updates include files. 

We are developing for a medical product and there are fairly strict
rules with respect to verfication and validation. It's not a problem to
modify a small OS utility; it becomes a bigger issue if numerous OS
libraries and sources are modified.

It seems to me I might be able to accomplish what I need by marking all
of the Ethernet interfaces as disabled in net.cfg so that the netmanager
does nothing with them during startup. I could then start them up under
our software control at some point later in the initialization phase.

Perhaps I am over simplifying this, but it appears that for each
Ethernet interface, the netmanager:
1) marks the interface as "up" via an ioctl() call
2) starts the DHCP client with paramaters set net.cfg
3) performs some name server tasks (I've not yet studied this in
detail). 

Might this scheme work or is it more complicated than I think?

Thanks,
--Paul 

_______________________________________________
General
http://community.qnx.com/sf/go/post21403
Paul Kahn
02/04/2009 10:46 AM
post21417
RE: DHCP client startup -- Build problem   
Hey Robert,

LOTS of great information! I'm sure learning a lot about QNX.

I'm sure I don't have the build staging area set up properly. I was able to get a clean build last night. I ran into 
problems with it, however. First the binaries I generated did not work properly. They run (i.e. they don't crash) but 
were unable to communicate via the socket interface. I saw no DHCP-specific traffic on the network using a network 
sniffer. I also found that after I did an "install" build, my Momentics builds would not compile and I had to reinstall 
the SDK to get things working again.

I'm guessing there is some sort of compatibility issue between R763 sources from the Foundary and the '632 libraries and
 include files I have. 

I like your idea of modifying the device enumeration; that might work.

It may be easiest at the end of the day to create a Momentics project for netmanager as I did (initially) for the dhcp.
client. I know that'll work. I was just striving to keep things clean in case we needed to resync with Foundary sources 
in the future.

I'll need to think about this to decide the best way to go next.

thanks again for your help...
Robert Craig
02/04/2009 11:00 AM
post21421
RE: DHCP client startup -- Build problem   
I missed out on the fact that you're using 6.3.2.  The project will
create a whole new networking infrastructure which is different from
io-net and I can see that "breaking" your normal startup without
changing the way things ran.  My apologies for not catching that sooner.
Without the staging area being set up properly to begin with, your best
bet is going to be doing a remove / re-install of the SDK to make sure
that there's nothing left hanging around from the installation
overwrite.  Information on setting up a staging area is covered in the
Source Guide.

I think that you're right and that the easiest thing to do is to create
a separate project for netmanager.  It's a small enough source base that
it should be pretty easy to pull in new versions of source if it gets
updated.  

You can always just do a check out directly from the netmanager
directory if you want to keep things relatively simple from the point of
view of code syncing (just specify trunk/utils/n/netmanager as your
checkout source location).

	Robert.


-----Original Message-----
From: Paul Kahn [mailto:community-noreply@qnx.com] 
Sent: Wednesday, February 04, 2009 10:47 AM
To: general-networking
Subject: RE: DHCP client startup -- Build problem

Hey Robert,

LOTS of great information! I'm sure learning a lot about QNX.

I'm sure I don't have the build staging area set up properly. I was able
to get a clean build last night. I ran into problems with it, however.
First the binaries I generated did not work properly. They run (i.e.
they don't crash) but were unable to communicate via the socket
interface. I saw no DHCP-specific traffic on the network using a network
sniffer. I also found that after I did an "install" build, my Momentics
builds would not compile and I had to reinstall the SDK to get things
working again.

I'm guessing there is some sort of compatibility issue between R763
sources from the Foundary and the '632 libraries and include files I
have. 

I like your idea of modifying the device enumeration; that might work.

It may be easiest at the end of the day to create a Momentics project
for netmanager as I did (initially) for the dhcp.client. I know that'll
work. I was just striving to keep things clean in case we needed to
resync with Foundary sources in the future.

I'll need to think about this to decide the best way to go next.

thanks again for your help...


_______________________________________________
General
http://community.qnx.com/sf/go/post21417
Paul Kahn
02/05/2009 1:16 PM
post21497
Re: RE: DHCP client startup -- Build problem   
Hey Robert,

I restored my QNX SDK, and created a netmanager build w/Momentics. 

I having an issue with the netmanager. Even the unmodifed version doesn't seem to work (again I'm running QNX 6.3.2). It
 fails after trying to configure the first interface. 

For each Ethernet interface, it calls set_interface_state() to modify the interface flags. However, the ioctl() call to 
retrieve them fails 

   ret = ioctl(sock,SIOCGIFFLAGS,...);

w/error ENOTSUP. I'd noticed that this ioctl didn't seem to work when coding some socket stuff for another part of our 
application.

I went back to the first version in the SourceForge archive and the code is similar. It appears that there have been 
additions to provide wireless (802.11) support. I scanned through the branches in order to find something that would 
coincide with the 6.3.2 release but I didn't see anything. I only see some for early 6.4.0 branches. 

Is there an archive from which I can retrieve OS sources compatible with the 6.3.2 release? Or am I doing something 
silly?

In general, why does that ioctl() fail when retrieving the flags? I looked in the socket sources and this *should* work 
(of course I think I have newer sources and they don't match the 6.3.2 binaries). The netmanager code is written as 
though it might fail; i.e. it does 5 retries w/a 2-second delay in between. 

Gracias...
Robert Craig
02/05/2009 1:37 PM
post21500
RE: RE: DHCP client startup -- Build problem   
Unfortunately, all of the source that's on the Foundry is only tested
against the new stack and it isn't guaranteed to be backwards compatible
with the io-net stack.  I can see that we've made some modifications
(such as the use of getifaddrs instead of SIOCFIGCONF in
get_tcpip_config and get_interface_aliases) but I THINK that those
should be compatible as long as you're using the io-net stack include
files (and not the include files in the foundry) to build against.  Out
of curiosity, are your interface names being correctly found?

The code for set_interface_state doesn't seem to have changed between
6.3.2 and now either, so I suspect that there may be an earlier failure
(?)

Unfortunately, there isn't any place to publicly get the source released
with 6.3.2.   

	Robert. 

-----Original Message-----
From: Paul Kahn [mailto:community-noreply@qnx.com] 
Sent: Thursday, February 05, 2009 1:16 PM
To: general-networking
Subject: Re: RE: DHCP client startup -- Build problem

Hey Robert,

I restored my QNX SDK, and created a netmanager build w/Momentics. 

I having an issue with the netmanager. Even the unmodifed version
doesn't seem to work (again I'm running QNX 6.3.2). It fails after
trying to configure the first interface. 

For each Ethernet interface, it calls set_interface_state() to modify
the interface flags. However, the ioctl() call to retrieve them fails 

   ret = ioctl(sock,SIOCGIFFLAGS,...);

w/error ENOTSUP. I'd noticed that this ioctl didn't seem to work when
coding some socket stuff for another part of our application.

I went back to the first version in the SourceForge archive and the code
is similar. It appears that there have been additions to provide
wireless (802.11) support. I scanned through the branches in order to
find something that would coincide with the 6.3.2 release but I didn't
see anything. I only see some for early 6.4.0 branches. 

Is there an archive from which I can retrieve OS sources compatible with
the 6.3.2 release? Or am I doing something silly?

In general, why does that ioctl() fail when retrieving the flags? I
looked in the socket sources and this *should* work (of course I think I
have newer sources and they don't match the 6.3.2 binaries). The
netmanager code is written as though it might fail; i.e. it does 5
retries w/a 2-second delay in between. 

Gracias...

_______________________________________________
General
http://community.qnx.com/sf/go/post21497
Paul Kahn
02/05/2009 1:47 PM
post21501
Re: RE: RE: DHCP client startup -- Build problem   
"Out of curiosity, are your interface names being correctly found?"

I think so, yes. I can see as I step through the code that it's processing "en0", etc. Is that what you mean?  I'll 
double check when I can get back to this.

BTW, we wanted to migrate to 6.4.0 but were unable to because of some third-party software we're using. 

Thanks again.
Sean Boudreau(deleted)
02/05/2009 1:51 PM
post21503
Re: RE: RE: DHCP client startup -- Build problem   
On Thu, Feb 05, 2009 at 01:48:01PM -0500, Paul Kahn wrote:
> 
> BTW, we wanted to migrate to 6.4.0 but were unable to because of some third-party software we're using. 

Something proprietary or generally available?

-seanb
Paul Kahn
02/05/2009 1:56 PM
post21506
Re: RE: RE: DHCP client startup -- Build problem   
Generally available. It's a state machine tool: Rhapsody. They have a port for 6.3.2 but don't yet have something for 6.
4.0.

I've looked at their OS-specific sources and in particulate the QNX-specific code. It seems to me that it *should* work.
 But, again, this is a medical product so we can't just migrate until they say we can.
12Next

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems