i,On Sun, 6 Jun 2004, Jean-Baptiste Marchand wrote:
> Hello,
>
> * Jean-Baptiste Marchand <Jean-Baptiste.Marchand@xxxxxx> [04/06/04 - 11:29]:
>
> > it seems that there is a dissection problem with a current version of
> > the DCE RPC dissector.
> >
> > The first attached capture (epm1_anon.cap) contains 6 frames, 2 two TCP segments
> > (SYN-ACK, ACK) and 4 DCE RPC PDUs. The last two DCE RPC PDUs are not
> > properly dissected as EPM operations.
> >
> > The second attached capture (epm2_anon.cap) is identical to the first one,
> > except that the first TCP segment has been removed. The last two DCE RPC
> > PDUs are properly dissected as EPM operations.
> >
> > The only difference is that in the first case, we see a SYN-ACK TCP
> > segment and thus, this might be something related to TCP conversations?
> >
> > PS: attached traces have been anonymized with ipsumdump
> > (http://www.icir.org/kohler/ipsumdump/), thus IP addresses are different
> > in the traces but they were both generated from the same original trace.
>
> I'm a bit confused because I've tried to open these two captures on a
> recent build of ethereal on MacOS X (CVS tree updated this morning) and
> the two are dissected properly.
>
> On the other hand, I've just updated my CVS tree on my FreeBSD laptop
> and I still have the same problem I described on ethereal-dev@.
>
> It does not seem to be related to a difference in my preferences, as
> I've tried with the default ethereal preference settings (I rename the
> ~/.ethereal directory to ~/.ethereal_old).
>
> Follow tethereal outputs for me (checksum is incorrect because IP
> addresses have been modified because of anonymization with ipsumdump):
>
> jbm@garbarek ~> tethereal -r epm1_anon.cap
> 1 0.000000 194.115.240.203 -> 194.115.240.48 TCP loc-srv > 1053
> [SYN, ACK] Seq=0 Ack=1 Win=17520 [CHECKSUM INCORRECT] Len=0 MSS=1460
> 2 0.001235 194.115.240.48 -> 194.115.240.203 TCP 1053 > loc-srv
> [ACK] Seq=1 Ack=1 Win=17520 [CHECKSUM INCORRECT] Len=0
> 3 0.006250 194.115.240.48 -> 194.115.240.203 DCERPC Bind: call_id: 1
> UUID: EPM
> 4 0.016912 194.115.240.203 -> 194.115.240.48 DCERPC Bind_ack:
> call_id: 1 accept max_xmit: 5840 max_recv: 5840
> 5 0.018674 194.115.240.48 -> 194.115.240.203 DCERPC Request:
> call_id: 1 opnum: 3 ctx_id: 0
> 6 0.021197 194.115.240.203 -> 194.115.240.48 DCERPC Response:
> call_id: 1 ctx_id: 0
>
> jbm@garbarek ~> tethereal -r epm2_anon.cap
> 1 0.000000 205.61.107.240 -> 205.61.107.6 TCP 1053 > loc-srv [ACK]
> Seq=0 Ack=0 Win=17520 [CHECKSUM INCORRECT] Len=0
> 2 0.005015 205.61.107.240 -> 205.61.107.6 DCERPC Bind: call_id: 1
> UUID: EPM
> 3 0.015677 205.61.107.6 -> 205.61.107.240 DCERPC Bind_ack: call_id:
> 1 accept max_xmit: 5840 max_recv: 5840
> 4 0.017439 205.61.107.240 -> 205.61.107.6 EPM Map request
> 5 0.019962 205.61.107.6 -> 205.61.107.240 EPM Map response
>
>
> As you can, frames 5 and 6 are not properly dissected in the first trace
> whereas in the second one, frames 4 and 5 (the first frame is remove in
> the second trace), there are properly recognized as EPM operations...
>
> Any ideas?
>
> Thanks in advance,
>
> Jean-Baptiste Marchand
>