Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 2859] HomePlug Dissector bug Warning

Date: Tue, 9 Sep 2008 08:47:49 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2859





--- Comment #5 from Luca Ceresoli <luca.ceresoli@xxxxxxxxx>  2008-09-09 08:47:46 PDT ---
(In reply to comment #4)
> be no surprises. The question is, does the device generating this frame adhere
> to the same spec?
It is *definitely* expected to: it's from the same manufacturer.
And actually it does adhere. Read on.

> The repair you described is indeed the way to go. Still, doing that doesn't
> seem to give a useful result either. This is what you get:
>
> Frame 1 (60 bytes on wire, 60 bytes captured)
> Ethernet II, Src: HewlettP_6a:ff:95, Dst: Broadcast
> HomePlug protocol
>     MAC Control Field: 2
>         Reserved
>         .000 0010 = Number of MAC Data Entries: 2
>     MAC Management Entry Header
>         000. .... = MAC Entry Version: 0
>         ...0 0100 = MAC Entry Type: Unknown (0x04)
>     MAC Management Entry Length: 9
>     Data: 011079D0D0B9E6CD0E
That's correct.
It's a Set NEK entry, 9 bytes long, and the content is sound (datasheet page
22).

>     MAC Management Entry Header
>         000. .... = MAC Entry Version: 0
>         ...1 1111 = MAC Entry Type: Unknown (0x1f)
>     MAC Management Entry Length: 3
>     Data: 588601
That's correct too.
This one is a Set TX characteristics, 3 bytes long, and at first sight the
content is correct (datasheet page 35).

> And then 29 bytes remain (padding to 60?). 
Yes, padding.

I dare say your fix is ok.


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.