osmocom
/
wireshark
14
0
Fork 1
Code Issues Pull Requests Projects Releases Wiki Activity

Explain why we have to be ready to handle Ethernet frames with 

protocol type values that are PPP protocol types.

svn path=/trunk/; revision=3554
This commit is contained in:
Guy Harris 2001-06-15 20:23:41 +00:00
parent 738fe781f9
commit 4a5b324abb
2 changed files with 37 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
packet-ethertype.c
View File

@ -1,7 +1,7 @@
/* ethertype.c
* Routines for calling the right protocol for the ethertype.
*
* $Id: packet-ethertype.c,v 1.16 2001/06/14 20:37:07 guy Exp $
* $Id: packet-ethertype.c,v 1.17 2001/06/15 20:23:41 guy Exp $
*
* Gilbert Ramirez <gram@xiexie.org>
*
@ -75,9 +75,19 @@ const value_string etype_vals[] = {
{ETHERTYPE_ETHBRIDGE, "Transparent Ethernet bridging" },
/*
* XXX - is there a standard for running PPP protocols atop
* Ethernet, using the PPP protocol type value as the
* Ethernet protocol type value?
* NDISWAN on Windows translates Ethernet frames from higher-level
* protocols into PPP frames to hand to the PPP driver, and translates
* PPP frames from the PPP driver to hand to the higher-level protocols.
*
* Apparently the PPP driver, on at least some versions of Windows,
* passes frames for internal-to-PPP protocols up through NDISWAN;
* the protocol type field appears to be passed through unchanged
* (unlike what's done with, for example, the protocol type field
* for IP, which is mapped from its PPP value to its Ethernet value).
*
* This means that we may see, on Ethernet captures, frames for
* protocols internal to PPP, so we list as "Ethernet" protocol
* types the PPP protocol types we've seen.
*/
{PPP_IPCP, "PPP IP Control Protocol" },
{PPP_LCP, "PPP Link Control Protocol" },

24
packet-ppp.c
View File

@ -1,7 +1,7 @@
/* packet-ppp.c
* Routines for ppp packet disassembly
*
* $Id: packet-ppp.c,v 1.64 2001/06/14 20:05:12 guy Exp $
* $Id: packet-ppp.c,v 1.65 2001/06/15 20:23:41 guy Exp $
*
* Ethereal - Network traffic analyzer
* By Gerald Combs <gerald@ethereal.com>
@ -1492,6 +1492,23 @@ void
proto_reg_handoff_lcp(void)
{
dissector_add("ppp.protocol", PPP_LCP, dissect_lcp, proto_lcp);
/*
* NDISWAN on Windows translates Ethernet frames from higher-level
* protocols into PPP frames to hand to the PPP driver, and translates
* PPP frames from the PPP driver to hand to the higher-level protocols.
*
* Apparently the PPP driver, on at least some versions of Windows,
* passes frames for internal-to-PPP protocols up through NDISWAN;
* the protocol type field appears to be passed through unchanged
* (unlike what's done with, for example, the protocol type field
* for IP, which is mapped from its PPP value to its Ethernet value).
*
* This means that we may see, on Ethernet captures, frames for
* protocols internal to PPP, so we register PPP_LCP with the
* "ethertype" dissector table as well as the PPP protocol dissector
* table.
*/
dissector_add("ethertype", PPP_LCP, dissect_lcp, proto_lcp);
}
@ -1514,5 +1531,10 @@ void
proto_reg_handoff_ipcp(void)
{
dissector_add("ppp.protocol", PPP_IPCP, dissect_ipcp, proto_ipcp);
/*
* See above comment about NDISWAN for an explanation of why we're
* registering with the "ethertype" dissector table.
*/
dissector_add("ethertype", PPP_IPCP, dissect_ipcp, proto_ipcp);
}