Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154082 - decodes bootp/dhcp option 2 incorrectly
Summary: decodes bootp/dhcp option 2 incorrectly
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: ethereal
Version: 3
Hardware: i586
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Radek Vokal
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-07 05:11 UTC by Don Russell
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-15 07:26:57 UTC


Attachments (Terms of Use)
A small packet trace capturing the bootp/dhcp packets with a West of UTC time offset (deleted)
2005-04-11 20:06 UTC, Don Russell
no flags Details

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 Vokal 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 Vokal 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 ...


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