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.