Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
-----Original Message-----
From: ethereal-dev-request@xxxxxxxxxxxx
[mailto:ethereal-dev-request@xxxxxxxxxxxx]
Sent: Thursday, November 09, 2000 1:01 PM
To: ethereal-dev@xxxxxxxxxxxx
Subject: Ethereal-dev digest, Vol 1 #55 - 13 msgs
Send Ethereal-dev mailing list submissions to
ethereal-dev@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://www.ethereal.com/mailman/listinfo/ethereal-dev
or, via email, send a message with subject or body 'help' to
ethereal-dev-request@xxxxxxxxxxxx
You can reach the person managing the list at
ethereal-dev-admin@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ethereal-dev digest..."
Today's Topics:
1. Re: new eigrp dissector, please commit (Guy Harris)
2. how to get mac address for DLPI (It's me)
3. Wiretap DLL and WinPcap (Gilbert Ramirez)
4. Re: MGCP plugin (Gilbert Ramirez)
5. Re: MGCP plugin (Guy Harris)
6. RE: Wiretap DLL and WinPcap (Fulvio Risso)
7. Re: MGCP plugin (Ed Warnicke)
8. Re: MGCP plugin (Ed Warnicke)
9. Re: MGCP plugin (andreas.sikkema@xxxxxxxxxxx)
10. Re: Wiretap DLL and WinPcap (andreas.sikkema@xxxxxxxxxxx)
11. Re: MGCP plugin (Ed Warnicke)
12. RE: RE: [Ethereal-users] Segmentation Fault on v0.
8.13-1 for Linux (Wiley, Rob)
--__--__--
Message: 1
Date: Wed, 8 Nov 2000 21:16:34 -0800
From: Guy Harris <gharris@xxxxxxxxxxxx>
To: Paul Ionescu <paul@xxxxxxxx>
Cc: ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] new eigrp dissector, please commit
On Thu, Nov 09, 2000 at 12:12:20AM +0200, Paul Ionescu wrote:
> I made an almost full dissector of EIGRP, using tvbuffs.
> It is a major rewrite and is not based on the old eigrp dissector
> because it was wrong in some points.
Checked in.
--__--__--
Message: 2
Date: Wed, 8 Nov 2000 22:07:38 -0800 (PST)
From: It's me <say_hullo@xxxxxxxxx>
Reply-To: say_hullo@xxxxxxxxx
To: ethereal-dev@xxxxxxxxxxxx
Subject: [Ethereal-dev] how to get mac address for DLPI
hi all,
i am using DLPI API for sending packets.
I have the IP address from the application
using my implementation. After assembling the UDP
and IP header i send the packet using DLPI.
but i need to specify the MAC address. How do
I get this address from the IP address that I have.
Basically is there any way i can use ARP (like data
link layer does). the assumption is that no prior
communication has been done with that IP address..so
that entry in not in the ARP cache.
cheers
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one Place.
http://shopping.yahoo.com/
--__--__--
Message: 3
Date: Thu, 9 Nov 2000 03:04:03 -0600
From: Gilbert Ramirez <gram@xxxxxxxxxx>
To: ethereal-dev@xxxxxxxxxxxx
Subject: [Ethereal-dev] Wiretap DLL and WinPcap
Here's where I am in making wiretap a DLL on win32.
I originally had problems because my instructions to build wiretap
as a DLL were causing a static version on the C library to be
linked into wiretap.dll, and another copy into tethereal.exe.
(I'm using tethereal as my test case since it's a bit
faster in compiling). I would not have noticed this except that
tethereal did not work. Wiretap.dll would create file descriptors and
pass them to tethereal.exe to use, but the file descriptors in
wiretap.dll were specific to the copy of the C library that wiretap.dll
held, and tethereal.exe would not honor those file descriptors.
I learned that the MSVC environment has 3 C libraries to link against:
LIBC.lib static, single-threaded
LIBCMT.lib static, multi-threaded
MSVCRT.dll dynamic, multi-threaded
(not to mention the debug versions of these)
Now I'm linking both wiretap.dll and tethereal.exe against msvcrt.dll,
the DLL version of the C library. That's all well and fine. They end
up sharing the same C library, and thus the same file descriptors.
However, I cannot link against libpcap.lib in this way. The objects in
libpcap.lib were compiled for use libcmt.lib, the static version of the
multi-threaded C library.
When I build a non-capturing version of tethereal.exe, without linking
with libpcap.lib, tethereal.exe works just fine (with wiretap.dll).
When I link tethereal.exe + libpcap.lib with no default
libraries, but do include msvcrt.lib, the linker complains about
unresolved symbols (_sys_nerr, from pcap.obj in libpcap.lib)
When I add LIBCMT.LIB to the link line, I get link errors regarding
multiple definitions of symbols (_exit, _mainCRTStartup, etc.)
Is there a way for me to link an executable using msvcrt.dll against
libpcap.lib, which contains objects compiled against LIBCMT.lib?
Or do I have to include the libpcap.lib sources from WPcapsrc in
the Ethereal distribution, convert the project file to a makefile, and
change the flags to either compile the objects in libpcap.lib against
msvcrt.dll, or do so *AND* make libpcap a DLL while I'm at it?
--gilbert
--__--__--
Message: 4
Date: Thu, 9 Nov 2000 04:07:30 -0600
From: Gilbert Ramirez <gram@xxxxxxxxxx>
To: Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx>
Cc: ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] MGCP plugin
On Wed, 8 Nov 2000 22:45:47 -0500 (EST)
Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx> wrote:
> OK. Here is the correction to that problem as well as several others
> plus a bit of cleanup . Please check this out and then check it in if it
> looks good to you.
>
> Ed
I checked it in. I question the definition of is_digit() and is_alpha() functions
in your code, however. Why not use isdigit() and isalpha() from the C library?
I have not added the Win32 Makefile.nmake yet.
--gilbert
--__--__--
Message: 5
Date: Thu, 9 Nov 2000 03:03:44 -0800
From: Guy Harris <gharris@xxxxxxxxxxxx>
To: Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx>
Cc: Gilbert_Ramirez@xxxxxxxxxx, ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] MGCP plugin
On Wed, Nov 08, 2000 at 10:45:47PM -0500, Ed Warnicke wrote:
> OK. Here is the correction to that problem as well as several others
> plus a bit of cleanup . Please check this out and then check it in if it
> looks good to you.
Just out of curiosity, why a plugin? I think plugins have to be
installed in order for Ethereal to use them - you can't just build
Ethereal and run it from the directory in which you built it.
--__--__--
Message: 6
From: "Fulvio Risso" <risso@xxxxxxxxx>
To: "Gilbert Ramirez" <gram@xxxxxxxxxx>
Cc: <ethereal-dev@xxxxxxxxxxxx>
Subject: RE: [Ethereal-dev] Wiretap DLL and WinPcap
Date: Thu, 9 Nov 2000 12:36:18 +0100
Hi.
We're almost ready for having WinPcap as dll. This (I guess) should solve
the problem.
If anyone want to test it, we're very happy to give him everything as a beta
tester.
Please let us know.
Cheers,
fulvio
> -----Original Message-----
> From: ethereal-dev-admin@xxxxxxxxxxxx
> [mailto:ethereal-dev-admin@xxxxxxxxxxxx]On Behalf Of Gilbert Ramirez
> Sent: Thursday, November 09, 2000 10:04
> To: ethereal-dev@xxxxxxxxxxxx
> Subject: [Ethereal-dev] Wiretap DLL and WinPcap
>
>
> Here's where I am in making wiretap a DLL on win32.
>
> I originally had problems because my instructions to build wiretap
> as a DLL were causing a static version on the C library to be
> linked into wiretap.dll, and another copy into tethereal.exe.
> (I'm using tethereal as my test case since it's a bit
> faster in compiling). I would not have noticed this except that
> tethereal did not work. Wiretap.dll would create file descriptors and
> pass them to tethereal.exe to use, but the file descriptors in
> wiretap.dll were specific to the copy of the C library that wiretap.dll
> held, and tethereal.exe would not honor those file descriptors.
>
> I learned that the MSVC environment has 3 C libraries to link against:
>
> LIBC.lib static, single-threaded
> LIBCMT.lib static, multi-threaded
> MSVCRT.dll dynamic, multi-threaded
>
> (not to mention the debug versions of these)
>
> Now I'm linking both wiretap.dll and tethereal.exe against msvcrt.dll,
> the DLL version of the C library. That's all well and fine. They end
> up sharing the same C library, and thus the same file descriptors.
>
> However, I cannot link against libpcap.lib in this way. The objects in
> libpcap.lib were compiled for use libcmt.lib, the static version of the
> multi-threaded C library.
>
> When I build a non-capturing version of tethereal.exe, without linking
> with libpcap.lib, tethereal.exe works just fine (with wiretap.dll).
>
> When I link tethereal.exe + libpcap.lib with no default
> libraries, but do include msvcrt.lib, the linker complains about
> unresolved symbols (_sys_nerr, from pcap.obj in libpcap.lib)
>
> When I add LIBCMT.LIB to the link line, I get link errors regarding
> multiple definitions of symbols (_exit, _mainCRTStartup, etc.)
>
> Is there a way for me to link an executable using msvcrt.dll against
> libpcap.lib, which contains objects compiled against LIBCMT.lib?
>
> Or do I have to include the libpcap.lib sources from WPcapsrc in
> the Ethereal distribution, convert the project file to a makefile, and
> change the flags to either compile the objects in libpcap.lib against
> msvcrt.dll, or do so *AND* make libpcap a DLL while I'm at it?
>
> --gilbert
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
--__--__--
Message: 7
Date: Thu, 9 Nov 2000 07:13:51 -0500 (EST)
From: Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx>
To: Gilbert Ramirez <gram@xxxxxxxxxx>
Cc: ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] MGCP plugin
You are right to question these functions and I appreciate you pointing
this out to me. I was unaware of the isalpha() and isdigit() functions
in the standard C library. I looked into them and determined that your
suggestion for using isdigit() is a good one. I will make the change
this evening. I do not however want to use isalpha(). According to the
man page on isalpha() on my box (Debian Woody):
isalpha()
checks for an alphabetic character; in the standard
"C" locale, it is equivalent to (isupper(c) ||
islower(c)). In some locales, there may be addi-
tional characters for which isalpha() is true--let-
ters which are neither upper case nor lower case.
RFC 2705 (MGCP) in laying out its grammar defines its ALPHA as in RFC
2234 which defines ALPHA as
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
I thus can't use isalpha() because in some locales it may return true
for other characters which do not match this definition.
Or at least that's my reading of the situation. Please feel free to
correct me if I'm mistaken (which I may well be).
Thank you very much for the suggestion, I do appreciate it.
Ed
On Thu, 9 Nov 2000, Gilbert Ramirez wrote:
> On Wed, 8 Nov 2000 22:45:47 -0500 (EST)
> Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx> wrote:
>
> > OK. Here is the correction to that problem as well as several others
> > plus a bit of cleanup . Please check this out and then check it in if it
> > looks good to you.
> >
> > Ed
>
> I checked it in. I question the definition of is_digit() and is_alpha() functions
> in your code, however. Why not use isdigit() and isalpha() from the C library?
>
> I have not added the Win32 Makefile.nmake yet.
>
> --gilbert
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
--__--__--
Message: 8
Date: Thu, 9 Nov 2000 07:30:34 -0500 (EST)
From: Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx>
To: Guy Harris <gharris@xxxxxxxxxxxx>
Cc: ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] MGCP plugin
Good question. Part of the reason that I wrote this plugin is that I
have a need to use ethereal in a production environment in which it
would be adventageus to be able to dissect MGCP. I really want to
as much as possible keep this production environment running the latest
actual RELEASE of ethereal. It may happen in the course of events that
I need to make some changes to the MGCP dissector to enhance its
functionality. The rev time to the next release of ethereal may
take a while. As a plugin I can simply drop my MGCP plugin into any
install of ethereal which is recent enough to supply the services I use.
If I screwed up I can just revert the plugin.
In summary I guess you could say I wrote the MGCP dissector as a plugin
because it increases the isolation of the MGCP dissector from ethereal.
I see this as a good thing. I was always taught that your modules should
be as weakly bound to each other as you can manage. This is just a
weakening of that bind. Increased modularity is good.
I believe your point about plugins needing to be installed to work
is correct, but once I put up a build/root dir and make installed
ethereal into it I actually found it was quicker to make install
in the ethereal/plugin/mgcp dir than it had previously been to
go through the whole static linking process for a dissector.
In general my personal bias would be towards more plugins, not less. For
the reasons I outlined above. If you don't think any of the above are
valid or if you can think of any other drawbacks to plugins please let
me know, I am quite curious.
Ed
On Thu, 9 Nov 2000, Guy Harris wrote:
> On Wed, Nov 08, 2000 at 10:45:47PM -0500, Ed Warnicke wrote:
> > OK. Here is the correction to that problem as well as several others
> > plus a bit of cleanup . Please check this out and then check it in if it
> > looks good to you.
>
> Just out of curiosity, why a plugin? I think plugins have to be
> installed in order for Ethereal to use them - you can't just build
> Ethereal and run it from the directory in which you built it.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
--__--__--
Message: 9
From: andreas.sikkema@xxxxxxxxxxx
To: <hagbard@xxxxxxxxxxxxxxxxxxx>
Cc: <ethereal-dev@xxxxxxxxxxxx>
Subject: Re: [Ethereal-dev] MGCP plugin
Date: Thu, 9 Nov 2000 13:57:21 +0100
> In summary I guess you could say I wrote the MGCP dissector as a plug=
in
> because it increases the isolation of the MGCP dissector from etherea=
l.
> I see this as a good thing. I was always taught that your modules sh=
ould
> be as weakly bound to each other as you can manage. This is just a
> weakening of that bind. Increased modularity is good.
I'd love to do this with the H.323 stuff, but because part of the proto=
cl
is Q.931 based I can't.... Well, I could put my own Q.931 dissector in
the plug-in, but that's a road I don't want to follow.
If only you could call an Ethereal basic function which returns the add=
ress=20
of the protocol dissector from a plugin, f.i.:
dissector_q931 =3D get_dissector_address("Q.931");
But apart from that, I think I still would have problems linking the pl=
ugin....
--=20
Andreas Sikkema
andreas.sikkema@xxxxxxxxxxx
=
--__--__--
Message: 10
From: andreas.sikkema@xxxxxxxxxxx
To: <gram@xxxxxxxxxx>
Cc: <ethereal-dev@xxxxxxxxxxxx>
Subject: Re: [Ethereal-dev] Wiretap DLL and WinPcap
Date: Thu, 9 Nov 2000 13:59:31 +0100
> Is there a way for me to link an executable using msvcrt.dll against
> libpcap.lib, which contains objects compiled against LIBCMT.lib?
> Or do I have to include the libpcap.lib sources from WPcapsrc in
> the Ethereal distribution, convert the project file to a makefile, an=
d
> change the flags to either compile the objects in libpcap.lib against=
> msvcrt.dll, or do so *AND* make libpcap a DLL while I'm at it?
I think I had the same problems when I wanted to create the H.323=20
dissectors as a plugin. I also couldn't find a solution. At one moment =
I was running around in circles just like you to get the linking proces=
s=20
to work. This gets really frustrating, very fast :-(
--=20
Andreas Sikkema
andreas.sikkema@xxxxxxxxxxx
=
--__--__--
Message: 11
Date: Thu, 9 Nov 2000 08:31:00 -0500 (EST)
From: Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx>
To: andreas.sikkema@xxxxxxxxxxx
Cc: ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] MGCP plugin
I've been thinking about this problem a bit myself. I've been eyeing
the SDP dissector because while it does a marvelous job of dissecting
SDP, it leaves something to be desired in the available set
of tags on which you can filter. If I were to want to take SDP the
same route and try to pluginize it I would need some way
for all of the places that call SDP (including my MGCP plugin) to figure
out how to use a plugin version of it, and more importantly, how to
cope with its absence (since one should be able to gracefully handle
the absence of any given plugin).
I'm still new enough to the root architecture of ethereal that I don't
really know if the above idea is viable or not, nor to I have any notion
what a good way to implement it would be.
I don't know if a pluginized H323 calling a pluginized Q.931 would
satisfy the license gods, but it is at least an interesting thought.
While I would far prefer to see a GPL based H323 dissector I do understand
the pain that writing it entails. I also understand the incredible
utility of being able to dissect H.323 if you work in that field.
I know my brother would KILL (probably several times over) for
an H.323 ethereal dissector.
But let us not reflame the license wars. I think this horse has already
been beaten to death previously on this list.
Ed
On Thu, 9 Nov 2000 andreas.sikkema@xxxxxxxxxxx wrote:
> > In summary I guess you could say I wrote the MGCP dissector as a plugin
> > because it increases the isolation of the MGCP dissector from ethereal.
> > I see this as a good thing. I was always taught that your modules should
> > be as weakly bound to each other as you can manage. This is just a
> > weakening of that bind. Increased modularity is good.
>
> I'd love to do this with the H.323 stuff, but because part of the protocl
> is Q.931 based I can't.... Well, I could put my own Q.931 dissector in
> the plug-in, but that's a road I don't want to follow.
>
> If only you could call an Ethereal basic function which returns the address
> of the protocol dissector from a plugin, f.i.:
> dissector_q931 = get_dissector_address("Q.931");
>
> But apart from that, I think I still would have problems linking the plugin....
>
> --
> Andreas Sikkema
> andreas.sikkema@xxxxxxxxxxx
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
--__--__--
Message: 12
From: "Wiley, Rob" <WileyR@xxxxxxxxxxxxxx>
To: Guy Harris <guy@xxxxxxxxxx>
Cc: Gilbert Ramirez <gram@xxxxxxxxxx>, ethereal-dev@xxxxxxxxxxxx
Subject: RE: [Ethereal-dev] RE: [Ethereal-users] Segmentation Fault on v0.
8.13-1 for Linux
Date: Thu, 9 Nov 2000 10:40:33 -0500
I found out trying to re-compile ethereal, I had GTK 1.2.8 libraries but
with 1.2.6 headers. I removed and re-installed GTK 1.2.8 and GTK-dev
1.2.8, recompiled ethereal v0.8.13 and everything is fine now.
-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxx]
Sent: Wednesday, November 08, 2000 5:10 PM
To: Wiley, Rob
Cc: Gilbert Ramirez; ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] RE: [Ethereal-users]
Segmentation Fault on v0.8.13-1 for Linux
> #1 0x80c5fb4 in close_cap_file (cf=0x816a880,
w=0x81c8ab8) at file.c:213
> #2 0x80c5e2d in open_cap_file (fname=0x81e7128
"/tmp/etherXXXXQkFcmN",
> is_tempfile=1, cf=0x816a880) at file.c:136
> #3 0x80c6466 in start_tail_cap_file (fname=0x81e7128
> "/tmp/etherXXXXQkFcmN", is_tempfile=1, cf=0x816a880) at
file.c:388
Those line numbers don't match the Ethereal 0.8.13 source
you get from
ethereal.com; either your C compiler is screwing up the line
numbers in
the symbol table, or you didn't compile the 0.8.13 source
from
ethereal.com. If the latter, perhaps somebody "improved" it
and broke
something.
What is Ethereal "v.0.8.13-1", and where did you get the
source?
--__--__--
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
End of Ethereal-dev Digest
- Prev by Date: RE: [Ethereal-dev] RE: [Ethereal-users] Segmentation Fault on v0. 8.13-1 for Linux
- Next by Date: [Ethereal-dev] mgcp plugin patch
- Previous by thread: RE: [Ethereal-dev] RE: [Ethereal-users] Segmentation Fault on v0. 8.13-1 for Linux
- Next by thread: [Ethereal-dev] mgcp plugin patch
- Index(es):
