This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 154082 - decodes bootp/dhcp option 2 incorrectly
decodes bootp/dhcp option 2 incorrectly
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: ethereal (Show other bugs)
3
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-07 01:11 EDT by Don Russell
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-15 03:26:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A small packet trace capturing the bootp/dhcp packets with a West of UTC time offset (1.45 KB, application/octet-stream)
2005-04-11 16:06 EDT, Don Russell
no flags Details

  None (edit)
Description Don Russell 2005-04-07 01:11:10 EDT
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 Vokal 2005-04-11 04:51:26 EDT
Can you provide an example capture file? 
Comment 2 Don Russell 2005-04-11 16:06:38 EDT
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 16:24:37 EDT
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 Vokal 2005-04-15 03:26:57 EDT
Just got a message from ethereal upstream that this will be fixed in next release. 
It prints that packet as ... -7 hours ...

Note You need to log in before you can comment on or make changes to this bug.