RE: [ECOS] DHCP w/ Win2K server?

RE: [ECOS] DHCP w/ Win2K server?

[Dan Conti]

Sorry, you will need to add a similar line for the RENEWING and
REBINDING cases in dhcp. 

> -----Original Message-----
> From: Dan Conti 
> Sent: Wednesday, November 28, 2001 2:39 PM
> To: ecos-discuss@sources.redhat.com
> Subject: RE: [ECOS] DHCP w/ Win2K server?
> 
> 
> I think we saw this at one point. IIRC (it's been a while), the eCos
> DHCP client assumes a gateway will be returned, and with linux dhcp
> servers one is returned by default, but on win2k it isn't. I 
> believe it
> says in the spec that you actually are supposed to request a gateway
> server ip if you want one, making this an eCos bug?
> 
> In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
> DHCPSTATE_REQUESTING), try adding the following line:
> 
> 	    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1
> );
> 
> to add the gateway request to the DHCP packet. I dont know if 
> there is a
> way to adjust the win2k dhcp server configuration to 
> automagically give
> this out though.
> 
> > -----Original Message-----
> > From: Grant Edwards [mailto:grante@visi.com]
> > Sent: Wednesday, November 28, 2001 2:35 PM
> > To: ecos-discuss@sources.redhat.com
> > Subject: [ECOS] DHCP w/ Win2K server?
> > 
> > 
> > 
> > From the "MS Windows continues to deteriorate" department...
> > 
> > I've had a customer complain that eCos DHCP client doesn't get
> > a gateway address when used with a Win2K server (WinNT is OK).
> > I've verified it by capturing network traffic between eCos and
> > our office's Win2K server: no gateway is sent by the DHCP
> > server. (Though BOFH claims it is.)
> > 
> > Has anybody else seen this problem?
> > 
> > Is there a setting in the Win2K DHCP server that needs to be
> > chanaged?  Both the customer and our BOFH claim that their
> > respective DHCP servers are configured to send gateway
> > addresses.
> > 
> > Needless to say, it works fine with Linux...  ;)
> > 
> > -- 
> > Grant Edwards
> > grante@visi.com
> > 
> 

Re: [ECOS] DHCP w/ Win2K server?

[Hugo Tyson]

"Dan Conti" <danc@iobjects.com> writes:
> Sorry, you will need to add a similar line for the RENEWING and
> REBINDING cases in dhcp.

> In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
> DHCPSTATE_REQUESTING), try adding the following line:
>
> 	    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1 );
>
> to add the gateway request to the DHCP packet. 

Thanks folks.  Shall I see to it and post a patch or will one of you come
up with a complete patch including ChangeLog?  

	- Huge

Re: [ECOS] DHCP w/ Win2K server?

[Hugo Tyson]

"Dan Conti" <danc@iobjects.com> writes:
> Sorry, you will need to add a similar line for the RENEWING and
> REBINDING cases in dhcp.

> In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
> DHCPSTATE_REQUESTING), try adding the following line:
>
> 	    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1 );
>
> to add the gateway request to the DHCP packet. 

Thanks folks.  Shall I see to it and post a patch or will one of you come
up with a complete patch including ChangeLog?  

	- Huge

RE: [ECOS] DHCP w/ Win2K server?

[Dan Conti]

Sorry, you will need to add a similar line for the RENEWING and
REBINDING cases in dhcp. 

> -----Original Message-----
> From: Dan Conti 
> Sent: Wednesday, November 28, 2001 2:39 PM
> To: ecos-discuss@sources.redhat.com
> Subject: RE: [ECOS] DHCP w/ Win2K server?
> 
> 
> I think we saw this at one point. IIRC (it's been a while), the eCos
> DHCP client assumes a gateway will be returned, and with linux dhcp
> servers one is returned by default, but on win2k it isn't. I 
> believe it
> says in the spec that you actually are supposed to request a gateway
> server ip if you want one, making this an eCos bug?
> 
> In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
> DHCPSTATE_REQUESTING), try adding the following line:
> 
> 	    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1
> );
> 
> to add the gateway request to the DHCP packet. I dont know if 
> there is a
> way to adjust the win2k dhcp server configuration to 
> automagically give
> this out though.
> 
> > -----Original Message-----
> > From: Grant Edwards [ mailto:grante@visi.com ]
> > Sent: Wednesday, November 28, 2001 2:35 PM
> > To: ecos-discuss@sources.redhat.com
> > Subject: [ECOS] DHCP w/ Win2K server?
> > 
> > 
> > 
> > From the "MS Windows continues to deteriorate" department...
> > 
> > I've had a customer complain that eCos DHCP client doesn't get
> > a gateway address when used with a Win2K server (WinNT is OK).
> > I've verified it by capturing network traffic between eCos and
> > our office's Win2K server: no gateway is sent by the DHCP
> > server. (Though BOFH claims it is.)
> > 
> > Has anybody else seen this problem?
> > 
> > Is there a setting in the Win2K DHCP server that needs to be
> > chanaged?  Both the customer and our BOFH claim that their
> > respective DHCP servers are configured to send gateway
> > addresses.
> > 
> > Needless to say, it works fine with Linux...  ;)
> > 
> > -- 
> > Grant Edwards
> > grante@visi.com
> > 
> 

RE: [ECOS] DHCP w/ Win2K server?

[Dan Conti]

> -----Original Message-----
> From: Hugo Tyson [mailto:hmt@redhat.com]
> Sent: Friday, November 30, 2001 9:16 AM
> Subject: Re: [ECOS] DHCP w/ Win2K server?
> 
> Well, it wasn't quite as easy as "easy enough" ;-)  See the patch...

*ouch*. Thinking back, i think we actually switched from linux dhcpd to
win2k dhcp at one point and didn't look back, which explains why we
never hit this issue.

RE: [ECOS] DHCP w/ Win2K server?

[Dan Conti]

> -----Original Message-----
> From: Hugo Tyson [ mailto:hmt@redhat.com ]
> Sent: Friday, November 30, 2001 9:16 AM
> Subject: Re: [ECOS] DHCP w/ Win2K server?
> 
> Well, it wasn't quite as easy as "easy enough" ;-)  See the patch...

*ouch*. Thinking back, i think we actually switched from linux dhcpd to
win2k dhcp at one point and didn't look back, which explains why we
never hit this issue.

RE: [ECOS] DHCP w/ Win2K server?

[Dan Conti]

Unfortunately my eCos version is a bit outdated at this point, so if i
gave you a patch it almost certainly wouldn't apply properly.

> -----Original Message-----
> From: Hugo Tyson [mailto:hmt@redhat.com]
> Sent: Thursday, November 29, 2001 10:17 AM
> To: ecos-discuss@sources.redhat.com; hmt@redhat.com
> Subject: Re: [ECOS] DHCP w/ Win2K server?
> 
> 
> 
> "Dan Conti" <danc@iobjects.com> writes:
> > Sorry, you will need to add a similar line for the RENEWING and
> > REBINDING cases in dhcp.
> 
> > In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
> > DHCPSTATE_REQUESTING), try adding the following line:
> >
> > 	    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, 
> TAG_GATEWAY, 1 );
> >
> > to add the gateway request to the DHCP packet. 
> 
> Thanks folks.  Shall I see to it and post a patch or will one 
> of you come
> up with a complete patch including ChangeLog?  
> 
> 	- Huge
> 
> 

Re: [ECOS] DHCP w/ Win2K server?

[Hugo Tyson]

"Dan Conti" <danc@iobjects.com> writes:
> Unfortunately my eCos version is a bit outdated at this point, so if i
> gave you a patch it almost certainly wouldn't apply properly.

OK, I'll get something together for the trunk.

I believe it will be good to add that tag to all *FOUR* places DHCP sends a
packet, DHCPSTATE_REQUESTING, RENEWING, REBINDING and the initial broadcast
one in INIT.  'Course I'll test it, but only with LINUX dhcpd.  Comments?

I'll place a patch which should be good for anoncvs here.

	- Huge
 
> > -----Original Message-----
> > From: Hugo Tyson [mailto:hmt@redhat.com]
> > Sent: Thursday, November 29, 2001 10:17 AM
> > To: ecos-discuss@sources.redhat.com; hmt@redhat.com
> > Subject: Re: [ECOS] DHCP w/ Win2K server?
> >=20
> >=20
> >=20
> > "Dan Conti" <danc@iobjects.com> writes:
> > > Sorry, you will need to add a similar line for the RENEWING and
> > > REBINDING cases in dhcp.
> >=20
> > > In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
> > > DHCPSTATE_REQUESTING), try adding the following line:
> > >
> > > 	    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST,=20
> > TAG_GATEWAY, 1 );
> > >
> > > to add the gateway request to the DHCP packet.=20
> >=20
> > Thanks folks.  Shall I see to it and post a patch or will one=20
> > of you come
> > up with a complete patch including ChangeLog? =20
> >=20
> > 	- Huge

Re: [ECOS] DHCP w/ Win2K server?

[Hugo Tyson]

Hugo Tyson <hmt@redhat.com> writes:
> "Dan Conti" <danc@iobjects.com> writes:
> > Unfortunately my eCos version is a bit outdated at this point, so if i
> > gave you a patch it almost certainly wouldn't apply properly.
> 
> OK, I'll get something together for the trunk.
> 
> I believe it will be good to add that tag to all *FOUR* places DHCP sends a
> packet, DHCPSTATE_REQUESTING, RENEWING, REBINDING and the initial broadcast
> one in INIT.  'Course I'll test it, but only with LINUX dhcpd.  

Interesting.  The LINUX dhcpd normally returns all these DHCP options:
        DHCP message: 5 ACK
        DHCP server id: 10.16.19.66
        DHCP time 51: 60
        DHCP time 58: 30
        DHCP time 59: 52
        subnet mask: 255.255.255.0
            gateway: 10.16.19.66
      domain server: 10.16.19.66
        domain name: hmt10.cambridge.redhat.com
       IP broadcast: 10.16.19.255

(Yes, this lease is very very short, it's my testbench obviously)
If I add:

    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1 );

then all I get back are these:
        DHCP message: 5 ACK
        DHCP server id: 10.16.19.66
        DHCP time 51: 60
            gateway: 10.16.19.66

(whether I add it in INIT case or not)

It seems obvious that what's happening is this: if the LINUX dhcpd sees no
specific option requests, it uses a sensible and generous list; if it sees
any specific request, it sends that option *only*.

So for backward compatibility, I shall add specific requests for *all*
those options that I am used to seeing - the absence of the "half time" and
"nearly done" times is particularly distressing.

	- Huge

Re: [ECOS] DHCP w/ Win2K server?

[Grant Edwards]

On Fri, Nov 30, 2001 at 01:11:01PM +0000, Hugo Tyson wrote:

> > I believe it will be good to add that tag to all *FOUR* places DHCP sends a
> > packet, DHCPSTATE_REQUESTING, RENEWING, REBINDING and the initial broadcast
> > one in INIT.  'Course I'll test it, but only with LINUX dhcpd.  
> 
> Interesting.  The LINUX dhcpd normally returns all these DHCP options:
>         DHCP message: 5 ACK
>         DHCP server id: 10.16.19.66
>         DHCP time 51: 60
>         DHCP time 58: 30
>         DHCP time 59: 52
>         subnet mask: 255.255.255.0
>             gateway: 10.16.19.66
>       domain server: 10.16.19.66
>         domain name: hmt10.cambridge.redhat.com
>        IP broadcast: 10.16.19.255
> 
> (Yes, this lease is very very short, it's my testbench obviously)
> If I add:
> 
>     set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1 );
> 
> then all I get back are these:
>         DHCP message: 5 ACK
>         DHCP server id: 10.16.19.66
>         DHCP time 51: 60
>             gateway: 10.16.19.66
> 
> (whether I add it in INIT case or not)
> 
> It seems obvious that what's happening is this: if the LINUX dhcpd sees no
> specific option requests, it uses a sensible and generous list; if it sees
> any specific request, it sends that option *only*.

Rats.  Mine does the same thing (even the 60 second lease
time).  Why didn't I notice that?

> So for backward compatibility, I shall add specific requests
> for *all* those options that I am used to seeing - the absence
> of the "half time" and "nearly done" times is particularly
> distressing.

As of a few months ago, those two times get defaulted to
reasonable values if they're not present (IIRC, the default
value calculation will match the default values used by the
Linux server: 1/2 and 3/4 of the lease time), but requesting
them is probably the right thing to do.

The lack of a netmask, OTOH, is the show stopper for me. :(

Fixing it's easy enough, but it's another half-day's worth of
electronic paper-shuffling to get the fix out.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] DHCP w/ Win2K server?

[Hugo Tyson]

> From: Grant Edwards <grante@visi.com>
> On Fri, Nov 30, 2001 at 01:11:01PM +0000, Hugo Tyson wrote:
> > If I add:
> > 
> >     set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1 );
> > 
> > then all I get back are these:
> >         DHCP message: 5 ACK
> >         DHCP server id: 10.16.19.66
> >         DHCP time 51: 60
> >             gateway: 10.16.19.66
> > 
> > (whether I add it in INIT case or not)
> > 
> > It seems obvious that what's happening is this: if the LINUX dhcpd sees no
> > specific option requests, it uses a sensible and generous list; if it sees
> > any specific request, it sends that option *only*.
> 
> Rats.  Mine does the same thing (even the 60 second lease
> time).  Why didn't I notice that?
> 
> > So for backward compatibility, I shall add specific requests
> > for *all* those options that I am used to seeing - the absence
> > of the "half time" and "nearly done" times is particularly
> > distressing.
> 
> As of a few months ago, those two times get defaulted to
> reasonable values if they're not present (IIRC, the default
> value calculation will match the default values used by the
> Linux server: 1/2 and 3/4 of the lease time), but requesting
> them is probably the right thing to do.

Indeed, the code in eCos does just that if it doesn't get the values.  But
I'd rather see all the stuff I'm used to seeing, IYSWIM - hence the far
larger patch that I applied.
 
> The lack of a netmask, OTOH, is the show stopper for me. :(
> 
> Fixing it's easy enough, but it's another half-day's worth of
> electronic paper-shuffling to get the fix out.

Well, it wasn't quite as easy as "easy enough" ;-)  See the patch...

	- Huge

Re: [ECOS] DHCP w/ Win2K server?

[Grant Edwards]

On Fri, Nov 30, 2001 at 05:15:58PM +0000, Hugo Tyson wrote:

> > > So for backward compatibility, I shall add specific requests
> > > for *all* those options that I am used to seeing - the absence
> > > of the "half time" and "nearly done" times is particularly
> > > distressing.
> > 
> > As of a few months ago, those two times get defaulted to
> > reasonable values if they're not present (IIRC, the default
> > value calculation will match the default values used by the
> > Linux server: 1/2 and 3/4 of the lease time), but requesting
> > them is probably the right thing to do.
> 
> Indeed, the code in eCos does just that if it doesn't get the values.  But
> I'd rather see all the stuff I'm used to seeing, IYSWIM - hence the far
> larger patch that I applied.
>  
> > The lack of a netmask, OTOH, is the show stopper for me. :(
> > 
> > Fixing it's easy enough, but it's another half-day's worth of
> > electronic paper-shuffling to get the fix out.
> 
> Well, it wasn't quite as easy as "easy enough" ;-)  See the patch...

Ah, the change to a variable sized tag required a bit of
additional infrastructure.  I'll try out the patch with Linux
and Win2K DHCP servers after lunch.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] DHCP w/ Win2K server?

[Grant Edwards]

On Fri, Nov 30, 2001 at 05:15:58PM +0000, Hugo Tyson wrote:

> > > So for backward compatibility, I shall add specific requests
> > > for *all* those options that I am used to seeing - the absence
> > > of the "half time" and "nearly done" times is particularly
> > > distressing.
> > 
> > As of a few months ago, those two times get defaulted to
> > reasonable values if they're not present (IIRC, the default
> > value calculation will match the default values used by the
> > Linux server: 1/2 and 3/4 of the lease time), but requesting
> > them is probably the right thing to do.
> 
> Indeed, the code in eCos does just that if it doesn't get the values.  But
> I'd rather see all the stuff I'm used to seeing, IYSWIM - hence the far
> larger patch that I applied.
>  
> > The lack of a netmask, OTOH, is the show stopper for me. :(
> > 
> > Fixing it's easy enough, but it's another half-day's worth of
> > electronic paper-shuffling to get the fix out.
> 
> Well, it wasn't quite as easy as "easy enough" ;-)  See the patch...

Ah, the change to a variable sized tag required a bit of
additional infrastructure.  I'll try out the patch with Linux
and Win2K DHCP servers after lunch.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] DHCP w/ Win2K server?

[Hugo Tyson]

> From: Grant Edwards <grante@visi.com>
> On Fri, Nov 30, 2001 at 01:11:01PM +0000, Hugo Tyson wrote:
> > If I add:
> > 
> >     set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1 );
> > 
> > then all I get back are these:
> >         DHCP message: 5 ACK
> >         DHCP server id: 10.16.19.66
> >         DHCP time 51: 60
> >             gateway: 10.16.19.66
> > 
> > (whether I add it in INIT case or not)
> > 
> > It seems obvious that what's happening is this: if the LINUX dhcpd sees no
> > specific option requests, it uses a sensible and generous list; if it sees
> > any specific request, it sends that option *only*.
> 
> Rats.  Mine does the same thing (even the 60 second lease
> time).  Why didn't I notice that?
> 
> > So for backward compatibility, I shall add specific requests
> > for *all* those options that I am used to seeing - the absence
> > of the "half time" and "nearly done" times is particularly
> > distressing.
> 
> As of a few months ago, those two times get defaulted to
> reasonable values if they're not present (IIRC, the default
> value calculation will match the default values used by the
> Linux server: 1/2 and 3/4 of the lease time), but requesting
> them is probably the right thing to do.

Indeed, the code in eCos does just that if it doesn't get the values.  But
I'd rather see all the stuff I'm used to seeing, IYSWIM - hence the far
larger patch that I applied.
 
> The lack of a netmask, OTOH, is the show stopper for me. :(
> 
> Fixing it's easy enough, but it's another half-day's worth of
> electronic paper-shuffling to get the fix out.

Well, it wasn't quite as easy as "easy enough" ;-)  See the patch...

	- Huge

Re: [ECOS] DHCP w/ Win2K server?

[Grant Edwards]

On Fri, Nov 30, 2001 at 01:11:01PM +0000, Hugo Tyson wrote:

> > I believe it will be good to add that tag to all *FOUR* places DHCP sends a
> > packet, DHCPSTATE_REQUESTING, RENEWING, REBINDING and the initial broadcast
> > one in INIT.  'Course I'll test it, but only with LINUX dhcpd.  
> 
> Interesting.  The LINUX dhcpd normally returns all these DHCP options:
>         DHCP message: 5 ACK
>         DHCP server id: 10.16.19.66
>         DHCP time 51: 60
>         DHCP time 58: 30
>         DHCP time 59: 52
>         subnet mask: 255.255.255.0
>             gateway: 10.16.19.66
>       domain server: 10.16.19.66
>         domain name: hmt10.cambridge.redhat.com
>        IP broadcast: 10.16.19.255
> 
> (Yes, this lease is very very short, it's my testbench obviously)
> If I add:
> 
>     set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1 );
> 
> then all I get back are these:
>         DHCP message: 5 ACK
>         DHCP server id: 10.16.19.66
>         DHCP time 51: 60
>             gateway: 10.16.19.66
> 
> (whether I add it in INIT case or not)
> 
> It seems obvious that what's happening is this: if the LINUX dhcpd sees no
> specific option requests, it uses a sensible and generous list; if it sees
> any specific request, it sends that option *only*.

Rats.  Mine does the same thing (even the 60 second lease
time).  Why didn't I notice that?

> So for backward compatibility, I shall add specific requests
> for *all* those options that I am used to seeing - the absence
> of the "half time" and "nearly done" times is particularly
> distressing.

As of a few months ago, those two times get defaulted to
reasonable values if they're not present (IIRC, the default
value calculation will match the default values used by the
Linux server: 1/2 and 3/4 of the lease time), but requesting
them is probably the right thing to do.

The lack of a netmask, OTOH, is the show stopper for me. :(

Fixing it's easy enough, but it's another half-day's worth of
electronic paper-shuffling to get the fix out.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] DHCP w/ Win2K server?

[Hugo Tyson]

Hugo Tyson <hmt@redhat.com> writes:
> "Dan Conti" <danc@iobjects.com> writes:
> > Unfortunately my eCos version is a bit outdated at this point, so if i
> > gave you a patch it almost certainly wouldn't apply properly.
> 
> OK, I'll get something together for the trunk.
> 
> I believe it will be good to add that tag to all *FOUR* places DHCP sends a
> packet, DHCPSTATE_REQUESTING, RENEWING, REBINDING and the initial broadcast
> one in INIT.  'Course I'll test it, but only with LINUX dhcpd.  

Interesting.  The LINUX dhcpd normally returns all these DHCP options:
        DHCP message: 5 ACK
        DHCP server id: 10.16.19.66
        DHCP time 51: 60
        DHCP time 58: 30
        DHCP time 59: 52
        subnet mask: 255.255.255.0
            gateway: 10.16.19.66
      domain server: 10.16.19.66
        domain name: hmt10.cambridge.redhat.com
       IP broadcast: 10.16.19.255

(Yes, this lease is very very short, it's my testbench obviously)
If I add:

    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1 );

then all I get back are these:
        DHCP message: 5 ACK
        DHCP server id: 10.16.19.66
        DHCP time 51: 60
            gateway: 10.16.19.66

(whether I add it in INIT case or not)

It seems obvious that what's happening is this: if the LINUX dhcpd sees no
specific option requests, it uses a sensible and generous list; if it sees
any specific request, it sends that option *only*.

So for backward compatibility, I shall add specific requests for *all*
those options that I am used to seeing - the absence of the "half time" and
"nearly done" times is particularly distressing.

	- Huge

Re: [ECOS] DHCP w/ Win2K server?

[Hugo Tyson]

Hugo Tyson <hmt@redhat.com> writes:
> "Dan Conti" <danc@iobjects.com> writes:
> > Unfortunately my eCos version is a bit outdated at this point, so if i
> > gave you a patch it almost certainly wouldn't apply properly.
> 
> OK, I'll get something together for the trunk.
> 
> I believe it will be good to add that tag to all *FOUR* places DHCP sends a
> packet, DHCPSTATE_REQUESTING, RENEWING, REBINDING and the initial broadcast
> one in INIT.  'Course I'll test it, but only with LINUX dhcpd.  Comments?
> 
> I'll place a patch which should be good for anoncvs here.

And here it is; rather more than the four-times-one-liner we expected...
Please followup here if anyone sees any problems with this tag set, and
requests to add or elide specifics, or if you need real configury of this.

	- Huge


Index: net/tcpip/current/ChangeLog
===================================================================
RCS file: /home/cvs/ecc/ecc/net/tcpip/current/ChangeLog,v
retrieving revision 1.147
diff -u -5 -p -r1.147 ChangeLog
--- net/tcpip/current/ChangeLog	2001/11/29 19:10:37	1.147
+++ net/tcpip/current/ChangeLog	2001/11/30 14:16:25
@@ -1,5 +1,21 @@
+2001-11-30  Hugo Tyson  <hmt@redhat.com>
+
+	* src/lib/dhcp_prot.c (set_default_dhcp_tags): New routine to
+	insert all the extra woffle we need neatly each time, keeping the
+	state machine's case arms to the real work.  The new thing this
+	sets is TAG_DHCP_PARM_REQ_LIST, with a list that matches the
+	default set we get from a LINUX dhcpd.  This is because M$ servers
+	need explicit requests for eg. TAG_GATEWAY.  Note that I have
+	included configuration to override the set of tags requested here
+	in the source, but not yet backed up by CDL - we'll see whether
+	anyone needs this.
+	(set_variable_tag): New routine to insert a variable pointed-to
+	data item rather than an int of 1,2 or 4 bytes.
+	(do_dhcp): Call set_default_dhcp_tags() every time we send a
+	packet, rather than ad hoc additions in each state.
+
 2001-11-29  Jonathan Larmour  <jlarmour@redhat.com>
 
 	* include/machine/ansi.h: No longer require BSD string function
 	compatibility macros (in fact they confuse things).
 
Index: net/tcpip/current/src/lib/dhcp_prot.c
===================================================================
RCS file: /home/cvs/ecc/ecc/net/tcpip/current/src/lib/dhcp_prot.c,v
retrieving revision 1.10
diff -u -5 -p -r1.10 dhcp_prot.c
--- net/tcpip/current/src/lib/dhcp_prot.c	2001/11/19 18:37:51	1.10
+++ net/tcpip/current/src/lib/dhcp_prot.c	2001/11/30 14:16:25
@@ -167,10 +167,54 @@ set_fixed_tag( struct bootp *ppkt,
         value >>= 8;
     }
     return true;
 }
 
+// Note that this does not permit changing the size of an extant tag.
+static int
+set_variable_tag( struct bootp *ppkt,
+               unsigned char tag,
+               cyg_uint8 *pvalue,
+               int len)
+{
+    unsigned char *op;
+
+    // Initially this will only scan the options field.
+    op = &ppkt->bp_vend[4];
+    while (*op != TAG_END) {
+        if ( op > &ppkt->bp_vend[BP_VEND_LEN-1] ) {
+            CYG_FAIL( "Oversize DHCP packet in set_variable_tag" );
+            return false;
+        }
+        if (*op == tag)                 // Found it...
+            break;
+        op += *(op+1)+2;
+    }
+    
+    if (*op == tag) { // Found it...
+        if ( *(op+1) != len ) {
+            CYG_FAIL( "Wrong size in set_variable_tag" );
+            return false;           // wrong size
+        }
+    }
+    else { // overwrite the end tag and install a new one
+        if ( op + len + 2 > &ppkt->bp_vend[BP_VEND_LEN-1] ) {
+            CYG_FAIL( "Oversize DHCP packet in set_variable_tag append" );
+            return false;
+        }
+        *op = tag;
+        *(op+1) = len;
+        *(op + len + 2) = TAG_END;
+    }
+    // and insert the value.  No order is implied.
+    op += 2;               // point to start of value
+    while ( len-- > 0 ) {
+        *op++ = *pvalue++;
+    }
+    return true;
+}
+
 // ------------------------------------------------------------------------
 // Bring up an interface enough to broadcast, before we know who we are
 
 static int
 bring_half_up(const char *intf, struct ifreq *ifrp )
@@ -404,10 +448,49 @@ static inline void new_lease( struct boo
 
     cyg_alarm_initialize( lease->alarm, lease->t1, 0 );
     cyg_alarm_enable( lease->alarm );
 }
 
+// ------------------------------------------------------------------------
+// Set all the tags we want to use when sending a packet.
+// This has expanded to a large, explicit set to interwork better
+// with a variety of DHCP servers.
+
+static void set_default_dhcp_tags( struct bootp *xmit )
+{
+    // Explicitly request full set of params that are default for LINUX
+    // dhcp servers, but not default for others.  This is rather arbitrary,
+    // but it preserves behaviour for people using those servers.
+    // Perhaps configury of this set will be needed in future?
+    //
+    // Here's the set:
+    static cyg_uint8 req_list[]  = {
+#ifdef CYGOPT_NET_DHCP_PARM_REQ_LIST_REPLACE
+        CYGOPT_NET_DHCP_PARM_REQ_LIST_REPLACE ,
+#else
+        TAG_DHCP_SERVER_ID    ,     //     DHCP server id: 10.16.19.66
+        TAG_DHCP_LEASE_TIME   ,     //     DHCP time 51: 60
+        TAG_DHCP_RENEWAL_TIME ,     //     DHCP time 58: 30
+        TAG_DHCP_REBIND_TIME  ,     //     DHCP time 59: 52
+        TAG_SUBNET_MASK       ,     //     subnet mask: 255.255.255.0
+        TAG_GATEWAY           ,     //     gateway: 10.16.19.66
+        TAG_DOMAIN_SERVER     ,     //     domain server: 10.16.19.66
+        TAG_DOMAIN_NAME       ,     //     domain name: hmt10.cambridge.redhat.com
+        TAG_IP_BROADCAST      ,     //     IP broadcast: 10.16.19.255
+#endif
+#ifdef CYGOPT_NET_DHCP_PARM_REQ_LIST_ADDITIONAL
+        CYGOPT_NET_DHCP_PARM_REQ_LIST_ADDITIONAL ,
+#endif
+    };
+
+    if ( req_list[0] ) // So that one may easily turn it all off by configury
+        set_variable_tag( xmit, TAG_DHCP_PARM_REQ_LIST,
+                          &req_list[0], sizeof( req_list ) );
+
+    // Explicitly specify our max message size.
+    set_fixed_tag( xmit, TAG_DHCP_MAX_MSGSZ, BP_MINPKTSZ, 2 );
+}
 
 // ------------------------------------------------------------------------
 // the DHCP state machine - this does all the work
 
 int
@@ -557,12 +640,12 @@ do_dhcp(const char *intf, struct bootp *
             bcopy(ifr.ifr_hwaddr.sa_data, &xmit->bp_chaddr, xmit->bp_hlen);
             bcopy(mincookie, xmit->bp_vend, sizeof(mincookie));
 
             // remove the next line to test ability to handle bootp packets.
             set_fixed_tag( xmit, TAG_DHCP_MESS_TYPE, DHCPDISCOVER, 1 );
-
-            set_fixed_tag( xmit, TAG_DHCP_MAX_MSGSZ, BP_MINPKTSZ, 2 );
+            // Set all the tags we want to use when sending a packet
+            set_default_dhcp_tags( xmit );
 
 #ifdef CYGDBG_NET_DHCP_CHATTER
             diag_printf( "---------DHCPSTATE_INIT sending:\n" );
             show_bootp( intf, xmit );
 #endif            
@@ -648,12 +731,12 @@ do_dhcp(const char *intf, struct bootp *
             // Fill in the BOOTP request - DHCPREQUEST packet
             xmit->bp_op = BOOTREQUEST;
             xmit->bp_flags = htons(0x8000); // BROADCAST FLAG
 
             set_fixed_tag( xmit, TAG_DHCP_MESS_TYPE, DHCPREQUEST, 1 );
-            set_fixed_tag( xmit, TAG_DHCP_MAX_MSGSZ, BP_MINPKTSZ, 2 );
-
+            // Set all the tags we want to use when sending a packet
+            set_default_dhcp_tags( xmit );
             // And this will be a new one:
             set_fixed_tag( xmit, TAG_DHCP_REQ_IP, ntohl(xmit->bp_yiaddr.s_addr), 4 );
             
 #ifdef CYGDBG_NET_DHCP_CHATTER
             diag_printf( "---------DHCPSTATE_REQUESTING sending:\n" );
@@ -765,12 +848,12 @@ do_dhcp(const char *intf, struct bootp *
             xmit->bp_flags = htons(0); // No BROADCAST FLAG
             // Use the *client* address here:
             xmit->bp_ciaddr.s_addr = xmit->bp_yiaddr.s_addr;
 
             set_fixed_tag( xmit, TAG_DHCP_MESS_TYPE, DHCPREQUEST, 1 );
-            set_fixed_tag( xmit, TAG_DHCP_MAX_MSGSZ, BP_MINPKTSZ, 2 );
-
+            // Set all the tags we want to use when sending a packet
+            set_default_dhcp_tags( xmit );
             // And this will be a new one:
             set_fixed_tag( xmit, TAG_DHCP_REQ_IP, ntohl(xmit->bp_yiaddr.s_addr), 4 );
             
             // Set unicast address to *server*
             server_addr.sin_addr.s_addr = res->bp_siaddr.s_addr;
@@ -864,12 +947,12 @@ do_dhcp(const char *intf, struct bootp *
             xmit->bp_flags = htons(0); // no BROADCAST FLAG
             // Use the *client* address here:
             xmit->bp_ciaddr.s_addr = xmit->bp_yiaddr.s_addr;
 
             set_fixed_tag( xmit, TAG_DHCP_MESS_TYPE, DHCPREQUEST, 1 );
-            set_fixed_tag( xmit, TAG_DHCP_MAX_MSGSZ, BP_MINPKTSZ, 2 );
-
+            // Set all the tags we want to use when sending a packet
+            set_default_dhcp_tags( xmit );
             // And this will be a new one:
             set_fixed_tag( xmit, TAG_DHCP_REQ_IP, ntohl(xmit->bp_yiaddr.s_addr), 4 );
             
 #ifdef CYGDBG_NET_DHCP_CHATTER
             diag_printf( "---------DHCPSTATE_REBINDING sending:\n" );

Re: [ECOS] DHCP w/ Win2K server?

[Hugo Tyson]

Hugo Tyson <hmt@redhat.com> writes:
> "Dan Conti" <danc@iobjects.com> writes:
> > Unfortunately my eCos version is a bit outdated at this point, so if i
> > gave you a patch it almost certainly wouldn't apply properly.
> 
> OK, I'll get something together for the trunk.
> 
> I believe it will be good to add that tag to all *FOUR* places DHCP sends a
> packet, DHCPSTATE_REQUESTING, RENEWING, REBINDING and the initial broadcast
> one in INIT.  'Course I'll test it, but only with LINUX dhcpd.  Comments?
> 
> I'll place a patch which should be good for anoncvs here.

And here it is; rather more than the four-times-one-liner we expected...
Please followup here if anyone sees any problems with this tag set, and
requests to add or elide specifics, or if you need real configury of this.

	- Huge


Index: net/tcpip/current/ChangeLog
===================================================================
RCS file: /home/cvs/ecc/ecc/net/tcpip/current/ChangeLog,v
retrieving revision 1.147
diff -u -5 -p -r1.147 ChangeLog
--- net/tcpip/current/ChangeLog	2001/11/29 19:10:37	1.147
+++ net/tcpip/current/ChangeLog	2001/11/30 14:16:25
@@ -1,5 +1,21 @@
+2001-11-30  Hugo Tyson  <hmt@redhat.com>
+
+	* src/lib/dhcp_prot.c (set_default_dhcp_tags): New routine to
+	insert all the extra woffle we need neatly each time, keeping the
+	state machine's case arms to the real work.  The new thing this
+	sets is TAG_DHCP_PARM_REQ_LIST, with a list that matches the
+	default set we get from a LINUX dhcpd.  This is because M$ servers
+	need explicit requests for eg. TAG_GATEWAY.  Note that I have
+	included configuration to override the set of tags requested here
+	in the source, but not yet backed up by CDL - we'll see whether
+	anyone needs this.
+	(set_variable_tag): New routine to insert a variable pointed-to
+	data item rather than an int of 1,2 or 4 bytes.
+	(do_dhcp): Call set_default_dhcp_tags() every time we send a
+	packet, rather than ad hoc additions in each state.
+
 2001-11-29  Jonathan Larmour  <jlarmour@redhat.com>
 
 	* include/machine/ansi.h: No longer require BSD string function
 	compatibility macros (in fact they confuse things).
 
Index: net/tcpip/current/src/lib/dhcp_prot.c
===================================================================
RCS file: /home/cvs/ecc/ecc/net/tcpip/current/src/lib/dhcp_prot.c,v
retrieving revision 1.10
diff -u -5 -p -r1.10 dhcp_prot.c
--- net/tcpip/current/src/lib/dhcp_prot.c	2001/11/19 18:37:51	1.10
+++ net/tcpip/current/src/lib/dhcp_prot.c	2001/11/30 14:16:25
@@ -167,10 +167,54 @@ set_fixed_tag( struct bootp *ppkt,
         value >>= 8;
     }
     return true;
 }
 
+// Note that this does not permit changing the size of an extant tag.
+static int
+set_variable_tag( struct bootp *ppkt,
+               unsigned char tag,
+               cyg_uint8 *pvalue,
+               int len)
+{
+    unsigned char *op;
+
+    // Initially this will only scan the options field.
+    op = &ppkt->bp_vend[4];
+    while (*op != TAG_END) {
+        if ( op > &ppkt->bp_vend[BP_VEND_LEN-1] ) {
+            CYG_FAIL( "Oversize DHCP packet in set_variable_tag" );
+            return false;
+        }
+        if (*op == tag)                 // Found it...
+            break;
+        op += *(op+1)+2;
+    }
+    
+    if (*op == tag) { // Found it...
+        if ( *(op+1) != len ) {
+            CYG_FAIL( "Wrong size in set_variable_tag" );
+            return false;           // wrong size
+        }
+    }
+    else { // overwrite the end tag and install a new one
+        if ( op + len + 2 > &ppkt->bp_vend[BP_VEND_LEN-1] ) {
+            CYG_FAIL( "Oversize DHCP packet in set_variable_tag append" );
+            return false;
+        }
+        *op = tag;
+        *(op+1) = len;
+        *(op + len + 2) = TAG_END;
+    }
+    // and insert the value.  No order is implied.
+    op += 2;               // point to start of value
+    while ( len-- > 0 ) {
+        *op++ = *pvalue++;
+    }
+    return true;
+}
+
 // ------------------------------------------------------------------------
 // Bring up an interface enough to broadcast, before we know who we are
 
 static int
 bring_half_up(const char *intf, struct ifreq *ifrp )
@@ -404,10 +448,49 @@ static inline void new_lease( struct boo
 
     cyg_alarm_initialize( lease->alarm, lease->t1, 0 );
     cyg_alarm_enable( lease->alarm );
 }
 
+// ------------------------------------------------------------------------
+// Set all the tags we want to use when sending a packet.
+// This has expanded to a large, explicit set to interwork better
+// with a variety of DHCP servers.
+
+static void set_default_dhcp_tags( struct bootp *xmit )
+{
+    // Explicitly request full set of params that are default for LINUX
+    // dhcp servers, but not default for others.  This is rather arbitrary,
+    // but it preserves behaviour for people using those servers.
+    // Perhaps configury of this set will be needed in future?
+    //
+    // Here's the set:
+    static cyg_uint8 req_list[]  = {
+#ifdef CYGOPT_NET_DHCP_PARM_REQ_LIST_REPLACE
+        CYGOPT_NET_DHCP_PARM_REQ_LIST_REPLACE ,
+#else
+        TAG_DHCP_SERVER_ID    ,     //     DHCP server id: 10.16.19.66
+        TAG_DHCP_LEASE_TIME   ,     //     DHCP time 51: 60
+        TAG_DHCP_RENEWAL_TIME ,     //     DHCP time 58: 30
+        TAG_DHCP_REBIND_TIME  ,     //     DHCP time 59: 52
+        TAG_SUBNET_MASK       ,     //     subnet mask: 255.255.255.0
+        TAG_GATEWAY           ,     //     gateway: 10.16.19.66
+        TAG_DOMAIN_SERVER     ,     //     domain server: 10.16.19.66
+        TAG_DOMAIN_NAME       ,     //     domain name: hmt10.cambridge.redhat.com
+        TAG_IP_BROADCAST      ,     //     IP broadcast: 10.16.19.255
+#endif
+#ifdef CYGOPT_NET_DHCP_PARM_REQ_LIST_ADDITIONAL
+        CYGOPT_NET_DHCP_PARM_REQ_LIST_ADDITIONAL ,
+#endif
+    };
+
+    if ( req_list[0] ) // So that one may easily turn it all off by configury
+        set_variable_tag( xmit, TAG_DHCP_PARM_REQ_LIST,
+                          &req_list[0], sizeof( req_list ) );
+
+    // Explicitly specify our max message size.
+    set_fixed_tag( xmit, TAG_DHCP_MAX_MSGSZ, BP_MINPKTSZ, 2 );
+}
 
 // ------------------------------------------------------------------------
 // the DHCP state machine - this does all the work
 
 int
@@ -557,12 +640,12 @@ do_dhcp(const char *intf, struct bootp *
             bcopy(ifr.ifr_hwaddr.sa_data, &xmit->bp_chaddr, xmit->bp_hlen);
             bcopy(mincookie, xmit->bp_vend, sizeof(mincookie));
 
             // remove the next line to test ability to handle bootp packets.
             set_fixed_tag( xmit, TAG_DHCP_MESS_TYPE, DHCPDISCOVER, 1 );
-
-            set_fixed_tag( xmit, TAG_DHCP_MAX_MSGSZ, BP_MINPKTSZ, 2 );
+            // Set all the tags we want to use when sending a packet
+            set_default_dhcp_tags( xmit );
 
 #ifdef CYGDBG_NET_DHCP_CHATTER
             diag_printf( "---------DHCPSTATE_INIT sending:\n" );
             show_bootp( intf, xmit );
 #endif            
@@ -648,12 +731,12 @@ do_dhcp(const char *intf, struct bootp *
             // Fill in the BOOTP request - DHCPREQUEST packet
             xmit->bp_op = BOOTREQUEST;
             xmit->bp_flags = htons(0x8000); // BROADCAST FLAG
 
             set_fixed_tag( xmit, TAG_DHCP_MESS_TYPE, DHCPREQUEST, 1 );
-            set_fixed_tag( xmit, TAG_DHCP_MAX_MSGSZ, BP_MINPKTSZ, 2 );
-
+            // Set all the tags we want to use when sending a packet
+            set_default_dhcp_tags( xmit );
             // And this will be a new one:
             set_fixed_tag( xmit, TAG_DHCP_REQ_IP, ntohl(xmit->bp_yiaddr.s_addr), 4 );
             
 #ifdef CYGDBG_NET_DHCP_CHATTER
             diag_printf( "---------DHCPSTATE_REQUESTING sending:\n" );
@@ -765,12 +848,12 @@ do_dhcp(const char *intf, struct bootp *
             xmit->bp_flags = htons(0); // No BROADCAST FLAG
             // Use the *client* address here:
             xmit->bp_ciaddr.s_addr = xmit->bp_yiaddr.s_addr;
 
             set_fixed_tag( xmit, TAG_DHCP_MESS_TYPE, DHCPREQUEST, 1 );
-            set_fixed_tag( xmit, TAG_DHCP_MAX_MSGSZ, BP_MINPKTSZ, 2 );
-
+            // Set all the tags we want to use when sending a packet
+            set_default_dhcp_tags( xmit );
             // And this will be a new one:
             set_fixed_tag( xmit, TAG_DHCP_REQ_IP, ntohl(xmit->bp_yiaddr.s_addr), 4 );
             
             // Set unicast address to *server*
             server_addr.sin_addr.s_addr = res->bp_siaddr.s_addr;
@@ -864,12 +947,12 @@ do_dhcp(const char *intf, struct bootp *
             xmit->bp_flags = htons(0); // no BROADCAST FLAG
             // Use the *client* address here:
             xmit->bp_ciaddr.s_addr = xmit->bp_yiaddr.s_addr;
 
             set_fixed_tag( xmit, TAG_DHCP_MESS_TYPE, DHCPREQUEST, 1 );
-            set_fixed_tag( xmit, TAG_DHCP_MAX_MSGSZ, BP_MINPKTSZ, 2 );
-
+            // Set all the tags we want to use when sending a packet
+            set_default_dhcp_tags( xmit );
             // And this will be a new one:
             set_fixed_tag( xmit, TAG_DHCP_REQ_IP, ntohl(xmit->bp_yiaddr.s_addr), 4 );
             
 #ifdef CYGDBG_NET_DHCP_CHATTER
             diag_printf( "---------DHCPSTATE_REBINDING sending:\n" );

Re: [ECOS] DHCP w/ Win2K server?

[Hugo Tyson]

"Dan Conti" <danc@iobjects.com> writes:
> Unfortunately my eCos version is a bit outdated at this point, so if i
> gave you a patch it almost certainly wouldn't apply properly.

OK, I'll get something together for the trunk.

I believe it will be good to add that tag to all *FOUR* places DHCP sends a
packet, DHCPSTATE_REQUESTING, RENEWING, REBINDING and the initial broadcast
one in INIT.  'Course I'll test it, but only with LINUX dhcpd.  Comments?

I'll place a patch which should be good for anoncvs here.

	- Huge
 
> > -----Original Message-----
> > From: Hugo Tyson [ mailto:hmt@redhat.com ]
> > Sent: Thursday, November 29, 2001 10:17 AM
> > To: ecos-discuss@sources.redhat.com; hmt@redhat.com
> > Subject: Re: [ECOS] DHCP w/ Win2K server?
> >=20
> >=20
> >=20
> > "Dan Conti" <danc@iobjects.com> writes:
> > > Sorry, you will need to add a similar line for the RENEWING and
> > > REBINDING cases in dhcp.
> >=20
> > > In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
> > > DHCPSTATE_REQUESTING), try adding the following line:
> > >
> > > 	    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST,=20
> > TAG_GATEWAY, 1 );
> > >
> > > to add the gateway request to the DHCP packet.=20
> >=20
> > Thanks folks.  Shall I see to it and post a patch or will one=20
> > of you come
> > up with a complete patch including ChangeLog? =20
> >=20
> > 	- Huge

RE: [ECOS] DHCP w/ Win2K server?

[Dan Conti]

Unfortunately my eCos version is a bit outdated at this point, so if i
gave you a patch it almost certainly wouldn't apply properly.

> -----Original Message-----
> From: Hugo Tyson [ mailto:hmt@redhat.com ]
> Sent: Thursday, November 29, 2001 10:17 AM
> To: ecos-discuss@sources.redhat.com; hmt@redhat.com
> Subject: Re: [ECOS] DHCP w/ Win2K server?
> 
> 
> 
> "Dan Conti" <danc@iobjects.com> writes:
> > Sorry, you will need to add a similar line for the RENEWING and
> > REBINDING cases in dhcp.
> 
> > In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
> > DHCPSTATE_REQUESTING), try adding the following line:
> >
> > 	    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, 
> TAG_GATEWAY, 1 );
> >
> > to add the gateway request to the DHCP packet. 
> 
> Thanks folks.  Shall I see to it and post a patch or will one 
> of you come
> up with a complete patch including ChangeLog?  
> 
> 	- Huge
> 
> 

RE: [ECOS] DHCP w/ Win2K server?

[Dan Conti]

I think we saw this at one point. IIRC (it's been a while), the eCos
DHCP client assumes a gateway will be returned, and with linux dhcp
servers one is returned by default, but on win2k it isn't. I believe it
says in the spec that you actually are supposed to request a gateway
server ip if you want one, making this an eCos bug?

In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
DHCPSTATE_REQUESTING), try adding the following line:

	    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1
);

to add the gateway request to the DHCP packet. I dont know if there is a
way to adjust the win2k dhcp server configuration to automagically give
this out though.

> -----Original Message-----
> From: Grant Edwards [mailto:grante@visi.com]
> Sent: Wednesday, November 28, 2001 2:35 PM
> To: ecos-discuss@sources.redhat.com
> Subject: [ECOS] DHCP w/ Win2K server?
> 
> 
> 
> From the "MS Windows continues to deteriorate" department...
> 
> I've had a customer complain that eCos DHCP client doesn't get
> a gateway address when used with a Win2K server (WinNT is OK).
> I've verified it by capturing network traffic between eCos and
> our office's Win2K server: no gateway is sent by the DHCP
> server. (Though BOFH claims it is.)
> 
> Has anybody else seen this problem?
> 
> Is there a setting in the Win2K DHCP server that needs to be
> chanaged?  Both the customer and our BOFH claim that their
> respective DHCP servers are configured to send gateway
> addresses.
> 
> Needless to say, it works fine with Linux...  ;)
> 
> -- 
> Grant Edwards
> grante@visi.com
> 

Re: [ECOS] DHCP w/ Win2K server?

[Grant Edwards]

On Wed, Nov 28, 2001 at 02:39:28PM -0800, Dan Conti wrote:

> I think we saw this at one point. IIRC (it's been a while), the
> eCos DHCP client assumes a gateway will be returned, and with
> linux dhcp servers one is returned by default, but on win2k it
> isn't. I believe it says in the spec that you actually are
> supposed to request a gateway server ip if you want one, making
> this an eCos bug?
> 
> In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
> DHCPSTATE_REQUESTING), try adding the following line:
> 
>     set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1 );

Yup, That did it.

I was about to dig out my RFC and look that one up.

This fix definitely needs to go into the CVS source tree.

Leave it to MS to figure out a way to screw with everybody by
strictly following an RFC for once.  :)

> I dont know if there is a way to adjust the win2k dhcp server
> configuration to automagically give this out though.

Probably not.  Providing a way to make Win2K servers backward
compatible with WinNT servers might discourage people from
upgrading all the clients.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] DHCP w/ Win2K server?

[Grant Edwards]

On Wed, Nov 28, 2001 at 02:39:28PM -0800, Dan Conti wrote:

> I think we saw this at one point. IIRC (it's been a while), the
> eCos DHCP client assumes a gateway will be returned, and with
> linux dhcp servers one is returned by default, but on win2k it
> isn't. I believe it says in the spec that you actually are
> supposed to request a gateway server ip if you want one, making
> this an eCos bug?
> 
> In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
> DHCPSTATE_REQUESTING), try adding the following line:
> 
>     set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1 );

Yup, That did it.

I was about to dig out my RFC and look that one up.

This fix definitely needs to go into the CVS source tree.

Leave it to MS to figure out a way to screw with everybody by
strictly following an RFC for once.  :)

> I dont know if there is a way to adjust the win2k dhcp server
> configuration to automagically give this out though.

Probably not.  Providing a way to make Win2K servers backward
compatible with WinNT servers might discourage people from
upgrading all the clients.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] DHCP w/ Win2K server?

[Dan Conti]

I think we saw this at one point. IIRC (it's been a while), the eCos
DHCP client assumes a gateway will be returned, and with linux dhcp
servers one is returned by default, but on win2k it isn't. I believe it
says in the spec that you actually are supposed to request a gateway
server ip if you want one, making this an eCos bug?

In net/tcpip/current/src/lib/dhcp_prot.c, around line 596 (in case
DHCPSTATE_REQUESTING), try adding the following line:

	    set_fixed_tag( xmit, TAG_DHCP_PARM_REQ_LIST, TAG_GATEWAY, 1
);

to add the gateway request to the DHCP packet. I dont know if there is a
way to adjust the win2k dhcp server configuration to automagically give
this out though.

> -----Original Message-----
> From: Grant Edwards [ mailto:grante@visi.com ]
> Sent: Wednesday, November 28, 2001 2:35 PM
> To: ecos-discuss@sources.redhat.com
> Subject: [ECOS] DHCP w/ Win2K server?
> 
> 
> 
> From the "MS Windows continues to deteriorate" department...
> 
> I've had a customer complain that eCos DHCP client doesn't get
> a gateway address when used with a Win2K server (WinNT is OK).
> I've verified it by capturing network traffic between eCos and
> our office's Win2K server: no gateway is sent by the DHCP
> server. (Though BOFH claims it is.)
> 
> Has anybody else seen this problem?
> 
> Is there a setting in the Win2K DHCP server that needs to be
> chanaged?  Both the customer and our BOFH claim that their
> respective DHCP servers are configured to send gateway
> addresses.
> 
> Needless to say, it works fine with Linux...  ;)
> 
> -- 
> Grant Edwards
> grante@visi.com
> 

[ECOS] DHCP w/ Win2K server?

[Grant Edwards]

From the "MS Windows continues to deteriorate" department...

I've had a customer complain that eCos DHCP client doesn't get
a gateway address when used with a Win2K server (WinNT is OK).
I've verified it by capturing network traffic between eCos and
our office's Win2K server: no gateway is sent by the DHCP
server. (Though BOFH claims it is.)

Has anybody else seen this problem?

Is there a setting in the Win2K DHCP server that needs to be
chanaged?  Both the customer and our BOFH claim that their
respective DHCP servers are configured to send gateway
addresses.

Needless to say, it works fine with Linux...  ;)

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] DHCP w/ Win2K server?

[Gary Thomas]

On Wed, 2001-11-28 at 15:35, Grant Edwards wrote:
> 
> >From the "MS Windows continues to deteriorate" department...
> 
> I've had a customer complain that eCos DHCP client doesn't get
> a gateway address when used with a Win2K server (WinNT is OK).
> I've verified it by capturing network traffic between eCos and
> our office's Win2K server: no gateway is sent by the DHCP
> server. (Though BOFH claims it is.)
> 
> Has anybody else seen this problem?
> 
> Is there a setting in the Win2K DHCP server that needs to be
> chanaged?  Both the customer and our BOFH claim that their
> respective DHCP servers are configured to send gateway
> addresses.
> 
> Needless to say, it works fine with Linux...  ;)

"it" is ambiguous - does this mean the client code works fine
with Linux and not with Win2K or that Linux as client works
fine with Win2K?

Re: [ECOS] DHCP w/ Win2K server?

[Grant Edwards]

On Wed, Nov 28, 2001 at 03:39:36PM -0700, Gary Thomas wrote:
> On Wed, 2001-11-28 at 15:35, Grant Edwards wrote:
> > 
> > >From the "MS Windows continues to deteriorate" department...
> > 
> > I've had a customer complain that eCos DHCP client doesn't get
> > a gateway address when used with a Win2K server (WinNT is OK).
> > I've verified it by capturing network traffic between eCos and
> > our office's Win2K server: no gateway is sent by the DHCP
> > server. (Though BOFH claims it is.)
> > 
> > Has anybody else seen this problem?
> > 
> > Is there a setting in the Win2K DHCP server that needs to be
> > chanaged?  Both the customer and our BOFH claim that their
> > respective DHCP servers are configured to send gateway
> > addresses.
> > 
> > Needless to say, it works fine with Linux...  ;)
> 
> "it" is ambiguous

Sorry about that. The eCos client works fine with a Linux
DHCP server (whatever is shipped with RH 6/7).  eCos client
code also works fine with an NT4 server and with a Novell (5.?)
server.

I'm going to try Linux-client and Win2K-server as soon as my
laptop is finished ripping a CD...

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] DHCP w/ Win2K server?

[Grant Edwards]

On Wed, Nov 28, 2001 at 03:39:36PM -0700, Gary Thomas wrote:
> On Wed, 2001-11-28 at 15:35, Grant Edwards wrote:
> > 
> > >From the "MS Windows continues to deteriorate" department...
> > 
> > I've had a customer complain that eCos DHCP client doesn't get
> > a gateway address when used with a Win2K server (WinNT is OK).
> > I've verified it by capturing network traffic between eCos and
> > our office's Win2K server: no gateway is sent by the DHCP
> > server. (Though BOFH claims it is.)
> > 
> > Has anybody else seen this problem?
> > 
> > Is there a setting in the Win2K DHCP server that needs to be
> > chanaged?  Both the customer and our BOFH claim that their
> > respective DHCP servers are configured to send gateway
> > addresses.
> > 
> > Needless to say, it works fine with Linux...  ;)
> 
> "it" is ambiguous

Sorry about that. The eCos client works fine with a Linux
DHCP server (whatever is shipped with RH 6/7).  eCos client
code also works fine with an NT4 server and with a Novell (5.?)
server.

I'm going to try Linux-client and Win2K-server as soon as my
laptop is finished ripping a CD...

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] DHCP w/ Win2K server?

[Gary Thomas]

On Wed, 2001-11-28 at 15:35, Grant Edwards wrote:
> 
> >From the "MS Windows continues to deteriorate" department...
> 
> I've had a customer complain that eCos DHCP client doesn't get
> a gateway address when used with a Win2K server (WinNT is OK).
> I've verified it by capturing network traffic between eCos and
> our office's Win2K server: no gateway is sent by the DHCP
> server. (Though BOFH claims it is.)
> 
> Has anybody else seen this problem?
> 
> Is there a setting in the Win2K DHCP server that needs to be
> chanaged?  Both the customer and our BOFH claim that their
> respective DHCP servers are configured to send gateway
> addresses.
> 
> Needless to say, it works fine with Linux...  ;)

"it" is ambiguous - does this mean the client code works fine
with Linux and not with Win2K or that Linux as client works
fine with Win2K?

[ECOS] DHCP w/ Win2K server?

[Grant Edwards]

From the "MS Windows continues to deteriorate" department...

I've had a customer complain that eCos DHCP client doesn't get
a gateway address when used with a Win2K server (WinNT is OK).
I've verified it by capturing network traffic between eCos and
our office's Win2K server: no gateway is sent by the DHCP
server. (Though BOFH claims it is.)

Has anybody else seen this problem?

Is there a setting in the Win2K DHCP server that needs to be
chanaged?  Both the customer and our BOFH claim that their
respective DHCP servers are configured to send gateway
addresses.

Needless to say, it works fine with Linux...  ;)

-- 
Grant Edwards
grante@visi.com