thin clients not interpreting dhcp options from vendor class

  • This topic is empty.
Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #1309
    Avatarmconigliaro
    Member
    • Total Post: 7
    • Newbie

    i have a wyse 1200le with firmware version 4.4.079, and i’ve been having trouble getting the device to parse the vendor dhcp options. i created a vendor class for vendor id “wyse-1000” and added dhcp options 161 and 162 to that class. with wireshark, i see that the thin client is sending “wyse-1000” as the vendor id and requesting options 161 and 162 (among several others). when i look at the reply from the server, i see dhcp option 43 (which, according to my research, contains the list of vendor specific options for the client to parse). however, these options never seem to get applied to the client.

    note that this only happens when i supply the options as part of a vendor class. if i dont use a class, everything works as expected. unfortunately, i need to use a vendor class for my wyse terminals, because our voip phones also use dhcp option 161 (but they do not supply a vendor id as part of their dhcp requests, making use of a phone vendor class impossible). any tips? is there a known bug in the firmware maybe?

    #13411
    ConfGenConfGen
    Keymaster
    • Total Post: 11116
    • Jedi Master
    • ★★★★★★★

    I am not aware of any bug regarding DHCP vendor class parsing.
    Why are you sending out option 43 at all?
    If you have trouble with option tag 161 already being used you can also remap the option tag on WT1200 to something else. Go to network preferences-options and enter a different value in the File Server row.

    CG

    #13412
    Avatarmconigliaro
    Member
    • Total Post: 7
    • Newbie

    hello, and thanks for the reply.

    maybe im wrong (i hope someone will correct me if i am), but from what i’ve read (and actually seen with wireshark), option 43 is not normally something you send out on your own, but a consequence of using vendor classes. as an example, if you specify options 161 and 162 as part of a vendor class, you will not see them in the dhcp reply from the server. instead, options 161 and 162 will be encapsulated within option 43. then its apparently up to the client to parse option 43 to retrieve the encapsulated “sub-options.”

    i realize its possible to remap options, but im trying to do this in an automated fashion. if i have to go to every thin client to do dhcp re-mapping, that kind of defeats the purpose.

    i have a strong suspicion that there is a bug in this version of the firmware for these units. in the previous version i had (4.1 i think), the units did not even send out a vendor class id. i wish i had newer firmware to test with…

    #13420
    ConfGenConfGen
    Keymaster
    • Total Post: 11116
    • Jedi Master
    • ★★★★★★★

    How could you configure option tag 161 twice on your DHCP server. If I try that it always tells me that this option is already available.
    Give us some steps how you have configured everything. This way we may be able help.

    CG

    #13424
    Avatarmconigliaro
    Member
    • Total Post: 7
    • Newbie

    when the client provides a user/vendor class identifier as part of its dhcp request, the server will reply with the options associated with the appropriate class. thus, it’s possible to define the same option many times.

    http://blogs.msdn.com/anto_rocks/archive/2005/02/25/380231.aspx
    http://support.microsoft.com/default.aspx/kb/240247

    #13432
    Avatarthinkthin
    Member
    • Total Post: 1707
    • Jacked into The Matrix
    • ★★★★★★

    Hi,
    I have seen this set up a link time ago on a site where there was a similar issue with the VoIP system using the same tags. My first step would be to get up to newer code, the version you have is old and many fixes and improvements have been made since that version,

    Cheers,
    -T

    #13448
    Avatarmconigliaro
    Member
    • Total Post: 7
    • Newbie

    i tried again this morning with a wyse s10 running firmware 5.3.0_09, and it’s still not working.

    #13449
    Avatarmconigliaro
    Member
    • Total Post: 7
    • Newbie

    ok, well this guy figured it out:

    http://www.freewysemonkeys.com/modules.php?name=Forums&file=viewtopic&t=859

    If I check the “Interpret DHCP vendor-specific info” box on the network options tab it works. If I uncheck it, it dosent.

    i tried this and confirmed that it does work, but the option is disabled by default. that means you need to visit every one of your thin clients to enable this option, which is absolutely ridiculous. totally defeats the purpose of the dhcp/ftp config method. thanks wyse.

    #13455
    ConfGenConfGen
    Keymaster
    • Total Post: 11116
    • Jedi Master
    • ★★★★★★★

    OK, good job in finding this.
    Here is a possible solution for you.
    Define a DNS host named “wyseftpfbc4tc” with the IP of your Fileserver.
    As long as a WTOS device did not have a fileserver configured at all it will fall back to trying a DNS name resolution of the above hardcoded host.

    Maybe this helps. Even if you only define two parameters on this fileservers wnos.ini:
    Fileserver=”my real FTP”
    DHCPVendorID=”Enter DHCP Vendor” ParseVendorInfo=yes

    Cheers
    CG

    #13457
    Avatarmconigliaro
    Member
    • Total Post: 7
    • Newbie

    unfortunately, i dont think the s10s try to resolve wyseftpfbc4tc. i just created that dns record and pointed it to an ftp server, but i never saw the terminal log in. so far, everyone i see in this forum talking about the magical wyseftpfbc4tc address is using a v10l.

    #13458
    ConfGenConfGen
    Keymaster
    • Total Post: 11116
    • Jedi Master
    • ★★★★★★★

    You need newer firmware for the S10 then.

    CG

    #13473
    Avatarmconigliaro
    Member
    • Total Post: 7
    • Newbie

    for the record, this workaround does work with the 6.x firmware. i created the wyseftpfbc4tc dns record as a cname that points to my real ftp server. then i created a /wnos/wnos.ini file with the following line:

    DHCPVendorID=”wyse-1000″ ParseVendorInfo=yes

    with factory default settings, the thin client grabs this very minimal wnos.ini during its first boot (enabling the ParseVendorInfo option). on subsequent reboots, everything works as expected.

    this hack is not ideal (i still insist that the ParseVendorInfo option should be enabled by default), but now i only have to instruct users to reboot their new thin clients twice. works for me. thanks for the help guys.

    #13476
    ConfGenConfGen
    Keymaster
    • Total Post: 11116
    • Jedi Master
    • ★★★★★★★

    Glad I could help.

    CG

Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.