Bug 154082

Summary: decodes bootp/dhcp option 2 incorrectly
Product: [Fedora] Fedora Reporter: Don Russell <don>
Component: etherealAssignee: Radek Vokál <rvokal>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i586   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-15 07:26:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A small packet trace capturing the bootp/dhcp packets with a West of UTC time offset none

Description Don Russell 2005-04-07 05:11:10 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
When ethereal displays the formatted packet for a bootp/dhcp DHCPACK that contains option 2 (time offset), the value is not calculated correctly.

Ethereal is treating the value as 32-bit UNsigned value, but it is supposed to be a SIGNED value. (See RFC 2132, section 3.4 Time Offset)

Version-Release number of selected component (if applicable):
ethereal-0.10.10-1.FC3.1

How reproducible:
Always

Steps to Reproduce:
1. Need access to a dhcp server that sends option 2 and is West of UTC (so negative time offsets are used)
2. set up a capture to filter bootp packets where a server returns option 2.
3. display the decoded packet to see the value/interpretation of option 2.
4. say "ah ha!" and fix the code :-)
  

Actual Results:  Response from DHCP server ... 02 04 ff ff 9d 90 ... formatted as:

Option 2: Time Offset = 49709 days, 23 hours, 28 minutes, 16 seconds


Expected Results:  The data portion of the data (0xff ff 9d 90) must be interpreted as a SIGNED number ( -25200 decimal) and is the number of seconds offset from UTC.
This should display as:

Option 2: Time Offset = -7 hours
or
Option 2: Time Offset = 0 days, -7 hours, 0 minutes, 0 seconds


Additional info:
Comment 1 Radek Vokál 2005-04-11 08:51:26 UTC 
Can you provide an example capture file?
Comment 2 Don Russell 2005-04-11 20:06:38 UTC 
Created attachment 112985 [details]
A small packet trace capturing the bootp/dhcp packets with a West of UTC time offset

As requested, a small capture showing the time offset option (option 2)

Specifically, see packet 2.
Comment 3 Don Russell 2005-04-11 20:24:37 UTC 
In my original report I suggested the form to display the offset, but that gets
a little ugly for offsets that are not whole hours. Since offsets can't exceed
12 hours, including 0 days ia little redundant. Perhaps a more "traditional"
format of display "time" in hours, minutes and seconds...

Perhaps strftime with %X format flag: "Preferred time representation for the
current locale but without the date". (Though you definately don't want any sort
of am/pm indication)

Or, something like:
Option 2: Time Offset: UTC +/-hh:mm:ss
or
Option 2: Time Offest: West (UTC-) 7:00:00
or
Option 2: Time Offset: East (UTC+) 3:00:00

if the offset exceeds +/- 12 hours, just report it as the raw hex data and a
possible warning:

Option 2: Time Offset: (Exceeds +/- 12 hours) 0xaa bb cc dd

Well, just an idea. :-)

Thanks,
Don
Comment 4 Radek Vokál 2005-04-15 07:26:57 UTC 
Just got a message from ethereal upstream that this will be fixed in next release. 
It prints that packet as ... -7 hours ...