Bug 1056 – CSMA: padding not handled correctly for LLC encapsulation

Bug 1056 - CSMA: padding not handled correctly for LLC encapsulation


Summary:	CSMA: padding not handled correctly for LLC encapsulation

Status:	RESOLVED FIXED

Product:	ns-3
Classification:	Unclassified
Component:	devices
Version:	ns-3-dev
Hardware:	All All

Importance:	P5 normal
Assigned To:	Tom Henderson

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2011-02-16 14:29 UTC by Tom Goff
Modified:	2011-05-13 00:21 UTC (History)
CC List:	2 users (show)

See Also:

Attachments
Possible fix (1.63 KB, patch) 2011-02-16 14:29 UTC, Tom Goff	Details \| Diff
Add an attachment (proposed patch, testcase, etc.)

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

Description Tom Goff 2011-02-16 14:29:11 UTC

Created attachment 1036 [details]
Possible fix

The attached patch addresses two issues:

 - The length field should not include added padding.  From IEEE
   802.3-2008 section 3.2.6:

     If the value of this field is less than or equal to 1500 decimal
     (05DC hexadecimal), then the Length/ Type field indicates the
     number of MAC client data octets contained in the subsequent MAC
     Client Data field of the basic frame (Length interpretation).

     ...

     Regardless of the interpretation of the Length/Type field, if the
     length of the MAC Client Data field is less than the minimum
     required for proper operation of the protocol, a Pad field (a
     sequence of octets) will be added after the MAC Client Data field
     but prior to the FCS field, specified below.

  - Padding is added when sending but not stripped when receiving.

Comment 1 Tom Henderson 2011-05-13 00:21:16 UTC

changeset: 2bdd52256e8a