DHCP Option 150

I'm wondering if anybody knows some way to configure the AEBS to distribute DHCP options - specifically, the TFTP server option 150. I've got a piece of development hardware that I have to flash over TFTP.
It's actually a home-theater receiver that I've been developing the firmware for. I had been simply running it in my lab on a separate network served by DHCP Turbo in Windows, but now I've moved it to my living room, so I can actually use the thing. It's stable in the lab, so I want to get some real-world use on it. I don't have a separate network drop out there - just the AEBS network.
I have a clunkier way to flash it, but I prefer using the netboot built into the receiver's CPU, which requires DHCP, and Option 150. There's no NV storage for the server address on board, without adding dedicated hardware.
The real problem here is that I actually want the thing on the AEBS network, since I've added a lot of internet connectivity to the box The separate network would just be for flashing, and so I have to keep switching networks between flashing and debugging. This will be even more of a pain, now that I've moved the receiver out of the lab.
I was hoping somebody knew about some super-secret backdoor configuration for the AEBS DHCP server. Not at all optimistic about this, but hope springs eternal.
My fallback is to set up a separate wireless network out to the living room, and keep running out to manually switch networks. Yuck.
-Rick

Novell's dhcp console only goes to Option 133...
If you have C-1, you might be able to add option 150 manually to the DHCP object. I've done something like that before for another option which never seemed to work well once you added it through the DHCP console...
--El
Originally Posted by netwo
Hi,
Is thers a way to add option 150 for dhcp for an array of tftp servers?Im using oes2 sp3.
thanks,

Similar Messages

  • SPA941 ignoring DHCP Option 66,150

    I've configured a HTTP provisioning server and have set up a Cisco ASA to send out the address via DHCP. Currently this setup works for the SPA504Gs which will get the address and provision correctly. The SPA941s however won't co-operate. They don't seem to get the settings from these options, however they do get the IP address via DHCP.
    Any help would be grateful thanks!

    With DHCP, you will need either option 150 or 66 configured. When the Phone boots and gets information from the DHCP Server the following order if followed to connect to the TFTP Server and download the configuration.
    1) Hardcoded TFTP Address
    2) DNS lookup of CiscoCM1
    3) Option 150
    4) DHCP si_addr field
    5) DHCP sname field
    6) Option 66

  • SPA122 - How to turn off "DHCP Option To Use" in the Provisioning tab using the XML configuration file?

    As default, SPA122 and SPA112 have DHCP Options 66, 160, 159 and 150 turned on.
    Our pre-provisioning process includes adding our default profile rule to our provisioning server for the device to pull its configuration files once the device has been added to an account.
    However, it seems like some customers have had problems with the device downloading the definite configuration file and manually turning off option Option 66 in the provisioning tab in the device solves this issue.
    Is there any option we could add to our pre-provisioning file so that it removes 66 from the "DHCP Option to Use" field in the provisioning tab?
    Please advise...

    Thanks Dan,
    I didn't know the dhcp server could serve different options to different classes of clients, I'll have to look that up!
    Moises
    so if your provisioning file has this line below (this is from a spa5xx config I had in my temp folder, so use the line from your provisioning file, or use the SPC tool to create a new default config for that device type)
    <DH<DHCP_Option_To_Use group="Provisioning/Configuration_Profile">66,160,159,150,60,43,125</DHCP_Option_To_Use>
    change it to
    <DH<DHCP_Option_To_Use group="Provisioning/Configuration_Profile">160,159,150,60,43,125</DHCP_Option_To_Use>
    Hope it helps,
    Provisioning guide is here
    Cisco IP Telephony Devices Provisioning Guide - Cisco Support Community
    Dan

  • Dnsmasq sends out its own ip as dns-server dhcp option

    Hi,
    i have a gateway / dns server on 192.168.1.1
    I have a dhcp server on 192.168.1.2 (dnsmasq)
    I configured dnsmasq to look into /etc/resolv.conf (well, that's actually default behavior) and use that to specify dns server when replying to client dhcp requests.
    However, it sends out its own ip instead, which is *not cool*.
    # cat /etc/resolv.conf
    nameserver 192.168.1.1
    #nameserver 127.0.0.1
    #nameserver 212.71.0.33
    # edpnet
    nameserver 212.71.0.33
    # grep -v ^# /etc/dnsmasq.conf | grep -v '^$'
    domain-needed
    bogus-priv
    dhcp-range=192.168.1.5,192.168.1.255,12h
    dhcp-host=q700
    dhcp-host=dieter-ws
    dhcp-host=dieter-dellD620-arch
    dhcp-host=gibran
    dhcp-host=hilde-compaq-arch
    dhcp-host=hilde-vbox-win
    dhcp-host=BRN_0441B3
    dhcp-option=option:router,192.168.1.1
    log-dhcp
    # cat /etc/hosts
    # /etc/hosts: static lookup table for host names
    #<ip-address> <hostname.domain.org> <hostname>
    127.0.0.1 localhost.localdomain localhost
    192.168.1.2 dieter-p4sci-arch server
    192.168.1.3 q700
    192.168.1.5 dieter-ws
    192.168.1.6 dieter-dellD620-arch
    192.168.1.7 dieter-delle5410-arch gibran
    192.168.1.8 hilde-compaq-arch
    192.168.1.9 hilde-vbox-win
    192.168.1.10 BRN_0441B3 hl5250
    178.79.146.162 dieter-linode1
    # End of file
    here's what I see in /var/log/daemon.log, when I start dnsmasq and do a dhcp request.
    Note the discrepancy between what it says as "using nameserver" and what it actually tells clients.
    Feb 12 18:10:50 dieter-p4sci-arch dnsmasq[2168]: started, version 2.55 cachesize 150
    Feb 12 18:10:50 dieter-p4sci-arch dnsmasq[2168]: compile time options: IPv6 GNU-getopt no-DBus no-I18N DHCP TFTP
    Feb 12 18:10:50 dieter-p4sci-arch dnsmasq-dhcp[2168]: DHCP, IP range 192.168.1.5 -- 192.168.1.255, lease time 12h
    Feb 12 18:10:50 dieter-p4sci-arch dnsmasq[2168]: reading /etc/resolv.conf
    Feb 12 18:10:50 dieter-p4sci-arch dnsmasq[2168]: using nameserver 212.71.0.33#53
    Feb 12 18:10:50 dieter-p4sci-arch dnsmasq[2168]: using nameserver 192.168.1.1#53
    Feb 12 18:10:50 dieter-p4sci-arch dnsmasq[2168]: read /etc/hosts - 10 addresses
    Feb 12 18:10:56 dieter-p4sci-arch dnsmasq-dhcp[2168]: 2764941049 available DHCP range: 192.168.1.5 -- 192.168.1.255
    Feb 12 18:10:56 dieter-p4sci-arch dnsmasq-dhcp[2168]: 2764941049 DHCPRELEASE(eth0) 192.168.1.5 80:ee:73:09:fa:94
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 available DHCP range: 192.168.1.5 -- 192.168.1.255
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 client provides name: dieter-ws
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 vendor class: dhcpcd-5.2.10:Linux-2.6.37-ARCH:i686:GenuineIntel
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 DHCPDISCOVER(eth0) 80:ee:73:09:fa:94
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 DHCPOFFER(eth0) 192.168.1.5 80:ee:73:09:fa:94
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 requested options: 1:netmask, 121:classless-static-route, 33:static-route,
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 requested options: 3:router, 6:dns-server, 12:hostname, 15:domain-name,
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 requested options: 26:mtu, 28:broadcast, 42:ntp-server, 51:lease-time,
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 requested options: 54:server-identifier, 58:T1, 59:T2, 119:domain-search
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 tags: known, eth0
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 next server: 192.168.1.2
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 1 option: 53:message-type 02
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 54:server-identifier 192.168.1.2
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 51:lease-time 00:00:a8:c0
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 58:T1 00:00:54:60
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 59:T2 00:00:93:a8
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 1:netmask 255.255.255.0
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 28:broadcast 192.168.1.255
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 6:dns-server 192.168.1.2
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 3:router 192.168.1.1
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 available DHCP range: 192.168.1.5 -- 192.168.1.255
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 client provides name: dieter-ws
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 vendor class: dhcpcd-5.2.10:Linux-2.6.37-ARCH:i686:GenuineIntel
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 DHCPREQUEST(eth0) 192.168.1.5 80:ee:73:09:fa:94
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 DHCPACK(eth0) 192.168.1.5 80:ee:73:09:fa:94 dieter-ws
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 requested options: 1:netmask, 121:classless-static-route, 33:static-route,
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 requested options: 3:router, 6:dns-server, 12:hostname, 15:domain-name,
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 requested options: 26:mtu, 28:broadcast, 42:ntp-server, 51:lease-time,
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 requested options: 54:server-identifier, 58:T1, 59:T2, 119:domain-search
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 tags: known, eth0
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 next server: 192.168.1.2
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 1 option: 53:message-type 05
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 54:server-identifier 192.168.1.2
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 51:lease-time 00:00:a8:c0
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 58:T1 00:00:54:60
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 59:T2 00:00:93:a8
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 1:netmask 255.255.255.0
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 28:broadcast 192.168.1.255
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 6:dns-server 192.168.1.2
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 9 option: 12:hostname dieter-ws
    Feb 12 18:11:00 dieter-p4sci-arch dnsmasq-dhcp[2168]: 3497735943 sent size: 4 option: 3:router 192.168.1.1

    1 yes, the dhcp server who's scope is full will not do a dhcp
    'offer'
    2 dhcp that answers fastest with a 'offer' will win. A delay is configurable (but changes nothing
    about the root scenario were the fastest will win)
    Note that if the scopes overlap on the servers, they might not lease out all the addresses in the scope.
    I would enlarge the scope as you will want to fence against unavailability of one of the servers (or a network connection for that matter). you currently have more addresses leased out than any set of two of your servers can offer.
    MCP/MCSA/MCTS/MCITP

  • Spa922 dhcp option error

    Cisco 881 Router config:
    ip dhcp excluded-address 10.1.0.129 10.1.0.130
    ip dhcp pool PHONES
       network 10.1.0.128 255.255.255.192
       domain-name blabla.com
       dns-server 10.0.2.11 10.0.2.24
       default-router 10.1.0.129
       option 42 ip 10.0.2.29 10.0.2.35
       option 150 ip 10.1.0.3
       option 66 ascii 10.1.0.3
       lease 31
    I have linksys spa922 phone with firmware 6.1.5(a) and some spa303, spa502..
    All the devices understand tftp options from dhcp server, but spa-922 not.
    I have log on debug server:
    Nov  6 09:03:09 10.1.0.131 System started: [email protected], reboot reason:H0
    Nov  6 09:03:09 10.1.0.131 System started: [email protected], reboot reason:H0
    Nov  6 09:03:09 10.1.0.131  subnet mask:    255.255.255.192
    Nov  6 09:03:09 10.1.0.131  gateway ip: 10.1.0.129
    Nov  6 09:03:09 10.1.0.131  dns servers(2):
    Nov  6 09:03:09 10.1.0.131 10.0.2.11
    Nov  6 09:03:09 10.1.0.131 10.0.2.24
    Nov  6 09:03:09 10.1.0.131
    Nov  6 09:03:10 10.1.0.131 IDBG: st-0
    Nov  6 09:03:10 10.1.0.131 src/dict_tftp.c: dictParseServerScp: 1501 script too short
    Nov  6 09:03:10 10.1.0.131 ---------- g_dict_enable[0]: 0, : -2621441
    Nov  6 09:03:10 10.1.0.131 syslog-ng[1328]: Error processing log message: <Embedded Msg>:   save param: 441 = 255 441
    Nov  6 09:03:10 10.1.0.131 DDE12 0 0
    Nov  6 09:03:10 10.1.0.131 dictTftpNum: 0
    Nov  6 09:03:10 10.1.0.131 paylen: 0
    Nov  6 09:03:10 10.1.0.131 Dict_N> Dict flash[1] err happened, check errcode1=1
    Nov  6 09:03:10 10.1.0.131 DICT_verify: 1
    Nov  6 09:03:10 10.1.0.131 Dict_N> Dict flash[1] err happened, check errcode2=1
    Nov  6 09:03:10 10.1.0.131 paylen: 0
    Nov  6 09:03:10 10.1.0.131 Dict_N> Dict flash[0] err happened, check errcode1=1
    Nov  6 09:03:10 10.1.0.131 DICT_verify: 1
    Nov  6 09:03:10 10.1.0.131 Dict_N> Dict flash[0] err happened, check errcode2=1
    Nov  6 09:03:10 10.1.0.131 3.0 deadbeef 48879
    Nov  6 09:03:10 10.1.0.131 DDE11 0 0
    Nov  6 09:03:10 10.1.0.131 DDE13 0 0
    Nov  6 09:03:10 10.1.0.131 [SCAPS]WaitTime:10
    Nov  6 09:03:10 10.1.0.131 [SCAPS]WaitTime:10
    Nov  6 09:03:11 10.1.0.131 [SCAPS]WaitTime:20
    Nov  6 09:03:11 10.1.0.131 [SCAPS]WaitTime:20
    Nov  6 09:03:12 10.1.0.131 [SCAPS]WaitTime:40
    Nov  6 09:03:12 10.1.0.131 [SCAPS]WaitTime:40
    Nov  6 09:03:14 10.1.0.131 [SCAPS]WaitTime:80
    Nov  6 09:03:14 10.1.0.131 [SCAPS]WaitTime:80
    Nov  6 09:03:14 10.1.0.131 Resolving 10.1.0.3
    What is the reason that the device does not accept dhcp option correctly?

    It is possible that SPA922 is using other option than SPA303. So at the first, you must found what option is triggering
    src/dict_tftp.c: dictParseServerScp: 1501 script too short
    error. Use option 150 but not option 66 and vice versa. It should reveal what option will cause the error.
    Also, you should catch the DHCP server's response packet. It's nice to know Cisco 881's configuration, but the bug may be in Cisco 881 itself. If it's response is malformed (in option used by SPA922 but ignored by SPA303, or SPA303 may be more resistent to bug than SPA922) then it's waste of time to play with SPA922's configuration.

  • Option 150

    Hello:
    I have read that the best option for configure the dhcp is use the dhcp custom option 150.
    I am not sure but I think that I must configure this in the dhcp server (a cisco router), like the address-pool or the dns server. Am I right?
    thanks
    antonio

    You can use your existing Microsoft or any other DHCP server that support custom options. An IOS router can also be used. You need option 150 configured in the DHCP server to support Cisco IP Phones with CM or CME.
    ip dhcp pool Phones
    network 10.1.1.0 /24
    default-router 10.1.1.254
    option 150 ip
    lease
    dns-server
    domain-name
    HTH
    Sankar
    PS: please remember to rate posts!

  • Wlan controller option 150

    Hi friend,
    Its posible enable option 150 (for phone) in wlan lan controller 5508, i want to create a DHCP POOL for my Wireless IP PHONE, but i can this option.
    other solución could be to use a DHCP externel ( like router), but the broadcast traffic dont pass from Wlan Controller to Router.
    Could you helpe me please.
    Marco.

    Marco,
         The DHCP server in the WLC is not fully functional.  You can only set the subnet, GW and DNS that the client uses.  You can't set any of the advanced features, like option 150 for the TFTP server.
    Now, under the interface for the phone subnet, what do you have set for the DHCP server?  if you set it to a router/switch/server the WLC will proxy the request to the device.  and the client will get the correct address.
    If you are using a secrity device, this won't work.  You'll need to disable DHCP proxy. 
    From the GUI Controller > Advanced > DHCP, and uncheck the box.
    From the CLI config dhcp proxy disable
    Once this is done, make sure you have the ip helper-address under the L3 interface and point to the DHCP server.
    HTH,
    Steve
    Please remember to rate helpful posts or to mark the question as answered so that it can be found later.

  • Option 150 on DHCPv6??

    Hi all,
    Is there a option 150 when configuring DHCPv6 on a IPv6 network?
    If not, is there an alternative?
    Thanks

    You can use your existing Microsoft or any other DHCP server that support custom options. An IOS router can also be used. You need option 150 configured in the DHCP server to support Cisco IP Phones with CM or CME.
    ip dhcp pool Phones
    network 10.1.1.0 /24
    default-router 10.1.1.254
    option 150 ip
    lease
    dns-server
    domain-name
    HTH
    Sankar
    PS: please remember to rate posts!

  • Multiple domains via DHCP (option 15)

    It seems Mac OS X (I use 10.4.10 but I suspect it affects many versions) is incompatible with receiving multiple domain names in a single string over DHCP Option 15.
    If DHCP returns Option 15 with "exampledomain.com eng.exampledomain.com", then any lookup (using dig, ping, Microsoft Entourage, etc.) of a non-fully qualified domain name will fail.
    You can see this in the /etc/resolv.conf file, which contains:
    domain exampledomain.com eng.exampledomain.com
    nameserver 10.X.X.1
    nameserver 10.X.X.2
    I know that putting multiple domains within the same "domain" option in DHCP is a proprietary hack but some networks still use this. Has anybody run into this and have they found a good resolution to make Mac OS X work with multiple domains?

    While a single mailbox can be configured to receive on multiple addresses (called "proxy addresses" or "aliases"), the mailbox is configured with only one primary SMTP address (outbound address).  So if your requirement is to send
    as the received address, you would not be able to do that with a single mailbox through normal means.
    Some people have developed a workaround to the above limitation by configuring Outlook to use multiple POP3 accounts for a single mailbox.  See this link for additional details: 
    http://blogs.technet.com/b/hot/archive/2012/04/26/how-to-add-an-alias-to-an-office-365-account-and-how-to-set-up-outlook-to-send-email-messages-as-this-alias.aspx
    I would also be sure to look at the client requirements for Exchange Online.  The supported version of Outlook is going to be Outlook 2010 SP2.  Older versions may work but would not be supported.  Outlook 2003 would at best possibly
    connect via POP3.
    Joseph Palarchio http://www.itworkedinthelab.com

  • Implement DHCP Option 60 in SPA100 series

    Hello,
    Is there any plan to implement DHCP Option 60(vendor class id) in SPA100 series devices in future FWs? CISCO SPA5xx series already has this option implemented.
    Regards,
    Josep.

    I'm not sure what exact device you mean saying "SPA100 series devices" but in SPA112 and SPA122 it is implemented already. I'm using it for long time. See catched packet:
        0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
                Hostname Option 12, length 6: "SPA112"
                Vendor-Class Option 60, length 12: "CISCO SPA112"
    Don't forget to mark thread as answered if it answers your question ...

  • DHCP Option Tags are not being applied...

    Hi,
    About to loose my mind... basically we are working towards a small WYSE Thin Client deployment in our environment.  The WYSE clients require to receive certain DHCP Option Tags to find the WCM server of which they receive their configuration from.  Same
    applies to the WDM Server as well.  The problem is no matter what we do, our test client is not receiving the custom option tags we've defined in our DHCP server.  
    DHCP Servers:
    vlan41
    10.40.1.206
    10.40.1.207
    Test Client:
    vlan46 - ip helpers defined on the switch
    Set to receive the same ip address from the DHCP server through the reservation route.
    Option Tags:
    186 - WDM Server - 10.40.1.184
    195 - WCM Server - 10.40.1.185
    196 - WCM Path - / 
    I've installed Wire Shark on the test client to monitor the DHCP activity.  The above custom options tags are not being pushed on to the client.  
    The Router, DNS Server and Domain Tags are being pushed.  So it's working but also not working????!!!
    Anybody with some insight to this problem?

    Hi hpaul_p
    In all fairness I'm about to give up... the vendor is not coming up with a solution and constantly blaming Microsoft.  To further test and confirm this wasn't a network issue, I've setup a secondary test environment using a 4 port switch, a client and
    a DHCP server.  Same results!!!  I'm really running out of time, so my work around is this:  I've setup a SRV records pointing to the WCM server... in your case this would be SRV record for the WDM server.  I've disabled the auto
    discovery functionality of the WDM Agent, for some reason it seems to be clashing with the WCM agent.  Since you will be using WDM only, don't disable auto discovery, tick the DNS SRV record from the Discovery Settings under the client agent. 
    I'm going to add the clients to the WDM server manually through their ip addresses so don't need auto discovery. From what I gather from the manuals the WCM searches for the repository or conifg servers in this order:  1. SRV 2.DNS (A record)
    3.DHCP (Options), I bet it's the same with WDM.  Though SRV and DNS methods has their limitations, if you will be using the default paths and credentials it shouldn't be a problem.  This is all I have have.  Steven Song I've forwarded you the
    DHCP database, if you find any problems with it please let me know.

  • DHCP option 60

    Does anyone know how I can configure Solaris DHCP server such that it will send option 60 and string "PXEClient" to DHCP clients that use PXE ? Thanks in advance for any help in this matter.
    Edmund Gean

    You should understand that DHCP 43 and DHCP 60 are both needed and ofcourse they combine together to send the controller IP address to a registering LAP. The DHCP server is configured for DHCP option 60 to know the Access points VCI string value. The DHCP option 43 is used to return the controller IP address in response to receiving a DHCP request from LAP specified in Option 60. Here is the CLI configuratione example:
    http://www.cisco.com/en/US/docs/wireless/access_point/1500/installation/guide/1500_axg.html

  • DHCP Option 100 corrupt

    The DHCP option 100 "Middle Tier server" is configured and
    added on the scope under "Other DHCP Options".
    The values set for option 100 are two operable IP-addresses, reflecting
    two running Middle Tier servers
    Problem:
    When a client gets it's DHCP-address, the registry values for
    the Middle Tier server is corrupted.
    The registry keys hosting the values are (reference TID 10092121 for
    details):
    HKLM\Software\Novell\ZENworks\<dword> MiddleTierDHCPOptionNumber
    (we use decimal value 100 as Option number)
    HKLM\Software\Novell\ZENworks\<string> MiddleTierAddress
    (we use 192.168.1.4 and 192.168.1.5 in the DHCP-scope)
    But the Middle Tier login fails after DHCP delivery.
    Looking at the registry on the client, the string values for the
    MiddleTierAddressis corrupted. Instead of showing the two correct
    IP-addresses, it shows just messed up characters like squares,
    bars and other cryptical signs at the end of the enrty.
    Without a DHCP delivery, things works ok, if the ZfD Agent is configured
    with the Middle Tier DNS name.
    The registry key holding the DHCP-distributed Middle Tier address is:
    HKLM\Software\Novell\ZENworks\<string> MiddleTierAddress
    After DHCP-distribution, in the Middle Tier login dialog, the squares
    appears like bold vertical bars. Middle Tier login then fails.
    Also found a related TID # 10089967.

    See:
    "Workstation receives corrupted middle tier address when middle tier address
    is"
    http://support.novell.com/cgi-bin/se...i?10099553.htm
    I'm sure Shaun or one of the SysOps could tell you the status of this issue.
    Regards
    Rolf Lidvall
    Swedish Radio (Ltd)

  • DHCP Option 82 on Solaris 8

    If DHCP option 82 is supported, how can I add it to my server?

    Thanks, I upgraded software to newest 1.3.0.59, then rebooted. After configuring ( only option 82 - no relay agent ) there is still no 82 option in dhcp discover packets.
    Wireshark with captured dhcp discover broadcast packet. Dhcp part:
    As You can see - there is no 82 option.
    All interfaces are trusted (dhcp snooping).
    Should I configure anything else to make it work ?
    regards,

  • MDT/WDS PXE Deployment - DHCP Options for both x64 and x86

    Alright, I've found out the option 66 & 67 information, as what to set for each. The problem I'm trying to figure out is what to use for the boot file for option 67. So far all the info I've found says this:
    Configure DHCP option 67 with the right boot image file.
    For 32-bits systems \boot\x86\wdsnbp.com
    For 64-bits systems \boot\x64\wdsnbp.com
    I want to be able to use this for both 32 and 64 bit Windows clients, but cannot find anywhere that specifies how I would be able to do both.

    DHCP Options (specifically 067) can have a significant impact on which NBP your client can access.  If you specify \Boot\x86\Wdsnbp.com you are forcing the client to the 32bit NBP.
    If you specify \Boot\x64\Wdsnbp.com you are forcing the client to the 64bit NBP.
    Niether option is an ideal solution, especially if you have a varied environment.
    I would take a look at the following article and see if it sheds some light on your question:
    PXE booting with WDS – DHCP Scope vs IP Helpers

Maybe you are looking for