> From: Guy Harris
>
> On Tuesday, July 8, 2003, at 5:52 AM, Biot Olivier wrote:
>
> > I can rely upon the value of smpp.source_addr and
> > smpp.destination_addr in
> > order to identify fragments that are potentially part of the same
> > message. I
> > can create conversations based on smpp.source_addr and
> > smpp.destination_addr
> > (both are NULL-terminated text strings that represent an endpoint's
> > "phone
> > number") addresses (address.type = AT_NONE). The question
> is whether I
> > can
> > reassemble Short Message fragments which are spread across distinct
> > SMPP/TCP
> > connections. To summarize:
> > TCP conversation t1 (SMPP conversation s1): SMS fragment
> 1/2 (smf1)
> > TCP conversation t2 (SMPP conversation s1): SMS fragment
> 2/2 (smf2)
> > ==> How can I reassemble smf1 and smf2
>
> Well, if you set "pinfo->src" and "pinfo->dst" to point to the source
> and destination address structures, and set "pinfo->srcport" and
> "pinfo->dstport" to 0 (unless there's some notion of ports that
> distinguish multiple endpoints on the phones), the reassembly code
> should be able to reassemble based on those addresses.
If I use my AT_NONE addresses, then the conversations are recognized, but
reassembly is not triggered.
> You should probably save them and restore them in case any other
> dissector uses them. (This argues that perhaps there should be
> *stacks* of addresses and ports and the like. It also raises the
> question of whether there should be a general way, if we have those
> stacks, to control which level of the stack should have its addresses
> displayed in the summary; I suspect the answer to that question is
> "yes".)
If I also save the address and port fields of the pinfo struct before
attempting reassembly (and restore them afterwards), then reassembly still
doesn't work *sigh*
As more and more protocols run on top of other protocols, we're starting to
catch the real meaning of a "protocol stack" :) When other addresses are
defined, there's no easy way today of using/specifying them, other than
adding opaque protocol data in a non-uniform manner to the pinfo structure.
My WSP-over-SMPP-over-TCP-over-IP-over-Ethernet example is a real brain
teaser for sure, especially when SMPP transmits short messages having
endpoint addresses not linked to the Ethernet/IP addresses :)
> There is also the potential risk of another dissector also using
> AT_NONE addresses in that fashion; perhaps we should have a mechanism
> by which dissectors can register address and/or port types,
> along with code to display their values.
Currently I seem to be the only one really using AT_NONE; some other
dissectors use a dummy address structure {AT_NONE, 0, NULL} since
the conversation functions require valid address objects (even with
NO_ADDR2 or NO_ADDR_B).
I have attached an attempt at making it work, but I'm not sure what goes
wrong now. Any help is welcome!
Regards,
Olivier
PS: checking in this patch won't harm, but the "TCP conversations t1 & t2
<--> SMPP conversation s1 ==> reassemble smf1 + smf2" problem is still not
solved.
Attachment:
packet-smpp.c.diff
Description: Binary data
