https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5164
--- Comment #5 from Guy Harris <guy@xxxxxxxxxxxx> 2012-10-23 13:52:24 PDT ---
And the guess offered for the problem is wrong, at least in the dissection
process. If it's PPPoE, as the "E" in "PPPoE" suggests, the packet (probably)
*is* an Ethernet packet (PPPoE "session" is assigned an Ethernet type, so it
*can* run over other link layers), but, as PPPoE "session" *is* assigned an
Ethernet type, an Ethernet packet containing a PPPoE "session" packet will not
be treated as if it contained an IP packet, it'll be handed to the PPPoE
dissector, which will then find the IP packet contained within it, and the UDP
packet contained within it, and (if set up to do so, either using port numbers
or the RTP heuristic), the RTP packet contained within it, and the RFC 2833
payload within it.
The VoIP call flow graph's data currently comes from an RTP tap, so it comes
from the RTP dissector; it's not doing its own bogus dissection that assumes
that the packets are IP-over-Ethernet.
So there may be a problem, but it's not something that involves fetching from a
fixed offset from the beginning of the packet. Without a capture, it's
probably going to be hard to find the problem; if the problem exists at all,
it's probably in the RTP dissector, and probably has nothing whatsoever to do
with PPPoE (unless an older version of the tap *was* doing such a bogus
dissection).
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.