Thanks Ronnie,
I was always wondering how ethereal could identify TCP session being
used for iSCSI(or other L5 proto) in case when I start ethereal in the
middle of TCP session? And also it is possible that iSCSI header & data
could be easily somewhere in the middle of TCP payload with unknown(from
TCP/IP point of view) offset.
I would appreciate if you could enlighten us a little bit on how it is
implemented in ethereal.
Thanks,
Dima
On Sat, 2005-04-30 at 12:18 -0400, ronnie sahlberg wrote:
> Hi,
>
> The problem was that some dataout packets were mistaken for being
> DCERPC and this made the iscsi dissector to loose track of the
> position in the bytestream for the start of the next pdu.
>
> I have added a change to the iscsi dissector to once it has positively
> identified a tcp session as being used for iscsi then it will block
> all heuristic dissectors from that tcp session.
>
> You should no longer need to disable the DCERPC protocol.
>
> thanks for the report.
>
>
> On 4/21/05, Ming Zhang <mingz@xxxxxxxxxxx> wrote:
> > and if i disable all other protocols except ethernet, ip, tcp, iscsi in
> > ethereal analyze (hint from Dima), these snack disappeared.
> >
> > ming
> >
> >
> > On Thu, 2005-04-21 at 05:04 -0400, ronnie sahlberg wrote:
> > > yeah i saw those weird SNACKs too.
> > >
> > > a very very quick eyeballing of them suggests that it is a bug in the
> > > sender of those semgents and not the thereal decode.
> > >
> > > i will check it properly tomorrow. it is probably an ethereal bug or
> > > else the other iscsi host receiving them should have been very
> > > "confused" and a hard error should have resulted.
> > >
> > >
> > >
> > >
> > >
> > > On 4/20/05, Ming Zhang <mingz@xxxxxxxxxxx> wrote:
> > > > and still this log
> > > >
> > > > all the iscsi snack requests like 520, 529, have strange decoding. the
> > > > data before decoding is unreasonable. just a ascend order of all ascii.
> > > >
> > > >
> > > > ming
> > > >
> > > > On Wed, 2005-04-20 at 13:39 +1000, ronnie sahlberg wrote:
> > > > > that frame looks normal to me.
> > > > > it is just that the initiator generated three scsi commands and sent
> > > > > them across and the TCP layer decided to collapse them all into one
> > > > > single tcp segment.
> > > > >
> > > > > this happens if the application is generating pdu's faster than the
> > > > > tcp layer can push the data out the wire.
> > > > >
> > > > >
> > > > >
> > > > > On 4/20/05, Ming Zhang <mingz@xxxxxxxxxxx> wrote:
> > > > > > met a strange error when decoding attached log, No 531. i do not
> > know
> > > > > > how to describe it accurately. but in decode window i see something
> > > > like
> > > > > >
> > > > > > Frame 531
> > > > > > Ethernet
> > > > > > Internet protocol
> > > > > > TCP
> > > > > > iSCSI
> > > > > > SCSI CDB
> > > > > > ISCSI
> > > > > > SCSI CDB
> > > > > > iSCSI
> > > > > > SCSI CDB
> > > > > >
> > > > > > so it looks like extra 2 pairs of iscsi/scsi here.
> > > > > >
> > > > > > Running with libpcap version 0.8.3 on Linux 2.6.10-1.770_FC3.
> > > > > >
> > > > > >
> > > > > > ming
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Ethereal-dev mailing list
> > > > > > Ethereal-dev@xxxxxxxxxxxx
> > > > > > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r
> _______________________________________________
> Iscsitarget-devel mailing list
> Iscsitarget-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel
