From: Denis Ovsienko
> >Eventually, we'll be using this format to debug multi-path TCP, in which case
> >the IP addresses (and maybe even the IP4/IP6-ness of it) might change.
>
> Also there exists SCTP, which implements the concept of variable (0..65535)
> number of "streams" for each direction o
> I'd prefer to also have a flag to say if this segment was received or
> transmitted - I've never liked inferring that information from the
> identity of the source/dest. addresses. It then makes it impossible to
> sensibly analyse the file if you don't know the underlying networking
> configurati
On Wed, 14 Jan 2015 14:21:18 -0800
Guy Harris wrote:
> OK, so the transport-layer metadata values we should include are:
>
> UDP: source and destination port numbers
>
> TCP: source and destination port numbers, EOF indication
> (think of it as FIN), urgent pointer?
>
> SCTP:
On Jan 14, 2015, at 12:10 PM, Michael Tuexen
wrote:
>> On 14 Jan 2015, at 18:19, Denis Ovsienko wrote:
>>
>>> Eventually, we'll be using this format to debug multi-path TCP, in which
>>> case
>>> the IP addresses (and maybe even the IP4/IP6-ness of it) might change.
>>
>> Also there exist
> On 14 Jan 2015, at 18:19, Denis Ovsienko wrote:
>
>> Eventually, we'll be using this format to debug multi-path TCP, in which
>> case
>> the IP addresses (and maybe even the IP4/IP6-ness of it) might change.
>
> Also there exists SCTP, which implements the concept of variable (0..65535)
>
>Eventually, we'll be using this format to debug multi-path TCP, in which case
>the IP addresses (and maybe even the IP4/IP6-ness of it) might change.
Also there exists SCTP, which implements the concept of variable (0..65535)
number of "streams" for each direction of an "association" between a
On Wed, 14 Jan 2015 11:57:53 -0500
Michael Richardson wrote:
> > It does momentarily seem wasteful to repeat the
> > source/destination information in every single packet
> > (especially in the case of IPv6 with its 256bits of addressing
> > information). Though I don't know if th
On Wed, 14 Jan 2015 11:57:53 -0500
Michael Richardson wrote:
> > It does momentarily seem wasteful to repeat the
> > source/destination information in every single packet
> > (especially in the case of IPv6 with its 256bits of addressing
> > information). Though I don't know if th
"Paul \"LeoNerd\" Evans" wrote:
> I wonder though, whether the flags could be combined with the IP
> version field, given as the version in the underlying (real) IP packet
> anyway is only a 4-bit field.
> 1 byte | Flags and IP version:
> bit7 [ ...W ] bit0
> VV
On Tue, 13 Jan 2015 19:32:46 -0800
Guy Harris wrote:
> LINKTYPE_IP_PAYLOAD, or something such as that, with a link-layer
> (pseudo-)header containing:
I'm happy with that as a name.
> an indication of whether the network-layer addresses are IPv4
> or IPv6;
>
> source address;
>
>
On Jan 13, 2015, at 6:05 PM, "Paul \"LeoNerd\" Evans"
wrote:
> I want an HTTP(S) client to write a dump file of the cleartext it is
> sending/receiving, so I can analyse it later. I'm feeling like maybe a
> pcap or pcapng file is good for that, so wireshark et.al. can be
> applied. Ideally it w
I want an HTTP(S) client to write a dump file of the cleartext it is
sending/receiving, so I can analyse it later. I'm feeling like maybe a
pcap or pcapng file is good for that, so wireshark et.al. can be
applied. Ideally it would include timing information, TCP port numbers
and IP addresses also.
12 matches
Mail list logo
