| Bug ID |
8148
|
| Summary |
HomeplugAV dissector: Troubles decoding HPAV-1.1 packets
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
SVN
|
| Hardware |
x86
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 9738 [details]
Mixed HPAV V1.0/V1.1 message capture
Build Information:
Version 1.9.0 (SVN Rev 46800 from /trunk)
Copyright 1998-2012 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (32-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.34.1, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
without libnl, with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python,
with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with
PortAudio V19-devel (built Dec 25 2012), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 10.0 build 40219
--
The current HPAV dissector only works correctly for HPAV V1.0 packets. The
newer 500Mb/s devices use a mix of HPAV and HPAV-1.1 (HPAV2) messages.
I currently have an Allnet 168555 pair which uses an Atheros AR7400 with
firmware INT7400-MAC-5-0-5010-02-655-20101105-FINAL-B. Other devices may behave
differently.
I do not have access to the HPAV/HPAV2 standards, i.e. patching the
packet-homeplug-av.c is not a real option.
I have attached some capture files, maybe somebody can get us started with
these. (Apply filter: (homeplug_av.mmhdr.mmver == 1 && eth.type==0x88e1) to
select the V1.1 messages)
The HPAV-1.1 messages seem to have additional (reserved) fields or are using
uint16 instead of uint8. For example the MMType is always followed by an 0x0000
(== Fragmentation Management Info?). With Vendor MMEs the OUI (00 b0 52) would
be next. Some public MMEs seem to decode correctly (for example
Get-Bridge-Informations-Confirmation).
Also noticed that in the Network-Info-Conf messages the average PHY Tx/Rx data
rates are still one byte values but they have to be multiplied by 1.33
(==AA/80?) to get the values displayed by the "Homeplug AV Utility". Not sure
if this a constant or derived from other parameters.
Thanx,
Guus
You are receiving this mail because:
- You are watching all bug changes.