--- Comment #3 from Kenneth Coombes <> ---
Thank you for feedback.

Thank you for the idea.  While the phone is not an Alcatel phone, I was indeed
able (in Wireshark 2.4 only) to disable the Alcatel-Lucent heuristic in Analyze
-> Enabled Protocols and get rid of the error.

Sounds good.
- The phone is indeed an NEC phone.  It is an NEC DT700/730G/820 series phone
running our Standard SIP firmware.
- The relay was a Cisco Catalyst with the "ip helper-address" command to
forward the DHCP Discover packets.  
- The DHCP server is Windows Server 2008 R2's DHCP server.
- The VoIP platform is an NEC UNIVERGE 3C UCM system.
- Option 66 is used by the phone as expected: it tells the phone where the boot
server is for firmware and configuration files.
- Option 60 in the DHCP Discover for this phone firmware will always be
"NECSDT700" even for DT820s).
- is an FTP server, HTTPS server, and TFTP Server (all hosted by
the UNIVERGE 3C server). The phone could use any of these protocols to download
FW and config files, but FTP is almost always used.
- Option 66 could be specified for these phone using any of the following
string formats:
 * [IP|FQDN] only (in this case, FTP is assumed)
 * ftp://[IP|FQDN]
 * https://[IP|FQDN]
 * tftp://[IP|FQDN]

Not sure how the heuristic part works (maybe key off of Option 60 in the
previous Discover?), but since the phone treats (sub)Option 66 in the standard
way, it would be nice to see it fully dissected as a Boot Server option (aka
TFTP Server Name per RFC).  There is nothing proprietary about it for the
phone.  The only reason to use DHCP Option 43 is where option 66 is already
being used in the same subnet by other non-NEC-phone hosts.


You are receiving this mail because:
You are watching all bug changes.
Sent via:    Wireshark-bugs mailing list <>

Reply via email to