- This topic is empty.
1. July 2008 at 20:13 #1309
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?2. July 2008 at 7:45 #13411
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.
CG2. July 2008 at 13:15 #13412
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…3. July 2008 at 7:44 #13420
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.
CG3. July 2008 at 10:49 #13424
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.5. July 2008 at 22:04 #13432thinkthinMember
- Total Post: 1707
- Jacked into The Matrix
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,
-T7. July 2008 at 17:57 #13448
i tried again this morning with a wyse s10 running firmware 5.3.0_09, and it’s still not working.7. July 2008 at 18:12 #13449
ok, well this guy figured it out:
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.8. July 2008 at 18:46 #13455
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
CG8. July 2008 at 19:42 #13457
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.8. July 2008 at 21:12 #13458
You need newer firmware for the S10 then.
CG9. July 2008 at 14:22 #13473
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:
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.9. July 2008 at 14:47 #13476
Glad I could help.
- You must be logged in to reply to this topic.