Hi,
How to get a attachment file from captured email.
Thanks,
Sridhar
-------Original Message-------
Date: 02/22/06 16:36:36
Subject: Ethereal-dev Digest, Vol 34, Issue 35
Send Ethereal-dev mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ethereal-dev digest..."
Today's Topics:
1. Re: mergecap: How to merge Ethernet & Linux cooked capture
files? (Guy Harris)
2. Re: mergecap: How to merge Ethernet & Linux cooked capture
files? (Guy Harris)
3. Re: mergecap: How to merge Ethernet & Linux cooked capture
files? (Guy Harris)
4. RE: mergecap: How to merge Ethernet & Linux cookedcapture
files? (Maynard, Chris)
5. Re: mergecap: How to merge Ethernet & Linux cooked capture
files? (Aaron Turner)
6. Re: mergecap: How to merge Ethernet & Linux cookedcapture
files? (LEGO)
7. RE: mergecap: How to merge Ethernet & Linuxcookedcapture
files? (Maynard, Chris)
8. Re: mergecap: How to merge Ethernet & Linux cookedcapture
files? (Guy Harris)
9. Re: mergecap: How to merge Ethernet & Linuxcookedcapture
files? (Guy Harris)
10. Re: mergecap: How to merge Ethernet & Linuxcookedcapture
files? (LEGO)
11. Re: Lua: where to find V2P.pm (Joerg Mayer)
12. RE: mergecap: How to merge Ethernet & Linux cookedcapture
files? (Maynard, Chris)
13. Re: Lua: where to find V2P.pm (LEGO)
14. Re: mergecap: How to merge Ethernet & Linux cookedcapture
files? (Aaron Turner)
15. RE: mergecap: How to merge Ethernet & Linuxcookedcapture
files? (Maynard, Chris)
16. Re: Re: Using USER DLT for RNSAP (over SCCP) (Roger Mahler)
17. Fallen at the first hurdle :( (Dave Ramsey)
18. Re: Re: Re: Using USER DLT for RNSAP (over SCCP) (LEGO)
19. Re: Fallen at the first hurdle :( (Ulf Lamping)
20. Re: IPsec dissector to decrypt ESP Payload (Gerald Combs)
21. RE: Fallen at the first hurdle :( (Dave Ramsey)
22. buildbot failure in Fedora-Core-4-IA32
23. Re: buildbot failure in Fedora-Core-4-IA32 (LEGO)
24. RE: Fallen at the first hurdle :( (Guy Harris)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Feb 2006 10:42:13 -0800
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cooked capture files?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Maynard, Chris wrote:
> I have 2 capture files that I would like to merge. One file has IEEE
> 802.3 Ethernet encapsulation and the other has Linux cooked capture
> encapsulation.
>
> I have been unsuccessful at merging them, trying things like,
> "mergecap -T ether -w merge.cap eth.cap cooked.cap"
> "mergecap -T linux-ssl merge.cap eth.cap cooked.cap"
> .... but in the first case, only the eth.cap packets are correctly
> dissected, and in the second case, only the cooked.cap packets are
> correctly dissected.
"-T" doesn't mean "reformat the content of the packets to actually have
a link-layer header of that type", it means "assume the packets already
have a link-layer header of that type, but the file has the wrong
link-layer type, and write out the packets in the new link-layer type".
> Is it possible to merge these two files?
No. Libpcap format only supports one link-layer type in a capture file,
and no other capture file format supported by Ethereal's Wiretap
capture-file-reading library supports the Linux cooked capture
encapsulation.
> If not, then what
> would it take to be able to support this type of merge?
Add support for pcap-NG format:
to the Wiretap library and to Ethereal, Tethereal, and mergecap; that
format supports multiple link-layer types in a file. The resulting
files will, of course, only be readable by programs that support pcap-NG.
work on that.
------------------------------
Message: 2
Date: Wed, 22 Feb 2006 10:43:24 -0800
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cooked capture files?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sake Blok wrote:
> I have not tried this myself, but I would use editcap to convert one
> of the files to the format of the other
Editcap doesn't support that - we don't have any tools that will convert
link-layer headers from one type to another.
------------------------------
Message: 3
Date: Wed, 22 Feb 2006 10:45:41 -0800
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cooked capture files?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Guy Harris wrote:
> Maynard, Chris wrote:
...
>> If not, then what
>> would it take to be able to support this type of merge?
>
> Add support for pcap-NG format:
....or write a tool that converts Linux cooked capture headers to
Ethernet headers (adding fake source or destination addresses), and run
that tool on the Linux cooked capture, and then merge the two Ethernet
capture files.
------------------------------
Message: 4
Date: Wed, 22 Feb 2006 13:53:30 -0500
Subject: RE: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cookedcapture files?
Message-ID:
Content-Type: text/plain; charset="us-ascii"
I suppose it depends on the amount of interest. If I am the only one
who will benefit, then I'll probably just convert the cooked capture to
Ethernet as Guy suggests below, since this is likely to be much easier
to do, but if this is something that many others could benefit from as
well, then I will look into the pcap-NG option. Is my problem a rather
unique or are there other folks who would desire this functionality as
well?
-----Original Message-----
Sent: Wednesday, February 22, 2006 1:46 PM
To: Ethereal development
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cookedcapture files?
Guy Harris wrote:
> Maynard, Chris wrote:
...
>> If not, then what
>> would it take to be able to support this type of merge?
>
> Add support for pcap-NG format:
.....or write a tool that converts Linux cooked capture headers to
Ethernet headers (adding fake source or destination addresses), and run
that tool on the Linux cooked capture, and then merge the two Ethernet
capture files.
-----------------------------------------
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.
------------------------------
Message: 5
Date: Wed, 22 Feb 2006 11:04:23 -0800
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cooked capture files?
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
Rather then reinventing the wheel, use tcpreplay/tcprewrite. It's not
really obvious, but there are a few ways of doing it (i'll just
explain how in tcpreplay 2.x). First you have to understand that
LINUX_SSL doesn't have enough info in it to auto-magically fill out an
802.3 header. Hence you'll need to provide some info. Either:
1) If a static ethernet header is good enough for your LINUX_SLL file,
use -2 to just replace it with your own.
2) If you need different src/dst MAC addresses then you'll have to
specify them with -I and -k and possibly -J and -K too (for -J and -K
you'll need to split your traffic into primary/secondary streams).
-Aaron
--
Aaron Turner
> Guy Harris wrote:
> > Maynard, Chris wrote:
>
> ...
>
> >> If not, then what
> >> would it take to be able to support this type of merge?
> >
> > Add support for pcap-NG format:
>
> ...or write a tool that converts Linux cooked capture headers to
> Ethernet headers (adding fake source or destination addresses), and run
> that tool on the Linux cooked capture, and then merge the two Ethernet
> capture files.
>
------------------------------
Message: 6
Date: Wed, 22 Feb 2006 20:09:49 +0100
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cookedcapture files?
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
Well supporting a (rw) file type that allows for several different
encapsulations to coexists in the same capture file would be great.
But, is the pcap-NG spec already usable?
ie. are we already at the point where future changes in the format
won't broke backwards compatibility?
> I suppose it depends on the amount of interest. If I am the only one
> who will benefit, then I'll probably just convert the cooked capture to
> Ethernet as Guy suggests below, since this is likely to be much easier
> to do, but if this is something that many others could benefit from as
> well, then I will look into the pcap-NG option. Is my problem a rather
> unique or are there other folks who would desire this functionality as
> well?
>
> -----Original Message-----
> Sent: Wednesday, February 22, 2006 1:46 PM
> To: Ethereal development
> Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
> cookedcapture files?
>
> Guy Harris wrote:
> > Maynard, Chris wrote:
>
> ...
>
> >> If not, then what
> >> would it take to be able to support this type of merge?
> >
> > Add support for pcap-NG format:
>
> ....or write a tool that converts Linux cooked capture headers to
> Ethernet headers (adding fake source or destination addresses), and run
> that tool on the Linux cooked capture, and then merge the two Ethernet
> capture files.
>
>
>
> -----------------------------------------
> This email may contain confidential and privileged material for the
> sole use of the intended recipient(s). Any review, use, retention,
> distribution or disclosure by others is strictly prohibited. If you
> are not the intended recipient (or authorized to receive for the
> recipient), please contact the sender by reply email and delete all
> copies of this message. Also, email is susceptible to data
> corruption, interception, tampering, unauthorized amendment and
> viruses. We only send and receive emails on the basis that we are
> not liable for any such corruption, interception, tampering,
> amendment or viruses or any consequence thereof.
>
>
> _______________________________________________
> Ethereal-dev mailing list
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
------------------------------
Message: 7
Date: Wed, 22 Feb 2006 14:18:46 -0500
Subject: RE: [Ethereal-dev] mergecap: How to merge Ethernet &
Linuxcookedcapture files?
Message-ID:
Content-Type: text/plain; charset="us-ascii"
I'll leave the question to Guy and the rest of you experts, but when I
was searching through the mailing list posts, I found a post from Guy
back in July 2001 indicating that Etherpeek, i4btrace for BSD, iptrace
for AIX and the Toshiba TR-600 & TR-650 formats also apparently support
per-packet encapsulations and there seems to be at least some support
for them already. In this case, would pcap-NG still be the preferred
format? Would it be worth looking at any of the others formats first?
Here's Guy's post:
- Chris
-----Original Message-----
Sent: Wednesday, February 22, 2006 2:10 PM
To: Ethereal development
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet &
Linuxcookedcapture files?
Well supporting a (rw) file type that allows for several different
encapsulations to coexists in the same capture file would be great.
But, is the pcap-NG spec already usable?
ie. are we already at the point where future changes in the format
won't broke backwards compatibility?
> I suppose it depends on the amount of interest. If I am the only one
> who will benefit, then I'll probably just convert the cooked capture
to
> Ethernet as Guy suggests below, since this is likely to be much easier
> to do, but if this is something that many others could benefit from as
> well, then I will look into the pcap-NG option. Is my problem a
rather
> unique or are there other folks who would desire this functionality as
> well?
>
> -----Original Message-----
> Sent: Wednesday, February 22, 2006 1:46 PM
> To: Ethereal development
> Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
> cookedcapture files?
>
> Guy Harris wrote:
> > Maynard, Chris wrote:
>
> ...
>
> >> If not, then what
> >> would it take to be able to support this type of merge?
> >
> > Add support for pcap-NG format:
>
> ....or write a tool that converts Linux cooked capture headers to
> Ethernet headers (adding fake source or destination addresses), and
run
> that tool on the Linux cooked capture, and then merge the two Ethernet
> capture files.
>
-----------------------------------------
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.
------------------------------
Message: 8
Date: Wed, 22 Feb 2006 11:25:33 -0800
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cookedcapture files?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
LEGO wrote:
> Well supporting a (rw) file type that allows for several different
> encapsulations to coexists in the same capture file would be great.
>
> But, is the pcap-NG spec already usable?
> ie. are we already at the point where future changes in the format
> won't broke backwards compatibility?
I'm not sure; it's already being used in one product, although it's a
somewhat specialized one (used for an avionics protocol).
That's something probably best asked on the ntar-workers list.
Note that "ntar" is a library for handling the "syntax" of pcap-NG
files; it doesn't handle the semantics of particular record types. Its
developers have suggested that it be used, even in Ethereal, for reading
pcap-NG files; they've added a mechanism to support a "plug-in"
lower-level access library, so we'd plug in support for handling
compressed files, for example.
The library has not, as far as I know, been released yet. That'd be a
bit of an obstacle for using it in Ethereal. :-)
There's also an issue somebody noted, namely that parts of a pcap-NG
file could be big-endian and other parts little-endian, and random
access to the file - which Ethereal requires - would have to be able to
figure out what byte order a particular part is in. A data structure
mapping file offsets to byte orders could probably handle this, as there
probably won't be a *lot* of parts (that would be the result of
concatenating files captured on big-endian hosts and on little-endian
hosts). However, I'm not sure that issue's been resolved yet - which
would be another obstacle.
At this point, just converting the headers of one of the captures to
another format would probably be the simplest and best solution.
------------------------------
Message: 9
Date: Wed, 22 Feb 2006 11:29:45 -0800
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet &
Linuxcookedcapture files?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Maynard, Chris wrote:
> I'll leave the question to Guy and the rest of you experts, but when I
> was searching through the mailing list posts, I found a post from Guy
> back in July 2001 indicating that Etherpeek,
....which doesn't support Linux cooked link-layer headers;
> i4btrace for BSD,
....which doesn't support Linux cooked link-layer headers;
> iptrace for AIX
....which doesn't support Linux cooked link-layer headers;
> and the Toshiba TR-600 & TR-650 formats
....which doesn't support Linux cooked link-layer headers.
> also apparently support per-packet encapsulations
You need more than just support for per-packet encapsulations - you need
support for Linux cooked link-layer headers. Note that we don't control
*any* of those capture file formats, so we can't add support for any
link-layer type of our own choice to them.
------------------------------
Message: 10
Date: Wed, 22 Feb 2006 20:33:19 +0100
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet &
Linuxcookedcapture files?
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
I'll add the Tektronix K1x .rf5 to the list (K12) it can actually
save some sort of multiencapsulation file (But if and only if you are
reading from an rf5 file, it is not able to save if you have opened an
(eg) pcap file).
The plus about pcap-NG is that it would allow to write a file that
could contain different encapsulaton types starting from any other
pcap file then mergecap could mix files with arbitrary encapsulations
(practical example: I work on a machine that uses either MTP2 or
ETHERNET or ATM for signalling).
L.
> I'll leave the question to Guy and the rest of you experts, but when I
> was searching through the mailing list posts, I found a post from Guy
> back in July 2001 indicating that Etherpeek, i4btrace for BSD, iptrace
> for AIX and the Toshiba TR-600 & TR-650 formats also apparently support
> per-packet encapsulations and there seems to be at least some support
> for them already. In this case, would pcap-NG still be the preferred
> format? Would it be worth looking at any of the others formats first?
>
> Here's Guy's post:
>
> - Chris
>
> -----Original Message-----
> Sent: Wednesday, February 22, 2006 2:10 PM
> To: Ethereal development
> Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet &
> Linuxcookedcapture files?
>
> Well supporting a (rw) file type that allows for several different
> encapsulations to coexists in the same capture file would be great.
>
> But, is the pcap-NG spec already usable?
> ie. are we already at the point where future changes in the format
> won't broke backwards compatibility?
>
>
> > I suppose it depends on the amount of interest. If I am the only one
> > who will benefit, then I'll probably just convert the cooked capture
> to
> > Ethernet as Guy suggests below, since this is likely to be much easier
> > to do, but if this is something that many others could benefit from as
> > well, then I will look into the pcap-NG option. Is my problem a
> rather
> > unique or are there other folks who would desire this functionality as
> > well?
> >
> > -----Original Message-----
> > Sent: Wednesday, February 22, 2006 1:46 PM
> > To: Ethereal development
> > Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
> > cookedcapture files?
> >
> > Guy Harris wrote:
> > > Maynard, Chris wrote:
> >
> > ...
> >
> > >> If not, then what
> > >> would it take to be able to support this type of merge?
> > >
> > > Add support for pcap-NG format:
> >
> > ....or write a tool that converts Linux cooked capture headers to
> > Ethernet headers (adding fake source or destination addresses), and
> run
> > that tool on the Linux cooked capture, and then merge the two Ethernet
> > capture files.
> >
>
>
> -----------------------------------------
> This email may contain confidential and privileged material for the
> sole use of the intended recipient(s). Any review, use, retention,
> distribution or disclosure by others is strictly prohibited. If you
> are not the intended recipient (or authorized to receive for the
> recipient), please contact the sender by reply email and delete all
> copies of this message. Also, email is susceptible to data
> corruption, interception, tampering, unauthorized amendment and
> viruses. We only send and receive emails on the basis that we are
> not liable for any such corruption, interception, tampering,
> amendment or viruses or any consequence thereof.
>
>
> _______________________________________________
> Ethereal-dev mailing list
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
------------------------------
Message: 11
Date: Wed, 22 Feb 2006 22:22:47 +0100
Subject: Re: [Ethereal-dev] Lua: where to find V2P.pm
Content-Type: text/plain; charset=us-ascii
On Wed, Feb 22, 2006 at 05:56:09PM +0100, LEGO wrote:
> If you want it, I checked it in a while ago in trunk/tools/tpg as I
> used it for the parser.
Ahh, and I ignored all the google hits pointing to Ethereal ;-)
I just created a softlink and now it works.
Thanks!
Joerg
--
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
------------------------------
Message: 12
Date: Wed, 22 Feb 2006 16:29:53 -0500
Subject: RE: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cookedcapture files?
Message-ID:
Content-Type: text/plain; charset="us-ascii"
FYI: I decided to give this option a try. I had to download & install
some things - libnet, tcpreplay, etc. before running it, but when I did,
it produced a file with the Ethernet header on it, but unfortunately it
doesn't use Ethertype 0800 (for IP), but rather it sets the Ethertype to
0400, which is unknown and therefore nothing else gets dissected
properly when loaded into Ethereal. In case I didn't run tcpreplay with
the correct options, here's the command I used to produce the file:
tcpreplay -i eth0 -R -w cooked2eth.cap -2 00,00,00,00,00,00
cooked.cap
I'm running on Fedora Core 4, 2.6.11-1.1369_FC4, and "tcpreplay -V"
reveals:
tcpreplay version: 2.3.5
Cache file supported: 04
Compiled against libnet: 1.1.2.1
Compiled against libpcap: 0.8.3
Not compiled against libpcapnav.
Using tcpdump located in: /usr/sbin/tcpdump
and "tcpdump -V" reveals:
tcpdump version 3.8
libpcap version 0.8.3
Have I missed something?
- Chris
-----Original Message-----
Sent: Wednesday, February 22, 2006 2:04 PM
To: Ethereal development
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cookedcapture files?
Rather then reinventing the wheel, use tcpreplay/tcprewrite. It's not
really obvious, but there are a few ways of doing it (i'll just
explain how in tcpreplay 2.x). First you have to understand that
LINUX_SSL doesn't have enough info in it to auto-magically fill out an
802.3 header. Hence you'll need to provide some info. Either:
1) If a static ethernet header is good enough for your LINUX_SLL file,
use -2 to just replace it with your own.
2) If you need different src/dst MAC addresses then you'll have to
specify them with -I and -k and possibly -J and -K too (for -J and -K
you'll need to split your traffic into primary/secondary streams).
-Aaron
--
Aaron Turner
> Guy Harris wrote:
> > Maynard, Chris wrote:
>
> ...
>
> >> If not, then what
> >> would it take to be able to support this type of merge?
> >
> > Add support for pcap-NG format:
>
> ...or write a tool that converts Linux cooked capture headers to
> Ethernet headers (adding fake source or destination addresses), and
run
> that tool on the Linux cooked capture, and then merge the two Ethernet
> capture files.
>
-----------------------------------------
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.
------------------------------
Message: 13
Date: Wed, 22 Feb 2006 22:47:13 +0100
Subject: Re: [Ethereal-dev] Lua: where to find V2P.pm
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
> On Wed, Feb 22, 2006 at 05:56:09PM +0100, LEGO wrote:
> > If you want it, I checked it in a while ago in trunk/tools/tpg as I
> > used it for the parser.
>
> Ahh, and I ignored all the google hits pointing to Ethereal ;-)
> I just created a softlink and now it works.
BTW you could just have commented out the "use V2P;" line it's not
used any more... I used it to print out the hash of hashes of arrays
and arrays of hashes arround which elua_makedoc.pl works.
Just for the mention, I wrote the toy (V2P) some years ago while
trying to mesh up a complex network so that it would be resilient to
more than one failure at once. Oddly enough turned out not to be
really useful as circular references would make it to smash the stack.
use V2P;
$r = { a=> [1,2,3,4], b=> {1=>[4,5,6], 2=> {a=>1,b=>2}}};
print var2perl($r)
yields valid perl code to restate the same variable
{
'a' =>[
1,
2,
3,
4
],
'b' =>{
1 =>[
4,
5,
6
],
2 =>{
'a' =>1,
'b' =>2
}
}
}
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
------------------------------
Message: 14
Date: Wed, 22 Feb 2006 13:51:22 -0800
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet & Linux
cookedcapture files?
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
> FYI: I decided to give this option a try. I had to download & install
> some things - libnet, tcpreplay, etc. before running it, but when I did,
> it produced a file with the Ethernet header on it, but unfortunately it
> doesn't use Ethertype 0800 (for IP), but rather it sets the Ethertype to
> 0400, which is unknown and therefore nothing else gets dissected
> properly when loaded into Ethereal. In case I didn't run tcpreplay with
> the correct options, here's the command I used to produce the file:
> tcpreplay -i eth0 -R -w cooked2eth.cap -2 00,00,00,00,00,00
> cooked.cap
[snip]
Using -2 specifies the *entire* layer two header (all 14 bytes for
ethernet). You've only specified the first 6 bytes, so the IP header
is starting at byte offset 7.
--
Aaron Turner
------------------------------
Message: 15
Date: Wed, 22 Feb 2006 17:01:31 -0500
Subject: RE: [Ethereal-dev] mergecap: How to merge Ethernet &
Linuxcookedcapture files?
Message-ID:
Content-Type: text/plain; charset="us-ascii"
Thanks. Yes, I realized that just after I hit "send" :(
Anyway, if I use the following, it works great:
tcpreplay -i eth0 -R -w cooked2eth.cap
-2 00,00,00,00,00,00, 00,00,00,00,00,00,08,00 cooked.cap
Thanks for the suggestion!
- Chris
-----Original Message-----
Sent: Wednesday, February 22, 2006 4:51 PM
To: Ethereal development
Subject: Re: [Ethereal-dev] mergecap: How to merge Ethernet &
Linuxcookedcapture files?
> FYI: I decided to give this option a try. I had to download & install
> some things - libnet, tcpreplay, etc. before running it, but when I
did,
> it produced a file with the Ethernet header on it, but unfortunately
it
> doesn't use Ethertype 0800 (for IP), but rather it sets the Ethertype
to
> 0400, which is unknown and therefore nothing else gets dissected
> properly when loaded into Ethereal. In case I didn't run tcpreplay
with
> the correct options, here's the command I used to produce the file:
> tcpreplay -i eth0 -R -w cooked2eth.cap -2 00,00,00,00,00,00
> cooked.cap
[snip]
Using -2 specifies the *entire* layer two header (all 14 bytes for
ethernet). You've only specified the first 6 bytes, so the IP header
is starting at byte offset 7.
--
Aaron Turner
_______________________________________________
Ethereal-dev mailing list
-----------------------------------------
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.
------------------------------
Message: 16
Date: Wed, 22 Feb 2006 09:02:41 +0100 (MET)
Subject: [Ethereal-dev] Re: Re: Using USER DLT for RNSAP (over SCCP)
Content-Type: text/plain; charset="us-ascii"
Hi
> RNSAP does not yet register to SCCP.
> The sample you sent unfortunatelly does not have the CR/CC pair in
> which conveys information regarding the user. So that would not be
> decoded even if RNSAP registered to SCCP. I don't know whether there
> is a good way to (heuristically) identify RNSAP.
How do you identify RANAP today?
Why can I not force Ethereal to decode RNSAP _unconditionally_ on top of
SCCP (I thought this is the purpose of these USER DLT, but how?)
I see 3 possibilities:
Solution 1
Both RANAP and RNSAP subscribe to SCCP. The user shall have the chance to
decide which of the two is chosen on top of SCCP. This then would decode the
correctly chosen frames error free and the wrongly chosen frames (most
likely) with errors. This works fine for every frame (also if no CR/CC is
present).
Solution 2
Both RANAP and RNSAP subscribe to SCCP. The decision whether to load the one
or the other shall be based on the SSN from the CR message and all
subsequent CC, DT1, RLSD, RLC within the same <SLR,DLR> shall be treated
alike.
The problem just remains: What if the SSN is the same (for both RANAP and
RNSAP). Is that possible? I think so. But then we still have solution 1.
Solution 3
Make a protocol discriminator based on the <opc,dpc> from the SCCP Routing
Label, but this might be a configuration nightmare. This is by the way
exactly what the Network Elements are doing (i.e. the MGW)
In my attachment there is 1 IuCS transaction and 1 Iur transaction.
For IuCS RANAP is used when SSN=142 (frame 1)
For Iur RNSAP is used when SSN=143 (frame 12)
If you are interested in Solution 3:
PCs starting with 3 are RNCs,
2107 is the MGC
Any finally: The RNSAP messages are segmented over several DT1 frames
(frames 16,17,18,19)
/Roger
--
DSL-Aktion wegen gro_er Nachfrage bis 28.2.2006 verldngert:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1xIuCS_1xIur.cap
Type: application/octet-stream
Size: 2900 bytes
Desc: not available
Url : /pipermail/attachments/20060222/31a74609/1xIuCS_1xIur.obj
------------------------------
Message: 17
Date: Wed, 22 Feb 2006 22:59:28 -0000
Subject: [Ethereal-dev] Fallen at the first hurdle :(
Content-Type: text/plain; charset="us-ascii"
Hi all .
I'm sorry if this question seems silly or is posted 4000 a day but ..
I read the dev guide and inferred that under Win32 using nmake (with VC6), I
could (without installing any other tools) invoke:
nmake -f makefile.nmake distclean
What happens is
rm -f gtk2.tmp/*.*
'rm' is not recognized as an internal or external command, operable program
or batch file.
NMAKE : fatal error U1077: 'rm' : return code '0x1'
Stop.
rm sounds very unix to me . as does the "/"
I do like a challenge but didn't expect to fail so soon.
Is there a different makefile for Windows?
Any hints will be gratefully received.
TIA
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060222/38a98f8d/attachment.html
------------------------------
Message: 18
Date: Thu, 23 Feb 2006 00:07:53 +0100
Subject: Re: [Ethereal-dev] Re: Re: Using USER DLT for RNSAP (over
SCCP)
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
> > RNSAP does not yet register to SCCP.
> How do you identify RANAP today?
Either because it uses a well known SSN (0x8e) or heuristically by
means of the lenght being right and the opcode (the heuristics fail
sometimes to get ranap packets and sometimes they might interpret as
ranap things that aren't realy ranap, that's heuristic isn't it :-).
> Why can I not force Ethereal to decode RNSAP _unconditionally_ on top of
> SCCP (I thought this is the purpose of these USER DLT, but how?)
Because sccp does not know (yet) even that RNSAP exists . In order to
do so the RNSAP dissector has to register to use an SCCP SSN (don't
worry I'll add it soon).
Even at that point not everything is solved, A problem is that the SSN
appears only in the setup packets of the SCCP "call" so unless your
capture contains these two messages SCCP will try to guess If the
payload is unknown. Theres no heuristics for RNSAP (I don't even know
if some reliable method to guess RNSAP exists, so it's not possible
for me to write it).
User DLT was born with no purpose other than helping me write the K12
rf5 file import. Even if the k12 code did not needed it once finished,
It turned out handy, so I packet it and left it there.
What it does is it takes a USER_DLT (unassigned PCAP encasulation
type) and maps it to an arbitrary protocol optionaly removing some
bytes before and some after. If you have a file that uses one of this
encapsulation types (usually a node's log passed through text2pcap) it
allows you to decode the payloadof the frames.
>
> I see 3 possibilities:
>
> Solution 1
> Both RANAP and RNSAP subscribe to SCCP. The user shall have the chance to
> decide which of the two is chosen on top of SCCP. This then would decode the
> correctly chosen frames error free and the wrongly chosen frames (most
> likely) with errors. This works fine for every frame (also if no CR/CC is
> present).
Very Ugly.
> Solution 2
> Both RANAP and RNSAP subscribe to SCCP. The decision whether to load the one
> or the other shall be based on the SSN from the CR message and all
> subsequent CC, DT1, RLSD, RLC within the same <SLR,DLR> shall be treated
> alike.
This one is neat and feasable.
> The problem just remains: What if the SSN is the same (for both RANAP and
> RNSAP). Is that possible? I think so. But then we still have solution 1.
While over a certain association (DPC-OPC) there should be no more
than one SSN per application. There could be someone tat uses the same
ssn for different applications,
However good practice is to use different SSNs for different
Applications even over different associations.
If you find something like that in the field make sure the System
Engineer is transfered to marketing before he causes more damage!!!
:-)
Solution 1 is ugly!
A Protocol preference in RNSAP for telling which SSN to use is a must!
So we go with 2.
As per the heuristics do you have an Idea on how we can guess if
something is RNSAP and not something else?
> Solution 3
> Make a protocol discriminator based on the <opc,dpc> from the SCCP Routing
> Label, but this might be a configuration nightmare. This is by the way
> exactly what the Network Elements are doing (i.e. the MGW)
I think the MGW is at most an STP for RNSAP messages, AFAIK in most
cases the IuR is cross-connected via ATM and as such completely
transparent to the MGw which works only as an ATM switch.
> In my attachment there is 1 IuCS transaction and 1 Iur transaction.
> For IuCS RANAP is used when SSN=142 (frame 1)
> For Iur RNSAP is used when SSN=143 (frame 12)
> If you are interested in Solution 3:
> PCs starting with 3 are RNCs,
> 2107 is the MGC
MGC in regard of the MGw only, MSC for the RNCs I guess.
>
> Any finally: The RNSAP messages are segmented over several DT1 frames
> (frames 16,17,18,19)
Thanks I'll take a look at this.
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
------------------------------
Message: 19
Date: Thu, 23 Feb 2006 00:17:17 +0100
Subject: Re: [Ethereal-dev] Fallen at the first hurdle :(
Content-Type: text/plain; charset=windows-1252; format=flowed
Dave Ramsey wrote:
>
> Hi all
>
> Im sorry if this question seems silly or is posted 4000 a day but .
>
> I read the dev guide
>
You should read the tools section thoroughly, you'll need cygwin.
Regards, ULFL
------------------------------
Message: 20
Date: Wed, 22 Feb 2006 17:58:24 -0600
Subject: Re: [Ethereal-dev] IPsec dissector to decrypt ESP Payload
Content-Type: text/plain; charset=ISO-8859-1
Would it be possible to link against GNU TLS instead? We can't ship
Ethereal linked against OpenSSL on many (most?) systems.
Frederic Roudaut wrote:
>
>
>
> Hi all,
>
>
> Because I received no comment about my dissector, I ask again ;-).
> Is there any need for my update ? Does anyone plan to use it ?
>
> Best regards
>
> ----
> Frederic
>
>
>
>
>
>
>
>
> Frederic roudaut a icrit :
>
>>
>>
>>
>> Hi everyone,
>>
>> I adapted the IPSEC dissector in order to decrypt ESP payload based on
>> known SAs.It uses the few algorithms described in RFC 4305.
>> It also uses libopenssl.
>>
>> If you prefer a patch please ask me. Otherwise, the file is the
>> following :
>> - packet-ipsec.c
>>
>> (It is still possible to decrypt ESP payloads with the assumption that
>> it is null encrypted and the Authenticator field is 12 bytes as in the
>> original dissector).
>>
>> I wrote a little doc in :
>> - README_DISSECTOR_IPSEC (have a look to install the dissector)
>>
>> And I put exemple files :
>>
>> - A capture file : capture.pcap
>>
>> - Some preferences files with the configurations for v4 and V6
>> - preferences_v4
>> - preferences_v6
>>
>> - The sad has been run using : ipsec.conf (config file for setkey)
>> I have not tested it for AES-CTR. So if you can, please send me a
>> report on it.
>>
>> - If you want to get another capture file. You may use both following
>> scripts on Linux:
>> - neigh.sh : for establishing neighborhood
>> - ping_v6_v4.sh : in order to send ping v4 and v6
>>
>>
>> I hope it will be helpfull for some of you.
>>
>>
>> Best regards,
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Ethereal-dev mailing list
------------------------------
Message: 21
Date: Thu, 23 Feb 2006 00:06:36 -0000
Subject: RE: [Ethereal-dev] Fallen at the first hurdle :(
Content-Type: text/plain; charset="us-ascii"
Dave Ramsey wrote:
>> I read the dev guide
>>
> You should read the tools section thoroughly, you'll need cygwin.
Ulf,
Many thanks for that ... I can certainly get past the first hurdle now
I have re-read the tools section very carefully, and Cygwin is only
mentioned as an alternative to Native Win32 ... I can't see where Cygwin is
specified as a mandatory tool to build under Native Win32 environment,
although it IS late and I'm tired :)
I will install the rest of the Native Win32 tools now and hopefully have no
further problems :)
Again thanks for your help
Regards
Dave
------------------------------
Message: 22
Date: Wed, 22 Feb 2006 18:17:45 -0600
Subject: [Ethereal-dev] buildbot failure in Fedora-Core-4-IA32
The Buildbot has detected a new failure of Fedora-Core-4-IA32.
Build Reason: changes
Build Source Stamp: 1992
Blamelist: lego
BUILD FAILED: failed rpm
sincerely,
-The Buildbot
------------------------------
Message: 23
Date: Thu, 23 Feb 2006 01:22:32 +0100
Subject: Re: [Ethereal-dev] buildbot failure in Fedora-Core-4-IA32
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
a missing file already checked in.
> The Buildbot has detected a new failure of Fedora-Core-4-IA32.
>
>
> Build Reason: changes
> Build Source Stamp: 1992
> Blamelist: lego
>
> BUILD FAILED: failed rpm
>
> sincerely,
> -The Buildbot
>
> _______________________________________________
> Ethereal-dev mailing list
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
------------------------------
Message: 24
Date: Wed, 22 Feb 2006 16:32:58 -0800 (PST)
Subject: RE: [Ethereal-dev] Fallen at the first hurdle :(
Content-Type: text/plain;charset=iso-8859-1
Dave Ramsey wrote:
> I have re-read the tools section very carefully, and Cygwin is only
> mentioned as an alternative to Native Win32 ... I can't see where Cygwin
> is
> specified as a mandatory tool to build under Native Win32 environment,
> although it IS late and I'm tired :)
The Win32: Recommended Tools section of the Developer's Guide needs to be
changed to say that you need Cygwin *even for Win32 native builds*, as
bash is required and you only get it with Cygwin.
(It also needs to be changed not to imply that you need bash on UN*X - any
Bourne-compatible shell will do, and *all* UN*Xes have at least one of
them.)
------------------------------
_______________________________________________
Ethereal-dev mailing list
End of Ethereal-dev Digest, Vol 34, Issue 35
******************************************** | 
