subject:"\[Wireshark\-dev\] q on catching error in sub\-dissectors."

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-23 Thread João Valverde

On 22/01/20 17:04, Christian Hopps wrote:

On Jan 22, 2020, at 11:21 AM, João Valverde
wrote:

On 22/01/20 01:11, Christian Hopps wrote:

João Valverde writes:

On 21/01/20 16:06, João Valverde wrote:

On 21/01/20 16:01, Jeff Morriss wrote:

We've been having fun with multiple PDUs in a single IP frame with
SCTP for years. While there's room for improvement it's worked
pretty well.

Maybe I didn't explain well, but that's completely different to
multiple IP packets encapsulated in a single frame. L4 multiplexing is
nothing new, I agree.

How would this protocol stack even look in the packet list? Surely it
can only display the outer IP header with ESP/IPTFS protocol? We already
have some issues to iron out with the much simpler case of IP over GRE
(bug 3791 for example).

One idea, and it's just that, I haven't studied the issue in depth,
would be using an IPTFS Cooked Capture DLT type.

I'm not versed well enough in wireshark yet to know what a "cooked capture DLT
type" is, but I can show what I have now. :)

I still haven't stamped anything with "comes from" or "depends on", and I'd
also like to have datablock summary lines include the actual size of that datablock data...

Basically I decode as:

- IPTFS
- Header fields
- Array of datablocks
- Subtree of contained packets:
- Array of Dissected IP packets
- 1st packet is the completion of a fragmented packet if that happened.

You'll notice the final datablock doesn't have a packet (7 data blocks 6
packets), the first packet is the reconstructed packet from the first datablock
which is the last of the fragments. The last datablock is the start of a new
fragmented packet so that will appear later (the inner packet sizes are from an
imix stream of 40, 576 and 1500 FWIW)

[snip]

That's pretty good, nice work.

What does tshark without the -V flag show? My guess is that all that compresses
to:

8 13.13.13.11 13.13.13.2 IPTFS

You guess correctly. :)

It would be nice to see each encapsulated IP flow (after reassembly if
necessary) in this list. Both from a usability stand point and also because it
enables a lot of other stuff, like better filtering, follow stream, etc.

A cooked capture, in particular a Linux cooked capture, is a link-layer pseudo-header for the
"any" interface. It doesn't correspond to any real protocol like ETH or PPP. The same
concept could possibly be applied here to display each inner IP packet in the packet list. For
IPTFS a frame "interface" could be the IPTFS ESP SPI. Usually dumpcap/libpcap provides
the DLT type. Major caveat, I don't know how difficult it would be to inject new cooked frames from
libwireshark itself.

That sounds really good.

Security Associations (SAs which the SPI identifies) are actually
uni-directional (although they almost *always* come in pairs inbound,
outbound), so we probably would want the psuedo-header to be based on the
tuple: (ip-src, ip-dst, spi), as one might have 2 unique SAs with the same SPI.

FWIW, I think the same psuedo-header should probably be used by non-IPTFS IPsec
code too (it also dissects the single inner packet it carries -- when operating
in tunnel mode -- when in transport mode it will be dissecting L4 data, but
this just means the conceptual inner IP header is the same as the outer, so
same ip-src, ip-dst tuple applies).

IPsec in tunnel mode is not so different from OpenVPN or even GRE from a
conceptual point of view. That's a pretty major redesign that requires
careful consideration and because the encapsulation is one-to-one and
not one-to-many like IPTFS it doesn't have most of the limitations that
IPTFS would have. Things work well most of the time in that case so
finding momentum to implement a link-layer encapsulation pseudo-header
so broadly might be difficult.

Thanks,
Chris.

___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-22 Thread Christian Hopps



> On Jan 22, 2020, at 11:21 AM, João Valverde 
>  wrote:
> 
> 
> 
> On 22/01/20 01:11, Christian Hopps wrote:
>> 
>> João Valverde  writes:
>> 
>>> On 21/01/20 16:06, João Valverde wrote:
 
 
 On 21/01/20 16:01, Jeff Morriss wrote:
> We've been having fun with multiple PDUs in a single IP frame with
> SCTP for years.  While there's room for improvement it's worked
> pretty well.
 
 Maybe I didn't explain well, but that's completely different to
 multiple IP packets encapsulated in a single frame. L4 multiplexing is
 nothing new, I agree.
 
 
>>> 
>>> How would this protocol stack even look in the packet list? Surely it
>>> can only display the outer IP header with ESP/IPTFS protocol? We already
>>> have some issues to iron out with the much simpler case of IP over GRE
>>> (bug 3791 for example).
>>> 
>>> One idea, and it's just that, I haven't studied the issue in depth,
>>> would be using an IPTFS Cooked Capture DLT type.
>> 
>> I'm not versed well enough in wireshark yet to know what a "cooked capture 
>> DLT type" is, but I can show what I have now. :)
>> 
>> I still haven't stamped anything with "comes from" or "depends on", and I'd 
>> also like to have datablock summary lines include the actual size of that 
>> datablock data...
>> 
>> Basically I decode as:
>> 
>> - IPTFS
>>  - Header fields
>>  - Array of datablocks
>>  - Subtree of contained packets:
>>- Array of Dissected IP packets
>>  - 1st packet is the completion of a fragmented packet if that happened.
>> 
>> You'll notice the final datablock doesn't have a packet (7 data blocks 6 
>> packets), the first packet is the reconstructed packet from the first 
>> datablock which is the last of the fragments. The last datablock is the 
>> start of a new fragmented packet so that will appear later (the inner packet 
>> sizes are from an imix stream of 40, 576 and 1500 FWIW)
>> 
> 
> [snip]
> 
> That's pretty good, nice work.
> 
> What does tshark without the -V flag show? My guess is that all that 
> compresses to:
> 
> 8   13.13.13.11   13.13.13.2  IPTFS   SPI=1113 Blocks=7>

You guess correctly. :)

> It would be nice to see each encapsulated IP flow (after reassembly if 
> necessary) in this list. Both from a usability stand point and also because 
> it enables a lot of other stuff, like better filtering, follow stream, etc.
> 
> A cooked capture, in particular a Linux cooked capture, is a link-layer 
> pseudo-header for the "any" interface. It doesn't correspond to any real 
> protocol like ETH or PPP. The same concept could possibly be applied here to 
> display each inner IP packet in the packet list. For IPTFS a frame 
> "interface" could be the IPTFS ESP SPI. Usually dumpcap/libpcap provides the 
> DLT type. Major caveat, I don't know how difficult it would be to inject new 
> cooked frames from libwireshark itself.

That sounds really good.

Security Associations (SAs which the SPI identifies) are actually 
uni-directional (although they almost *always* come in pairs inbound, 
outbound), so we probably would want the psuedo-header to be based on the 
tuple: (ip-src, ip-dst, spi), as one might have 2 unique SAs with the same SPI. 

FWIW, I think the same psuedo-header should probably be used by non-IPTFS IPsec 
code too (it also dissects the single inner packet it carries -- when operating 
in tunnel mode -- when in transport mode it will be dissecting L4 data, but 
this just means the conceptual inner IP header is the same as the outer, so 
same ip-src, ip-dst tuple applies).

Thanks,
Chris.

> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-22 Thread João Valverde




On 22/01/20 01:11, Christian Hopps wrote:


João Valverde  writes:


On 21/01/20 16:06, João Valverde wrote:



On 21/01/20 16:01, Jeff Morriss wrote:

We've been having fun with multiple PDUs in a single IP frame with
SCTP for years.  While there's room for improvement it's worked
pretty well.


Maybe I didn't explain well, but that's completely different to
multiple IP packets encapsulated in a single frame. L4 multiplexing is
nothing new, I agree.




How would this protocol stack even look in the packet list? Surely it
can only display the outer IP header with ESP/IPTFS protocol? We already
have some issues to iron out with the much simpler case of IP over GRE
(bug 3791 for example).

One idea, and it's just that, I haven't studied the issue in depth,
would be using an IPTFS Cooked Capture DLT type.


I'm not versed well enough in wireshark yet to know what a "cooked 
capture DLT type" is, but I can show what I have now. :)


I still haven't stamped anything with "comes from" or "depends on", 
and I'd also like to have datablock summary lines include the actual 
size of that datablock data...


Basically I decode as:

- IPTFS
 - Header fields
 - Array of datablocks
 - Subtree of contained packets:
   - Array of Dissected IP packets
 - 1st packet is the completion of a fragmented packet if that 
happened.


You'll notice the final datablock doesn't have a packet (7 data blocks 
6 packets), the first packet is the reconstructed packet from the 
first datablock which is the last of the fragments. The last datablock 
is the start of a new fragmented packet so that will appear later (the 
inner packet sizes are from an imix stream of 40, 576 and 1500 FWIW)




[snip]

That's pretty good, nice work.

What does tshark without the -V flag show? My guess is that all that 
compresses to:


8   13.13.13.11   13.13.13.2  IPTFS      SPI=1113 Blocks=7>


It would be nice to see each encapsulated IP flow (after reassembly if 
necessary) in this list. Both from a usability stand point and also 
because it enables a lot of other stuff, like better filtering, follow 
stream, etc.


A cooked capture, in particular a Linux cooked capture, is a link-layer 
pseudo-header for the "any" interface. It doesn't correspond to any real 
protocol like ETH or PPP. The same concept could possibly be applied 
here to display each inner IP packet in the packet list. For IPTFS a 
frame "interface" could be the IPTFS ESP SPI. Usually dumpcap/libpcap 
provides the DLT type. Major caveat, I don't know how difficult it would 
be to inject new cooked frames from libwireshark itself.


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-21 Thread Christian Hopps



João Valverde  writes:


On 21/01/20 16:06, João Valverde wrote:



On 21/01/20 16:01, Jeff Morriss wrote:

We've been having fun with multiple PDUs in a single IP frame with
SCTP for years.  While there's room for improvement it's worked
pretty well.


Maybe I didn't explain well, but that's completely different to
multiple IP packets encapsulated in a single frame. L4 multiplexing is
nothing new, I agree.




How would this protocol stack even look in the packet list? Surely it
can only display the outer IP header with ESP/IPTFS protocol? We already
have some issues to iron out with the much simpler case of IP over GRE
(bug 3791 for example).

One idea, and it's just that, I haven't studied the issue in depth,
would be using an IPTFS Cooked Capture DLT type.


I'm not versed well enough in wireshark yet to know what a "cooked capture DLT 
type" is, but I can show what I have now. :)

I still haven't stamped anything with "comes from" or "depends on", and I'd 
also like to have datablock summary lines include the actual size of that datablock data...

Basically I decode as:

- IPTFS
 - Header fields
 - Array of datablocks
 - Subtree of contained packets:
   - Array of Dissected IP packets
 - 1st packet is the completion of a fragmented packet if that happened.

You'll notice the final datablock doesn't have a packet (7 data blocks 6 
packets), the first packet is the reconstructed packet from the first datablock 
which is the last of the fragments. The last datablock is the start of a new 
fragmented packet so that will appear later (the inner packet sizes are from an 
imix stream of 40, 576 and 1500 FWIW)

Here's the tshark output:

   Frame 8: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
on interface 0
   [...]
   Ethernet II, Src: IntelCor_3c:08:29 (f8:f2:1e:3c:08:29), Dst: 
IntelCor_3c:09:b1 (f8:f2:1e:3c:09:b1)
   [...]
   Internet Protocol Version 4, Src: 13.13.13.11, Dst: 13.13.13.12
   [...]
   Source: 13.13.13.11
   Destination: 13.13.13.12
   Encapsulating Security Payload
   ESP SPI: 0x0458 (1112)
   ESP Sequence: 8979
   ESP Pad Length: 0
   Next header: Unassigned (0x8f)
   NULL Authentication
   [Good: True]
   [Bad: False]
   IP Traffic Flow Security
   Flags: 0x, V: Not set, CC: Not set
   0...    = V: Not set
   .0..    = CC: Not set
   Block Offset: 0x013a
   Data Block: 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 ...
   Data Block: 45 00 00 28 00 01 00 00 3f 11 3b 81 10 00 00 22 ...
   Data Block: 45 00 00 28 00 01 00 00 3f 11 3b 83 10 00 00 21 ...
   Data Block: 45 01 02 40 ff ff 00 00 3f 11 39 ab 10 00 00 01 ...
   Data Block: 45 00 00 28 00 01 00 00 3f 11 3b 7d 10 00 00 24 ...
   Data Block: 45 00 00 28 00 01 00 00 3f 11 3b 7f 10 00 00 23 ...
   Data Block: 45 01 02 40 ff ff 00 00 3f 11 39 ab 10 00 00 01 ...
   Contained Packets
   Internet Protocol Version 4, Src: 16.0.0.42, Dst: 48.0.0.42
   0100  = Version: 4
    0101 = Header Length: 20 bytes (5)
   Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    00.. = Differentiated Services Codepoint: Default (0)
    ..00 = Explicit Congestion Notification: Not 
ECN-Capable Transport (0)
   Total Length: 1500
   Identification: 0x0001 (1)
   Flags: 0x
   0...    = Reserved bit: Not set
   .0..    = Don't fragment: Not set
   ..0.    = More fragments: Not set
   ...0    = Fragment offset: 0
   Time to live: 63
   Protocol: UDP (17)
   Header checksum: 0x35bd [validation disabled]
   [Header checksum status: Unverified]
   Source: 16.0.0.42
   Destination: 48.0.0.42
   User Datagram Protocol, Src Port: 21964, Dst Port: 13226
   Source Port: 21964
   Destination Port: 13226
   Length: 1480
   Checksum: 0xd039 [unverified]
   [Checksum Status: Unverified]
   [Stream index: 19]
   Data (1472 bytes)

     78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78   
   0010  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78   
   0020  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78   
   0030  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78   
   0040  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78   
   0050  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78   
   0060  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78   
   0070  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78   
   0080  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78   
   0

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-21 Thread João Valverde




On 21/01/20 16:06, João Valverde wrote:



On 21/01/20 16:01, Jeff Morriss wrote:
We've been having fun with multiple PDUs in a single IP frame with 
SCTP for years.  While there's room for improvement it's worked 
pretty well.


Maybe I didn't explain well, but that's completely different to 
multiple IP packets encapsulated in a single frame. L4 multiplexing is 
nothing new, I agree.





How would this protocol stack even look in the packet list? Surely it 
can only display the outer IP header with ESP/IPTFS protocol? We already 
have some issues to iron out with the much simpler case of IP over GRE 
(bug 3791 for example).


One idea, and it's just that, I haven't studied the issue in depth, 
would be using an IPTFS Cooked Capture DLT type.




On Tue, Jan 21, 2020 at 9:58 AM João Valverde 
> wrote:


By the way usually a tunnel encapsulates a single packet. I'm not
aware
of any other protocol multiplexing at the IP level. I would assume
Wireshark requires some replumbing to handle that. Something like
TFS
being treated as a framing layer. Just food for thought.

On 21/01/20 14:46, João Valverde wrote:
>
>
> On 21/01/20 14:33, Christian Hopps wrote:
>> So I've got a payload of packets in a single frame. I'm calling
>> dissector_try_uint_new() to dissect each payload (typically IPv4
>> packets). Some of these packets are considered "malformed" by
>> wireshark (e.g., created by scapy/trex with some bogus values).
>>
>> The problem I'm hitting is that the first malformed inner packet
>> fails all the way out of my parent dissector, so it doesn't
dissect
>> any of the other packets in the payload.
>>
>> Another problem I'm having is that the IP sub-dissector is
>> overwriting my source and destination addresses in the pinfo/tree
>> (not sure which doesn't really matter).
>>
>> Summary:
>>
>> - How can I "catch" errors in a subdissector so I can call other
>> sub-dissectors?
>
> Use TRY/CATCH (in epan/exceptions.h).
>
>> - How can I "block" sub-dissectors from overwriting my outer
header
>> information?
>
> I don't think you can. Maybe your IPTFS dissector can set it
after the
> sub-dissectors run.
>
>>
>> Thanks,
>> Chris.
>>
___

>>
>> Sent via:    Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
>> Archives: https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe
>
>
___

>
> Sent via:    Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe

___
Sent via:    Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:https://www.wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-21 Thread João Valverde




On 21/01/20 16:01, Jeff Morriss wrote:
We've been having fun with multiple PDUs in a single IP frame with 
SCTP for years.  While there's room for improvement it's worked pretty 
well.


Maybe I didn't explain well, but that's completely different to multiple 
IP packets encapsulated in a single frame. L4 multiplexing is nothing 
new, I agree.





On Tue, Jan 21, 2020 at 9:58 AM João Valverde 
> wrote:


By the way usually a tunnel encapsulates a single packet. I'm not
aware
of any other protocol multiplexing at the IP level. I would assume
Wireshark requires some replumbing to handle that. Something like TFS
being treated as a framing layer. Just food for thought.

On 21/01/20 14:46, João Valverde wrote:
>
>
> On 21/01/20 14:33, Christian Hopps wrote:
>> So I've got a payload of packets in a single frame. I'm calling
>> dissector_try_uint_new() to dissect each payload (typically IPv4
>> packets). Some of these packets are considered "malformed" by
>> wireshark (e.g., created by scapy/trex with some bogus values).
>>
>> The problem I'm hitting is that the first malformed inner packet
>> fails all the way out of my parent dissector, so it doesn't
dissect
>> any of the other packets in the payload.
>>
>> Another problem I'm having is that the IP sub-dissector is
>> overwriting my source and destination addresses in the pinfo/tree
>> (not sure which doesn't really matter).
>>
>> Summary:
>>
>> - How can I "catch" errors in a subdissector so I can call other
>> sub-dissectors?
>
> Use TRY/CATCH (in epan/exceptions.h).
>
>> - How can I "block" sub-dissectors from overwriting my outer
header
>> information?
>
> I don't think you can. Maybe your IPTFS dissector can set it
after the
> sub-dissectors run.
>
>>
>> Thanks,
>> Chris.
>>
___

>>
>> Sent via:    Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
>> Archives: https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe
>
>
___

>
> Sent via:    Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe

___
Sent via:    Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-21 Thread Jeff Morriss

We've been having fun with multiple PDUs in a single IP frame with SCTP for
years.  While there's room for improvement it's worked pretty well.

On Tue, Jan 21, 2020 at 9:58 AM João Valverde <
joao.valve...@tecnico.ulisboa.pt> wrote:

> By the way usually a tunnel encapsulates a single packet. I'm not aware
> of any other protocol multiplexing at the IP level. I would assume
> Wireshark requires some replumbing to handle that. Something like TFS
> being treated as a framing layer. Just food for thought.
>
> On 21/01/20 14:46, João Valverde wrote:
> >
> >
> > On 21/01/20 14:33, Christian Hopps wrote:
> >> So I've got a payload of packets in a single frame. I'm calling
> >> dissector_try_uint_new() to dissect each payload (typically IPv4
> >> packets). Some of these packets are considered "malformed" by
> >> wireshark (e.g., created by scapy/trex with some bogus values).
> >>
> >> The problem I'm hitting is that the first malformed inner packet
> >> fails all the way out of my parent dissector, so it doesn't dissect
> >> any of the other packets in the payload.
> >>
> >> Another problem I'm having is that the IP sub-dissector is
> >> overwriting my source and destination addresses in the pinfo/tree
> >> (not sure which doesn't really matter).
> >>
> >> Summary:
> >>
> >> - How can I "catch" errors in a subdissector so I can call other
> >> sub-dissectors?
> >
> > Use TRY/CATCH (in epan/exceptions.h).
> >
> >> - How can I "block" sub-dissectors from overwriting my outer header
> >> information?
> >
> > I don't think you can. Maybe your IPTFS dissector can set it after the
> > sub-dissectors run.
> >
> >>
> >> Thanks,
> >> Chris.
> >>
> ___
> >>
> >> Sent via:Wireshark-dev mailing list 
> >> Archives:https://www.wireshark.org/lists/wireshark-dev
> >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> >
> >
> ___
> >
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-21 Thread Christian Hopps



> On Jan 21, 2020, at 9:46 AM, João Valverde  
> wrote:
> 
> 
> 
> On 21/01/20 14:33, Christian Hopps wrote:
>> So I've got a payload of packets in a single frame. I'm calling 
>> dissector_try_uint_new() to dissect each payload (typically IPv4 packets). 
>> Some of these packets are considered "malformed" by wireshark (e.g., created 
>> by scapy/trex with some bogus values).
>> 
>> The problem I'm hitting is that the first malformed inner packet fails all 
>> the way out of my parent dissector, so it doesn't dissect any of the other 
>> packets in the payload.
>> 
>> Another problem I'm having is that the IP sub-dissector is overwriting my 
>> source and destination addresses in the pinfo/tree (not sure which doesn't 
>> really matter).
>> 
>> Summary:
>> 
>> - How can I "catch" errors in a subdissector so I can call other 
>> sub-dissectors?
> 
> Use TRY/CATCH (in epan/exceptions.h).

This worked!

Thanks,
Chris.

> 
>> - How can I "block" sub-dissectors from overwriting my outer header 
>> information?
> 
> I don't think you can. Maybe your IPTFS dissector can set it after the 
> sub-dissectors run.
> 
>> 
>> Thanks,
>> Chris.
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-21 Thread Christian Hopps



> On Jan 21, 2020, at 10:24 AM, Anders Broman via Wireshark-dev 
>  wrote:
> 
> 
> 
> -Original Message-
> From: Wireshark-dev  On Behalf Of João 
> Valverde
> Sent: den 21 januari 2020 15:47
> To: wireshark-dev@wireshark.org
> Subject: Re: [Wireshark-dev] q on catching error in sub-dissectors.
> 
> 
> 
> On 21/01/20 14:33, Christian Hopps wrote:
>> So I've got a payload of packets in a single frame. I'm calling 
>> dissector_try_uint_new() to dissect each payload (typically IPv4 packets). 
>> Some of these packets are considered "malformed" by wireshark (e.g., created 
>> by scapy/trex with some bogus values).
>> 
>> The problem I'm hitting is that the first malformed inner packet fails all 
>> the way out of my parent dissector, so it doesn't dissect any of the other 
>> packets in the payload.
>> 
>> Another problem I'm having is that the IP sub-dissector is overwriting my 
>> source and destination addresses in the pinfo/tree (not sure which doesn't 
>> really matter).
>> 
>> Summary:
>> 
>> - How can I "catch" errors in a subdissector so I can call other 
>> sub-dissectors?
> 
> Use TRY/CATCH (in epan/exceptions.h).

Worked!

> 
>> - How can I "block" sub-dissectors from overwriting my outer header 
>> information?
> 
> I don't think you can. Maybe your IPTFS dissector can set it after the 
> sub-dissectors run.
> 
> Not sure how you want it, there is col_set_fence()

So I saved all the pinfo address and port info prior to calling sub-dissectors, 
then restored them, then I called col_fill_in(). This worked.

Thanks,
Chris.

> 
>> 
>> Thanks,
>> Chris.
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> 
>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-21 Thread Anders Broman via Wireshark-dev



-Original Message-
From: Wireshark-dev  On Behalf Of João 
Valverde
Sent: den 21 januari 2020 15:47
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] q on catching error in sub-dissectors.



On 21/01/20 14:33, Christian Hopps wrote:
> So I've got a payload of packets in a single frame. I'm calling 
> dissector_try_uint_new() to dissect each payload (typically IPv4 packets). 
> Some of these packets are considered "malformed" by wireshark (e.g., created 
> by scapy/trex with some bogus values).
>
> The problem I'm hitting is that the first malformed inner packet fails all 
> the way out of my parent dissector, so it doesn't dissect any of the other 
> packets in the payload.
>
> Another problem I'm having is that the IP sub-dissector is overwriting my 
> source and destination addresses in the pinfo/tree (not sure which doesn't 
> really matter).
>
> Summary:
>
> - How can I "catch" errors in a subdissector so I can call other 
> sub-dissectors?

Use TRY/CATCH (in epan/exceptions.h).

> - How can I "block" sub-dissectors from overwriting my outer header 
> information?

I don't think you can. Maybe your IPTFS dissector can set it after the 
sub-dissectors run.

Not sure how you want it, there is col_set_fence()

>
> Thanks,
> Chris.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>   
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


smime.p7s
Description: S/MIME cryptographic signature
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-21 Thread João Valverde

By the way usually a tunnel encapsulates a single packet. I'm not aware 
of any other protocol multiplexing at the IP level. I would assume 
Wireshark requires some replumbing to handle that. Something like TFS 
being treated as a framing layer. Just food for thought.


On 21/01/20 14:46, João Valverde wrote:



On 21/01/20 14:33, Christian Hopps wrote:
So I've got a payload of packets in a single frame. I'm calling 
dissector_try_uint_new() to dissect each payload (typically IPv4 
packets). Some of these packets are considered "malformed" by 
wireshark (e.g., created by scapy/trex with some bogus values).


The problem I'm hitting is that the first malformed inner packet 
fails all the way out of my parent dissector, so it doesn't dissect 
any of the other packets in the payload.


Another problem I'm having is that the IP sub-dissector is 
overwriting my source and destination addresses in the pinfo/tree 
(not sure which doesn't really matter).


Summary:

- How can I "catch" errors in a subdissector so I can call other 
sub-dissectors?


Use TRY/CATCH (in epan/exceptions.h).

- How can I "block" sub-dissectors from overwriting my outer header 
information?


I don't think you can. Maybe your IPTFS dissector can set it after the 
sub-dissectors run.




Thanks,
Chris.
___ 


Sent via:    Wireshark-dev mailing list 
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___ 


Sent via:    Wireshark-dev mailing list 
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

2020-01-21 Thread João Valverde




On 21/01/20 14:33, Christian Hopps wrote:

So I've got a payload of packets in a single frame. I'm calling dissector_try_uint_new() 
to dissect each payload (typically IPv4 packets). Some of these packets are considered 
"malformed" by wireshark (e.g., created by scapy/trex with some bogus values).

The problem I'm hitting is that the first malformed inner packet fails all the 
way out of my parent dissector, so it doesn't dissect any of the other packets 
in the payload.

Another problem I'm having is that the IP sub-dissector is overwriting my 
source and destination addresses in the pinfo/tree (not sure which doesn't 
really matter).

Summary:

- How can I "catch" errors in a subdissector so I can call other sub-dissectors?


Use TRY/CATCH (in epan/exceptions.h).


- How can I "block" sub-dissectors from overwriting my outer header information?


I don't think you can. Maybe your IPTFS dissector can set it after the 
sub-dissectors run.




Thanks,
Chris.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] q on catching error in sub-dissectors.

2020-01-21 Thread Christian Hopps

So I've got a payload of packets in a single frame. I'm calling 
dissector_try_uint_new() to dissect each payload (typically IPv4 packets). Some 
of these packets are considered "malformed" by wireshark (e.g., created by 
scapy/trex with some bogus values).

The problem I'm hitting is that the first malformed inner packet fails all the 
way out of my parent dissector, so it doesn't dissect any of the other packets 
in the payload.

Another problem I'm having is that the IP sub-dissector is overwriting my 
source and destination addresses in the pinfo/tree (not sure which doesn't 
really matter).

Summary:

- How can I "catch" errors in a subdissector so I can call other sub-dissectors?
- How can I "block" sub-dissectors from overwriting my outer header information?

Thanks,
Chris.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

Re: [Wireshark-dev] q on catching error in sub-dissectors.

[Wireshark-dev] q on catching error in sub-dissectors.

13 matches

Site Navigation

Mail list logo

Footer information