http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2194
--- Comment #11 from Jim Young <jyoung@xxxxxxx> 2008-03-12 19:51:29 GMT ---
Hello Jorg,
Thanks for providing a trace with a properly enabled Overload option! ;-)
So...
Enabling the overload option with a value of 1 allows access to the 'boot'
field to support an additional 128 bytes of bootp options space.
Enabling the overload option with a value of 2 allows access to the
'sname' field to support an additional 64 bytes of bootp options space.
Enabling the overload option with a value of 3 makes BOTH the 'sname' and
'boot' fields available to support an additional 192 bytes of bootp options.
Your example trace and your previous comments brings up a few questions:
If one enables the Overload feature (option 53) with a value of 3, where both
the bootp 'sname' and bootp 'file' fields are now available for bootp options,
is it legal to write an option that extends across the boundary between the
last byte of the 'sname' field (frame offset 0x95 in the sample trace you
uploaded) and the first byte of the 'file' field (frame offset 0x96)?
Assuming that it's possible to cross the sname/boot field boundry when the
overload option has a value of 3, should the "Server host name option overload"
section be displayed before the "Boot file name option overload"?
Should the display of the "Server host name:" and/or "Boot file name:" fields
earlier in the packet details display be changed to display some text to
indicate that one or both of these fields are "Overloaded" instead of the ASCII
string that is currently displayed?
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
