New Dissector only applied to first packet

[Jan Willamowius]

Hi,

I'm writing my first dissector based on the example in the Developers
Guide and README.developer.

I register my dissector for a certain port using

dissector_add_uint("udp.port", FOO_PORT, handle);

I notice that it only gets applied to the first packet that matches the
port and I can't apply it to other packets, not even using "Decode As".

How can I figure out what the problem might be ?

Thanks,
Jan

[Guy Harris]

Post by Jan Willamowius
I'm writing my first dissector based on the example in the Developers
Guide and README.developer.
I register my dissector for a certain port using
dissector_add_uint("udp.port", FOO_PORT, handle);
I notice that it only gets applied to the first packet that matches the
port and I can't apply it to other packets, not even using "Decode As".

"Only gets applied" meaning "you have a printf or are running it in the debugger and it's only being called for the first UDP packet being sent to or from port FOO_PORT" or "only gets applied" meaning "I only see the first UDP packet sent to or from port FOO_PORT having the dissector's information in the Protocol and Info columns and only see the dissector's information in the packet details pane when I click on the first such packet"?

The latter isn't necessarily equivalent to the former - if, for example, the dissector is a "new-style" dissector that checks to see if the packet looks as if it's a packet for its protocol, and returns 0 before doing any dissection work if it doesn't, the dissector might get called but might reject the packet.

What do the other packets to or from that port show up as? Do they just show up as UDP, or are they showing up as some other protocol on top of UDP (and perhaps as a "malformed" packet for that protocol)? If the latter, there may be a heuristic dissector or dissectors that are claiming the packets; if the packets aren't for those dissectors' protocols, perhaps the dissectors need to have their heuristics strengthened.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Jan Willamowius]

Post by Guy Harris

Post by Jan Willamowius
I'm writing my first dissector based on the example in the Developers
Guide and README.developer.
I register my dissector for a certain port using
dissector_add_uint("udp.port", FOO_PORT, handle);
I notice that it only gets applied to the first packet that matches the
port and I can't apply it to other packets, not even using "Decode As".

"Only gets applied" meaning "you have a printf or are running it in the debugger and it's only being called for the first UDP packet being sent to or from port FOO_PORT" or "only gets applied" meaning "I only see the first UDP packet sent to or from port FOO_PORT having the dissector's information in the Protocol and Info columns and only see the dissector's information in the packet details pane when I click on the first such packet"?

...

I put a printf in and my dissector doesn't get called.

Post by Guy Harris
What do the other packets to or from that port show up as? Do they just show up as UDP, or are they showing up as some other protocol on top of UDP (and perhaps as a "malformed" packet for that protocol)? If the latter, there may be a heuristic dissector or dissectors that are claiming the packets; if the packets aren't for those dissectors' protocols, perhaps the dissectors need to have their heuristics strengthened.

It turns out that other packets in between are responsible for the
dissector not being called for packets that come after them. If I mark
those to be ignored in the GUI, my dissector is called for all matching
packets and works fine.

My dissector only handles UDP packets, but strangely the stop-packets
are all TCP packets and I have verified that my dissector never even
gets called for them.

Any ideas ?

Thanks,
Jan

[Guy Harris]

Post by Jan Willamowius
It turns out that other packets in between are responsible for the
dissector not being called for packets that come after them. If I mark
those to be ignored in the GUI, my dissector is called for all matching
packets and works fine.
My dissector only handles UDP packets, but strangely the stop-packets
are all TCP packets and I have verified that my dissector never even
gets called for them.

A dissector for one protocol can set up future (in the sense of "later in the capture") packets to or from certain endpoints to be dissected as a particular protocol. This is used, for example, for protocols such as SIP, which initiate a session and specify "use port XXX" for that session, so that future UDP traffic to or from port XXX should be dissected as RTP for that session.

What protocol(s) are in the TCP packets in question?
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Jan Willamowius]

Post by Guy Harris

Post by Jan Willamowius
My dissector only handles UDP packets, but strangely the stop-packets
are all TCP packets and I have verified that my dissector never even
gets called for them.

A dissector for one protocol can set up future (in the sense of "later in the capture") packets to or from certain endpoints to be dissected as a particular protocol. This is used, for example, for protocols such as SIP, which initiate a session and specify "use port XXX" for that session, so that future UDP traffic to or from port XXX should be dissected as RTP for that session.
What protocol(s) are in the TCP packets in question?

...

Thats it!

I'm doing a dissector to decode the H.460.19 RTP multiplexing used by
H.323 and the packets I have to ignore contain openLogicalChannel
messages that probably set up rules to decode future packets as RTP.

Is there a way to override these rules for future packets ?
Or is the only way to adapt the dissector for H.323 to auto detect when
RTP multiplexing is used ?

To start out I was planning to use a manual Decode As instead of the
more difficult auto-detect.

Regards,
Jan

[Guy Harris]

Post by Jan Willamowius

Post by Guy Harris

Post by Jan Willamowius
My dissector only handles UDP packets, but strangely the stop-packets
are all TCP packets and I have verified that my dissector never even
gets called for them.

A dissector for one protocol can set up future (in the sense of "later in the capture") packets to or from certain endpoints to be dissected as a particular protocol. This is used, for example, for protocols such as SIP, which initiate a session and specify "use port XXX" for that session, so that future UDP traffic to or from port XXX should be dissected as RTP for that session.
What protocol(s) are in the TCP packets in question?

Thats it!
I'm doing a dissector to decode the H.460.19 RTP multiplexing used by
H.323 and the packets I have to ignore contain openLogicalChannel
messages that probably set up rules to decode future packets as RTP.

...

At least as I read H.460.19 section 7.3.2 "Multiplexed media mode – RTP/RTCP", it should set up rules to decode future packets as "multiplexed RTP":

When operating in the multiplexed media mode, a multiplexing layer shall be added by H.460.19 entities between the UDP and RTP/RTCP packet headers as shown in Figures 7 and 8.

+---------------------------+
| IP header |
+---------------------------+
| UDP header |
+---------------------------+
| 4-byte multiplexID |
+---------------------------+
| RTP HEADER |
+---------------------------+
| RTP PAYLOAD |
+---------------------------+

Figure 7/H.460.19 – The multiplexed RTP packet

+---------------------------+
| IP header |
+---------------------------+
| UDP header |
+---------------------------+
| 4-byte multiplexID |
+---------------------------+
| RTCP HEADER |
+---------------------------+
| RTCP PAYLOAD |
+---------------------------+
| ... |
+---------------------------+

Figure 8/H.460.19 – The multiplexed RTCP packet

So there'd need to be a dissector for "multiplexed RTP" (which would probably be part of the RTP dissector source file), and, when the multiplexed media mode is negotiated, use the "multiplexed RTP" dissector rather than the regular RTP dissector.

Post by Jan Willamowius
Is there a way to override these rules for future packets ?
Or is the only way to adapt the dissector for H.323 to auto detect when
RTP multiplexing is used ?

It looks, from my quick reading of H.460.19, as if the H.323 dissector would, and could, and probably should detect RTP multiplexing at call setup time.

If you don't have the call setup traffic, RTP traffic would have to be recognized heuristically - the H.323 dissector (or SIP dissector, or...) wouldn't be setting up future packets to be dissected as RTP; a heuristic "multiplexed RTP" dissector could probably recognize "multiplexed RTP" by using the same mechanisms as the regular heuristic RTP dissector but fetching the fields it uses at an offset 4 bytes greater than the regular offset.

___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Jan Willamowius]

Post by Guy Harris

Post by Jan Willamowius
I'm doing a dissector to decode the H.460.19 RTP multiplexing used by
H.323 and the packets I have to ignore contain openLogicalChannel
messages that probably set up rules to decode future packets as RTP.

Ideally, yes.

Post by Guy Harris
When operating in the multiplexed media mode, a multiplexing layer shall be added by H.460.19 entities between the UDP and RTP/RTCP packet headers as shown in Figures 7 and 8.
+---------------------------+
| IP header |
+---------------------------+
| UDP header |
+---------------------------+
| 4-byte multiplexID |
+---------------------------+
| RTP HEADER |
+---------------------------+
| RTP PAYLOAD |
+---------------------------+
Figure 7/H.460.19 – The multiplexed RTP packet
+---------------------------+
| IP header |
+---------------------------+
| UDP header |
+---------------------------+
| 4-byte multiplexID |
+---------------------------+
| RTCP HEADER |
+---------------------------+
| RTCP PAYLOAD |
+---------------------------+
| ... |
+---------------------------+
Figure 8/H.460.19 – The multiplexed RTCP packet
So there'd need to be a dissector for "multiplexed RTP" (which would probably be part of the RTP dissector source file), and, when the multiplexed media mode is negotiated, use the "multiplexed RTP" dissector rather than the regular RTP dissector.

...

I have one as plugin right now that calls the RTP dissector, but either
way is fine by me.

Post by Guy Harris

Post by Jan Willamowius
Is there a way to override these rules for future packets ?
Or is the only way to adapt the dissector for H.323 to auto detect when
RTP multiplexing is used ?

It looks, from my quick reading of H.460.19, as if the H.323 dissector would, and could, and probably should detect RTP multiplexing at call setup time.

No, it cannot. The use of H.460.19 (with or without RTP multiplexing) is
negotiated in Setup / Alerting / Connect if both sides support it. At
that point Wireshark could know that the RTP addresses sent by H.460.19
client side (the side that doesn't set the server flag), should be
disregarded, because that side is possibly behind a NAT.

The use of multiplexing is negotiated in openLogicalChannel and
openLogicalChannelAck. It can be bi-directional or only in one
direction. If one side wants to _receive_ multiplexed RTP, it will add
a multiplexedMediaChannel + control channel to the traversal parameters
plus the payload type it expects.
In the case of an H.460.19 client, those addresses must be disregarded
again, because it may be behind a NAT and the real IPs will be
determined by keepAlive packets.

Post by Guy Harris
If you don't have the call setup traffic, RTP traffic would have to be recognized heuristically - the H.323 dissector (or SIP dissector, or...) wouldn't be setting up future packets to be dissected as RTP; a heuristic "multiplexed RTP" dissector could probably recognize "multiplexed RTP" by using the same mechanisms as the regular heuristic RTP dissector but fetching the fields it uses at an offset 4 bytes greater than the regular offset.

I don't really want to detect it heuristically. If one has the call
signaling, We can know whether it is multiplexed or not and if only
the RTP is available I would prefer to do Decode As.

Looking at the template that packet-h245.c is generated from, I don't
really see where it says that the upcoming channel will be RTP. Is that
implied and all upcoming channels are RTP right now ?
Changing that to multiplexed-RTP is my priority right now.

The other change we could make is disregarding addresses from H.460.19
clients, but that will require to carrying over the state from the
H.225 dissector and it currently seems to work OK without most of the
time.

Regards,
Jan

[Anders Broman]

-----Original Message-----
From: wireshark-dev-bounces-IZ8446WsY0/***@public.gmane.org [mailto:wireshark-dev-bounces-IZ8446WsY0/***@public.gmane.org] On Behalf Of Jan Willamowius
Sent: den 5 november 2012 12:00
To: wireshark-dev-IZ8446WsY0/***@public.gmane.org
Subject: Re: [Wireshark-dev] New Dissector only applied to first packet

Post by Guy Harris

Post by Jan Willamowius
I'm doing a dissector to decode the H.460.19 RTP multiplexing used by
H.323 and the packets I have to ignore contain openLogicalChannel
messages that probably set up rules to decode future packets as RTP.

Ideally, yes.

Post by Guy Harris
When operating in the multiplexed media mode, a multiplexing layer shall be added by H.460.19 entities between the UDP and RTP/RTCP packet headers as shown in Figures 7 and 8.
+---------------------------+
| IP header |
+---------------------------+
| UDP header |
+---------------------------+
| 4-byte multiplexID |
+---------------------------+
| RTP HEADER |
+---------------------------+
| RTP PAYLOAD |
+---------------------------+
Figure 7/H.460.19 - The multiplexed RTP packet
+---------------------------+
| IP header |
+---------------------------+
| UDP header |
+---------------------------+
| 4-byte multiplexID |
+---------------------------+
| RTCP HEADER |
+---------------------------+
| RTCP PAYLOAD |
+---------------------------+
| ... |
+---------------------------+
Figure 8/H.460.19 - The multiplexed RTCP packet
So there'd need to be a dissector for "multiplexed RTP" (which would probably be part of the RTP dissector source file), and, when the multiplexed media mode is negotiated, use the "multiplexed RTP" dissector rather than the regular RTP dissector.

...

I have one as plugin right now that calls the RTP dissector, but either way is fine by me.

Post by Guy Harris

Post by Jan Willamowius
Is there a way to override these rules for future packets ?
Or is the only way to adapt the dissector for H.323 to auto detect
when RTP multiplexing is used ?

It looks, from my quick reading of H.460.19, as if the H.323 dissector would, and could, and probably should detect RTP multiplexing at call setup time.

No, it cannot. The use of H.460.19 (with or without RTP multiplexing) is negotiated in Setup / Alerting / Connect if both sides support it. At that point Wireshark could know that the RTP addresses sent by H.460.19 client side (the side that doesn't set the server flag), should be disregarded, because that side is possibly behind a NAT.

The use of multiplexing is negotiated in openLogicalChannel and openLogicalChannelAck. It can be bi-directional or only in one direction. If one side wants to _receive_ multiplexed RTP, it will add a multiplexedMediaChannel + control channel to the traversal parameters plus the payload type it expects.
In the case of an H.460.19 client, those addresses must be disregarded again, because it may be behind a NAT and the real IPs will be determined by keepAlive packets.

Post by Guy Harris
If you don't have the call setup traffic, RTP traffic would have to be recognized heuristically - the H.323 dissector (or SIP dissector, or...) wouldn't be setting up future packets to be dissected as RTP; a heuristic "multiplexed RTP" dissector could probably recognize "multiplexed RTP" by using the same mechanisms as the regular heuristic RTP dissector but fetching the fields it uses at an offset 4 bytes greater than the regular offset.

I don't really want to detect it heuristically. If one has the call signaling, We can know whether it is multiplexed or not and if only the RTP is available I would prefer to do Decode As.

Looking at the template that packet-h245.c is generated from, I don't really see where it says that the upcoming channel will be RTP. Is that implied and all upcoming channels are RTP right now ?
Changing that to multiplexed-RTP is my priority right now.

The other change we could make is disregarding addresses from H.460.19 clients, but that will require to carrying over the state from the
H.225 dissector and it currently seems to work OK without most of the time.

Regards,
Jan


It ought to be possible to set up the RTP or RTPmux data by using the information in
TraversalParameters ::= SEQUENCE
{
multiplexedMediaChannel TransportAddress OPTIONAL,
multiplexedMediaControlChannel TransportAddress OPTIONAL,
multiplexID INTEGER(0..4294967295) OPTIONAL,
keepAliveChannel TransportAddress OPTIONAL,
keepAlivePayloadType INTEGER (0..127) OPTIONAL,
keepAliveInterval TimeToLive OPTIONAL,
...
}

At least adding dissection of the parameter shouldn't be to difficult given an example trace.

/Anders

--
Jan Willamowius, jan-bB5sYrGU/***@public.gmane.org, http://www.gnugk.org/ ___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Jan Willamowius]

Post by Anders Broman
The use of multiplexing is negotiated in openLogicalChannel and openLogicalChannelAck. It can be bi-directional or only in one direction. If one side wants to _receive_ multiplexed RTP, it will add a multiplexedMediaChannel + control channel to the traversal parameters plus the payload type it expects.
In the case of an H.460.19 client, those addresses must be disregarded again, because it may be behind a NAT and the real IPs will be determined by keepAlive packets.

[...]

Post by Anders Broman
Looking at the template that packet-h245.c is generated from, I don't really see where it says that the upcoming channel will be RTP. Is that implied and all upcoming channels are RTP right now ?
Changing that to multiplexed-RTP is my priority right now.

[...]

Post by Anders Broman
It ought to be possible to set up the RTP or RTPmux data by using the information in
TraversalParameters ::= SEQUENCE
{
multiplexedMediaChannel TransportAddress OPTIONAL,
multiplexedMediaControlChannel TransportAddress OPTIONAL,
multiplexID INTEGER(0..4294967295) OPTIONAL,
keepAliveChannel TransportAddress OPTIONAL,
keepAlivePayloadType INTEGER (0..127) OPTIONAL,
keepAliveInterval TimeToLive OPTIONAL,
...
}
At least adding dissection of the parameter shouldn't be to difficult given an example trace.

...

I have captured a trace of a multiplexing call to test with. One capture
contains one endpoint multiplexing to the H.323 gatekeeper and the
other trace has the other endpoint in it too.

http://www.gnugk.org/download/rtp-mux.pcap
http://www.gnugk.org/download/rtp-mux-both.pcap

Here is my dissector for H.460.19 rtp-mux (which right now can only be
used for Decode As if the openLogicalChannel and openlogicalChannelAck
packets are marked Ignore).

http://www.gnugk.org/download/packet-h46019rtpmux.c

Anders, how could one specify a different dissector for the upcoming
channel in packet-h245.c ?

Regards,
Jan

[Anders Broman]

-----Original Message-----
From: wireshark-dev-bounces-IZ8446WsY0/***@public.gmane.org [mailto:wireshark-dev-bounces-IZ8446WsY0/***@public.gmane.org] On Behalf Of Jan Willamowius
Sent: den 6 november 2012 21:53
To: wireshark-dev-IZ8446WsY0/***@public.gmane.org
Subject: Re: [Wireshark-dev] New Dissector only applied to first packet

Post by Anders Broman
The use of multiplexing is negotiated in openLogicalChannel and openLogicalChannelAck. It can be bi-directional or only in one direction. If one side wants to _receive_ multiplexed RTP, it will add a multiplexedMediaChannel + control channel to the traversal parameters plus the payload type it expects.
In the case of an H.460.19 client, those addresses must be disregarded again, because it may be behind a NAT and the real IPs will be determined by keepAlive packets.

[...]

Post by Anders Broman
Looking at the template that packet-h245.c is generated from, I don't really see where it says that the upcoming channel will be RTP. Is that implied and all upcoming channels are RTP right now ?
Changing that to multiplexed-RTP is my priority right now.

[...]

Post by Anders Broman
It ought to be possible to set up the RTP or RTPmux data by using the
information in TraversalParameters ::= SEQUENCE {
multiplexedMediaChannel TransportAddress OPTIONAL,
multiplexedMediaControlChannel TransportAddress OPTIONAL, multiplexID
INTEGER(0..4294967295) OPTIONAL, keepAliveChannel TransportAddress
OPTIONAL, keepAlivePayloadType INTEGER (0..127) OPTIONAL,
keepAliveInterval TimeToLive OPTIONAL, ...
}
At least adding dissection of the parameter shouldn't be to difficult given an example trace.
I have captured a trace of a multiplexing call to test with. One capture contains one endpoint multiplexing to >the H.323 gatekeeper and the other trace has the other endpoint in it too.
http://www.gnugk.org/download/rtp-mux.pcap
http://www.gnugk.org/download/rtp-mux-both.pcap
Here is my dissector for H.460.19 rtp-mux (which right now can only be used for Decode As if the
openLogicalChannel and openlogicalChannelAck packets are marked Ignore).
http://www.gnugk.org/download/packet-h46019rtpmux.c
Anders, how could one specify a different dissector for the upcoming channel in packet-h245.c ?
Regards,
Jan

...

I'm not familiar with the H.460.19 procedures and don't have the time to dive to deeply into the spec
But using the OLC info it should be possible to "detect" that RTPmux is beeing used and
Overide setup of the RTP conversation and instead create an RTPmux conversation possibly a
Per Conversation data structure is needed to keep information per MUX id about the muxed RTP connections.
Somthing like
"If multiplexID present use_rtpmultiplex = TRUE" and use the IP addr of multiplexedMediaChannel(?)(and ctrl)
As conversation data to set UDP sub dissector as RTPmux.


This should "direct" the RTPmux packets to your dissector which then would remove the mux id and
Call the RTP dissector. Your dissector would probably need set up the RTP paylod data in the RTP
Dissector to have the payload properly dissected. I'm not sure if this is interleaved with the
RTP conversation setup in that case modifications to the RTP dissector may be needed.


About the dissector:
I don't think this lines are needed:
if ((tvb == NULL) || tvb_length(tvb) < 16)
return 0; /* only look at UDP packets */

if (pinfo->ipproto != IP_PROTO_UDP)
return 0;

/* check RTP version */
version = RTP_VERSION(tvb_get_guint8(tvb, 4));
if (version != 2)
return 0;

I'd do all the column stuff after:
/* Clear out stuff in the info column */
col_clear(pinfo->cinfo,COL_INFO);


- mux_id = tvb_get_guint8(tvb, 0)*16777216 + tvb_get_guint8(tvb, 1)*65536 + tvb_get_guint8(tvb, 2)*256 + tvb_get_guint8(tvb, 3);
+ mux_id = tvb_get_ntohl(tvb, 0);

Move proto_register_h46019rtpmux() after dissect_h46019rtpmux()

Regards
Anders

--
Jan Willamowius, jan-bB5sYrGU/***@public.gmane.org, http://www.gnugk.org/ ___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe