Ethereal-dev: Re: [ethereal-dev] Ethereal Win32 libpcap patch.
> #ifdef WIN32
> -#define MONO_MEDIUM_FONT "-*-lucida console-medium-*-*-*-*-100-*-*-*-*-*-*"
> -#define MONO_BOLD_FONT "-*-lucida console-bold-*-*-*-*-100-*-*-*-*-*-*"
> +/* font that allows bold and regular */
> +#define MONO_MEDIUM_FONT "-unknown-courier new-normal-r-normal-*-*-110-*-*-m-*-windows-russian"
> +#define MONO_BOLD_FONT "-unknown-courier new-bold-r-normal-*-*-110-*-*-m-*-windows-russian"
>
> I think I'll avoid applying this patch. Nye vcye govaryat po-russki.
Da, ya slishkom mnogo ljet nazad izuchil ruskovo yazika, i slishkom
monogo zab'il.
Ed - just out of curiosity, why the Russian font?
> diff -u -r1.31 libpcap.c
> --- libpcap.c 2000/01/22 06:22:39 1.31
> +++ libpcap.c 2000/02/01 19:35:09
> @@ -160,6 +160,13 @@
> WTAP_ENCAP_LINUX_ATM_CLIP
> };
> #define NUM_PCAP_ENCAPS (sizeof pcap_encap / sizeof pcap_encap[0])
> +/*
> + * New Data-link level type for win32.
> + */
> +#ifdef WIN32
> +#define DLT_EN100MB 100 /* Ethernet (100Mb) */
I'm not sure why the folk at the Politecnico thought Fast Ethernet
needed its own DLT_ type - the whole point of Fast Ethernet was to let
the old software (and, I think, much of the old hardware) Just Work.
Oh, well. Perhaps the tcpdump.org folk should suggest that the
Politecnico folk re-license "pcap-win32.c" under the BSDL, so it can be
incorporated into the standard libpcap - but if it gets picked up, they
should probably nuke DLT_EN100MB (and, as per the below, DLT_PPP_WIN32)
and just use DLT_EN10MB for them; the "10MB" in "DLT_EN10MB" is
historical, and was there to distinguish it from the old experimental
Xerox *3* megabit Ethernet, which may have had smaller (16 bit?) MAC
addresses; it isn't necessary to have separate DLT_ values for different
speeds of "real" Ethernet. (This wouldn't oblige them to license the
drivers under the BSDL; they could remain GPLed. It might be useful for
the Politecnico folk not to have to maintain their own libpcap.)
> Do you have a "DLT_PPP_WIN32" trace available? We discovered that the
> NDIS type for "WAN" indicates a packet with a fake ethernet header on it.
> It is possible, if libpcap for win32 uses the same NDIS facility as
> NetXRay, that "DLT_PPP_WIN32" should really return WTAP_ENCAP_ETHERNET.
In particular, I infer from the diagram in the NT DDK that, for WAN
connections, the low-level WAN driver sends PPP frames up to the NDISWAN
NDIS module, which turns them into Ethernet frames and hands them to the
higher-layer protocols; my *suspicion* is that the packet-capture driver
used by NetXRay was inserted above NDISWAN.
The Politecnico di Torino version of "tcpdump" does
{ ether_if_print, DLT_PPP_WIN32 },
so it appears that it's treating Win32 PPP as being Ethernet,
suggesting that their packet-capture driver also appears above NDISWAN -
and that DLT_PPP_WIN32 should be mapped to WTAP_ENCAP_ETHERNET, not
WTAP_ENCAP_PPP.
(Another case of "why didn't they just use DLT_EN10MB?")
