Revision history [back]

My problem is that I don't speak C++ (and I haven't used MATE for at least two years), so I can only surf the surface, but what I could find is that in 2.6.4., MATE has problems to extract fields from protocols specified by the Transport clause of the Pdu definition.

For the following configuration,

Pdu sip_pdu Proto sip Transport udp/ip {
  Extract ipaddr From ip.addr;
  Extract udpport From udp.port;
  Extract user From sip.from.user;
  Extract user From sip.to.user;
  Extract user From sip.ppi.user;
  Extract callid From sip.Call-ID;
  Extract method From sip.Method;
  Extract cseq From sip.CSeq.seq;
  Extract resp_code From sip.Status-Code;
  Extract req_method From sip.CSeq.method;
  Transform start_stop_cond, xtract_rsp;
};

MATE log says (### comments added by me):

mate_analyze_frame: trying to extract: sip_pdu
mate_analyze_frame: found matching proto, extracting: sip_pdu
new_pdu: type=sip_pdu framenum=1
new_pdu: proto range 42-966
get_pdu_fields: found field 34-36
### this matches to udp.srcport
get_pdu_fields: found field 36-38
### this matches to udp.dstport
get_pdu_fields: found field 42-48
get_pdu_fields: got method=INVITE
get_pdu_fields: found field 261-266
get_pdu_fields: got user=10001
get_pdu_fields: found field 194-199
get_pdu_fields: got user=10003
get_pdu_fields: found field 298-344
get_pdu_fields: got [email protected]
get_pdu_fields: found field 350-351
get_pdu_fields: got cseq=1
get_pdu_fields: found field 352-358
get_pdu_fields: got req_method=INVITE
get_pdu_fields: found field 26-30
### this matches to ip.src
get_pdu_fields: found field 30-34
### this matches to ip.dst
mate_analyze_frame: trying to extract: sip_pdu
### this is the start of processing of next frame

So it does find both the ip.addr fields (ip.src and ip.dst) and both udp.port fields but it has some problem with their size and (therefore?) it doesn't extract them. It does not, however, have a problem with the SIP fields whose size it determines properly.

So in your case, giop_addr and giop_port don't get extracted, which means that the Gop doesn't build as its Match requires both of them (twice).

But as I was trying to understand where the problem was (because I was suspecting the ip and tcp dissectors to report wrong field size to MATE), I have incidentally found a workaround for you.

If you add

Pdu ip_pdu Proto ip Transport eth {
  Extract ipaddr From ip.addr;
};

Pdu tcp_pdu Proto tcp Transport ip {
  Extract port From tcp.port;
};

before the Pdu giop_pdu in your MATE configuration file, some voodoo will make MATE identify the fields when it extracts them for the giop Pdu as they have been previously extraced for their native protocols when processing the same frame, despite the fact that the length is incorrect even when they are extracted from their native Proto:

mate_analyze_frame: trying to extract: udp_pdu
mate_analyze_frame: found matching proto, extracting: udp_pdu
new_pdu: type=udp_pdu framenum=1
new_pdu: proto range 34-42
get_pdu_fields: found field 34-36
get_pdu_fields: got port=5060
get_pdu_fields: found field 36-38
get_pdu_fields: got port=5060

So please file a bug, place a link to this Question to it, and place a link to the bug here.

I'm not sure whether a change in ip, tcp and udp dissectors has made them report a wrong field size, but it seems more likely to me than that someone has touched the MATE code - Lekensteyn was fixing the Loose match a year or two ago but that should not be related to this.

My problem is that I don't speak C++ (and I haven't used MATE for at least two years), so I can only surf the surface, but what I could find is that in 2.6.4., MATE has problems to extract fields from protocols specified by the Transport clause of the Pdu definition.

For the following configuration,

Pdu sip_pdu Proto sip Transport udp/ip {
  Extract ipaddr From ip.addr;
  Extract udpport From udp.port;
  Extract user From sip.from.user;
  Extract user From sip.to.user;
  Extract user From sip.ppi.user;
  Extract callid From sip.Call-ID;
  Extract method From sip.Method;
  Extract cseq From sip.CSeq.seq;
  Extract resp_code From sip.Status-Code;
  Extract req_method From sip.CSeq.method;
  Transform start_stop_cond, xtract_rsp;
};

MATE log says (### comments added by me):

mate_analyze_frame: trying to extract: sip_pdu
mate_analyze_frame: found matching proto, extracting: sip_pdu
new_pdu: type=sip_pdu framenum=1
new_pdu: proto range 42-966
get_pdu_fields: found field 34-36
### this matches to udp.srcport
get_pdu_fields: found field 36-38
### this matches to udp.dstport
get_pdu_fields: found field 42-48
get_pdu_fields: got method=INVITE
get_pdu_fields: found field 261-266
get_pdu_fields: got user=10001
get_pdu_fields: found field 194-199
get_pdu_fields: got user=10003
get_pdu_fields: found field 298-344
get_pdu_fields: got [email protected]
get_pdu_fields: found field 350-351
get_pdu_fields: got cseq=1
get_pdu_fields: found field 352-358
get_pdu_fields: got req_method=INVITE
get_pdu_fields: found field 26-30
### this matches to ip.src
get_pdu_fields: found field 30-34
### this matches to ip.dst
mate_analyze_frame: trying to extract: sip_pdu
### this is the start of processing of next frame

So it does find both the ip.addr fields (ip.src and ip.dst) and both udp.port fields but it has some problem with their size and (therefore?) it doesn't extract them. It does not, however, have a problem with the SIP fields whose size it determines properly.

So in your case, giop_addr and giop_port don't get extracted, which means that the Gop Gop doesn't build up as its Match requires both of them (twice).

But as I was trying to understand where the problem was (because I was suspecting the ip and tcp dissectors to report wrong field size to MATE), I have incidentally found a workaround for you.

If you add

Pdu ip_pdu Proto ip Transport eth {
  Extract ipaddr From ip.addr;
};

Pdu tcp_pdu Proto tcp Transport ip {
  Extract port From tcp.port;
};

before the Pdu giop_pdu in your MATE configuration file, some voodoo will make MATE identify the fields when it extracts them for the giop Pdu as they have been previously extraced for their native protocols when processing the same frame, despite the fact that the length is incorrect even when they are extracted from their native Proto:

mate_analyze_frame: trying to extract: udp_pdu
mate_analyze_frame: found matching proto, extracting: udp_pdu
new_pdu: type=udp_pdu framenum=1
new_pdu: proto range 34-42
get_pdu_fields: found field 34-36
get_pdu_fields: got port=5060
get_pdu_fields: found field 36-38
get_pdu_fields: got port=5060

So please file a bug, place a link to this Question to it, and place a link to the bug here.

I'm not sure whether a change in ip, tcp and udp dissectors has made them report a wrong field size, but it seems more likely to me than that someone has touched the MATE code - Lekensteyn was fixing the Loose match a year or two ago but that should not be related to this.

My problem is that I don't speak C++ (and I haven't used MATE for at least two years), so I can only surf the surface, but what I could find is that in 2.6.4., MATE has problems to extract fields from protocols specified by the Transport clause of the Pdu definition.definition. Don't give up reading - workaround inside.

For the following configuration,

Pdu sip_pdu Proto sip Transport udp/ip {
  Extract ipaddr From ip.addr;
  Extract udpport From udp.port;
  Extract user From sip.from.user;
  Extract user From sip.to.user;
  Extract user From sip.ppi.user;
  Extract callid From sip.Call-ID;
  Extract method From sip.Method;
  Extract cseq From sip.CSeq.seq;
  Extract resp_code From sip.Status-Code;
  Extract req_method From sip.CSeq.method;
  Transform start_stop_cond, xtract_rsp;
};

MATE log says (### comments added by me):

mate_analyze_frame: trying to extract: sip_pdu
mate_analyze_frame: found matching proto, extracting: sip_pdu
new_pdu: type=sip_pdu framenum=1
new_pdu: proto range 42-966
get_pdu_fields: found field 34-36
### this matches to udp.srcport
get_pdu_fields: found field 36-38
### this matches to udp.dstport
get_pdu_fields: found field 42-48
get_pdu_fields: got method=INVITE
get_pdu_fields: found field 261-266
get_pdu_fields: got user=10001
get_pdu_fields: found field 194-199
get_pdu_fields: got user=10003
get_pdu_fields: found field 298-344
get_pdu_fields: got [email protected]
get_pdu_fields: found field 350-351
get_pdu_fields: got cseq=1
get_pdu_fields: found field 352-358
get_pdu_fields: got req_method=INVITE
get_pdu_fields: found field 26-30
### this matches to ip.src
get_pdu_fields: found field 30-34
### this matches to ip.dst
mate_analyze_frame: trying to extract: sip_pdu
### this is the start of processing of next frame

So it does find both the ip.addr fields (ip.src and ip.dst) and both udp.port fields but it has some problem with their size and (therefore?) it doesn't extract them. It does not, however, have a problem with the SIP fields whose size it determines properly.

So in your case, giop_addr and giop_port don't get extracted, which means that the Gop doesn't build up as its Match requires both of them (twice).

But as I was trying to understand where the problem was (because I was suspecting the ip and tcp dissectors to report wrong field size to MATE), I have incidentally found a workaround for you.

If you add

Pdu ip_pdu Proto ip Transport eth {
  Extract ipaddr From ip.addr;
};

Pdu tcp_pdu Proto tcp Transport ip {
  Extract port From tcp.port;
};

before the Pdu giop_pdu in your MATE configuration file, some voodoo will make MATE identify the fields when it extracts them for the giop Pdu as they have been previously extraced for their native protocols when processing the same frame, despite the fact that the length is incorrect even when they are extracted from their native Proto:

mate_analyze_frame: trying to extract: udp_pdu
mate_analyze_frame: found matching proto, extracting: udp_pdu
new_pdu: type=udp_pdu framenum=1
new_pdu: proto range 34-42
get_pdu_fields: found field 34-36
get_pdu_fields: got port=5060
get_pdu_fields: found field 36-38
get_pdu_fields: got port=5060

So please file a bug, place a link to this Question to it, and place a link to the bug here.

I'm not sure whether a change in ip, tcp and udp dissectors has made them report a wrong field size, but it seems more likely to me than that someone has touched the MATE code - Lekensteyn was fixing the Loose match a year or two ago but that should not be related to this.