Re: DHCP

I flipped briefly through the bootp and dhcp RFCs - we're really
reinventing the wheel here. It looks like the player should just do bootp
in both cases, but use a different port number for the proprietary
discovery protocol.  Really the only difference is on the server, in terms
of how we decide the IP address to give.

Any objections to having bootp but *not* dhcp?  AFAIK all DHCP servers
support BOOTP; the only real downside to bootp for this application is
the lack of lease/renew functionality. I'll do bootp and we can decide
later if dhcp is necessary.

Sean


On Wed, 24 Oct 2001, Sean Adams wrote:

>
> Kevin,
>
> Yep, I understand and I agree, although I'm not entirely sure of all the
> specifics - I was just thinking out loud.
>
> Step by step then:
>
> 1. The player sends a UDP packet to the Ethernet broadcast address. What
> IP address should be specified in this packet?  Will Windows deliver it to
> the server application if the IP address is, say 255.255.255.255, or do we
> need to snoop the Ethernet port?  I know if it's an IP packet sent to say,
> 192.168.10.255, we'll get it. But if the player doesn't know the subnet
> address, can it still send a valid IP broadcast?  I guess I'll just
> look at the RFC for DHCP - would have taken me less time that writing
> this question :)
>
> 2. The server has figured out in advance which unused/phony IP address it
> will assign. How does it do this?  I guess we would do ARP lookups for
> random IP addresses on our subnet until we find one that's not there - can
> we rely on ping (saves bypassing IP stack), or should we worry about
> machines that respond to arp but not ICMP?
>
> 3. The server then replies to the hardware address that sent the request,
> with the IP destination set to the address we want to assign the player.
> The player gleans it's new IP address and we're done. No subnet mask or
> gateway is needed or allowed in this scheme.
>
>
> We will need to bypass Windows' IP stack to do this.  I've done
> plenty on this stuff in Linux, but does anyone have experience doing this
> on Windows?  I'm perfectly comfortable with what I'll need to do on the
> client side.
>
> Also I think it goes without saying that Linux users will *not* care to
> use this, so we only need to worry about Windows (and maybe MacOSX).
>
>
>
> On Wed, 24 Oct 2001, Kevin Murphy wrote:
>
> >
> > >Since the client needs only to talk to the PC, and not the Internet, all
> > >we should have to do is find an unused IP address and take it. EG if
> > >someone has a cable modem and their PC has a real, public IP address, it
> > >should be okay for us to just grab any unused IP on the same subnet. We
> > >don't care if the cable modem won't route it for us, as long as it's not
> > >set up to do anything stupid like proxy arp.
> > >
> > >I'm thinking the client should have three choices:
> > >
> > >- Configure manually
> > >- BOOTP/DHCP
> > >- Kludgy-but-very-simple/easy discovery mechanism
> >
> > This was precisely what I had recommended.  If there is no DHCP mechanism
> > in place, the server code provides something to that effect, simply grabbing
> > an IP and telling the player to use it.
> >
> > Maybe you misunderstood me?
> >
> > I would like to use the DHCP client support because I already have a server
> > configured, but most people don't.  So the server does some sniffing around,
> > determines the PC's address, and grabs a random IP address and then when
> > the client boots up, the information is provided by the server itself, instead of
> > a real full-fledged DHCP server.
> >
> > That make sense?
> >
> >
> >
> > -- Kevin Murphy
> > Project Manager / IT Director
> > Sargon Consulting
> >
> >
> >
>
>


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE VeriSign guide to security solutions for your web site: encrypting transactions, securing intranets, and more!
http://us.click.yahoo.com/UnN2wB/m5_CAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/