Hi, Tony.
How to triage depends on the situation,
but most basic triage is investigating pktrecv.
Your point is correct.
At the same time,
investigating tcpdump files (*.dump) is also important for 1st step.
Thanks,
On Wed, 13 Feb 2008 21:21:13 -0800
"Anthony Coon" <acoon@vmware.com> wrote:
>
>
>
>
> The fragment of message is from a successful test execution using RHEL5. My
> purpose is to understand how to triage TAHI fails. I included the fragment
> as it seemed to illustrate mapping the frames from the pktrecv command to the
> trace. Sorry if I confused you.
>
> You are correct, in the case illustrated by the included files, the remote
> freeBSD machine did not reply correctly to the ICMP Echo request. I have
> seen a number of such fails, I am trying to determine what the cause may be.
>
> grepping for ns_"ell two ell" was found in the .def just as you said.
>
> Again, many thanks for your help.
>
> cheers,
> Tony
>
> -----Original Message-----
> From: Yukiyo Akisada [mailto:akisada@tahi.org]
> Sent: Wed 2/13/2008 5:22 PM
> To: Anthony Coon
> Cc: users@tahi.org
> Subject: Re: [users:00582] definition of frames
>
> Hi, Tony.
>
> Are attached files are the same as the previous?
>
>
> In this time,
> I couldn't find the message starting from
>
> > ===u_ns_g2l_wo=================================
> > ng compare _HDR_IPV6_u_ns_g2l_wo.HopLimit received:64 = 255 ng compare
> > _HDR_IPV6_u_ns_g2l_wo.DestinationAddress
> > received:3ffe:501:ffff:106:200:ff:fe00:a0a0 = fe80::200:ff:fe00:100 ng
> > meta Packet_IPv6.ICMPv6_NS != Packet_IPv6.ICMPv6_EchoReply
>
> In this attached file show me
> that your device didn't send back any Echo Reply at that point.
> Your test38.trace only says,
>
> ##### execCmd()... /usr/local/v6eval//bin/pktrecv -t \
> /usr/local/v6eval//etc//tn.def -n /usr/local/v6eval//etc//nut.def \
> -p /var/tmp/tmp.0.dYvLLa -l1 -i Link0 -e 5 u_ns_g2l_wo ns_l2l \
> u_ns_l2l_wo u_ns_g2l u_ns_l2g_wo ns_g2g ns_g2l u_ns_l2l u_ns_g2g \
> u_ns_g2g_wo u_ns_l2g ns_l2g echo_reply echo_reply_rh_rv
> ##### execCmd()ret... log:pktbuf timeout
> ##### Catch child die pid=42079 status=0x00000100
> Cannot receive Echo Reply
> NG
>
> Please confirm it.
>
> And, talking about framename -- ns_l2l,
> it is not '1 (one)' but 'l (L)'. :-)
>
> $ pwd
> /usr/home/akisada/work/Self_Test_1-4-9
> $ find . -name "*.def" -exec grep ns_l2l {} \;
> ns_l2l,
> u_ns_l2l,
> u_ns_l2l_wo,
> ns_l2l_tr1,
> ns_l2l,
> u_ns_l2l,
> u_ns_l2l_wo,
> $
>
> Thanks,
>
>
> On Wed, 13 Feb 2008 09:07:59 -0800
> "Anthony Coon" <acoon@vmware.com> wrote:
>
> >
> > First, let me offer my gratitude for your help, it is very much
> appreciated.
> >
> > note: test38, in this case is v6LC.1.2.9
> > both NUT and TN are freeBSD 6.2
> >
> > I have attached 3 files,
> > test38.trace - a typescript capture of the Spec test 38 run with trace
> > enabled
> > 38.html
> > 38.html.Link0.dump
> >
> > It appears that the test failed because the NUT did not return a ICMP
> Reply.
> > The partial trace was from another NUT (RHEL5) where the test passed.
> >
> > I'm using Self_Test 1.4.9, but I cannot grep ns_121 in any .def file, e.g.
> >
> > tcdell2# pwd
> > /usr/local/Self_Test_1-4-9
> > tcdell2# find . -name "*.def" -exec grep ns_121 {} \;
> > tcdell2#
> >
> > I think I am doing something dreadfully wrong here.
> >
> > Again, many thanks.
> >
> > Tony
> > -----Original Message-----
> > From: Yukiyo Akisada [mailto:akisada@tahi.org]
> > Sent: Tuesday, February 12, 2008 5:13 PM
> > To: Anthony Coon
> > Cc: users@tahi.org
> > Subject: Re: [users:00582] definition of frames
> >
> > Hi, Tony.
> >
> > Could you send me corresponding <test number.html>?
> > And which version were you using?
> >
> > In my environment, I can find "ns_121" in "*.def".
> > And you must have "ns_121" in "*.def".
> > If there is a lack of packet definition, you can see other message from the
> > tool.
> >
> > Anyway, in this case,
> > pktrecv tried packet matching with packet definition in order of arguments.
> >
> > - u_ns_g2l_wo
> > - ns_l2l
> > - u_ns_l2l_wo
> > - u_ns_g2l
> > - u_ns_l2g_wo
> > - ns_g2g
> > - ns_g2l
> > - u_ns_l2l
> > - u_ns_g2g
> > - u_ns_g2g_wo
> > - u_ns_l2g
> > - ns_l2g
> > - echo_reply
> > - echo_reply_rh_rv
> >
> > Your attached log is showing you
> > that packet matching is doing in that order.
> >
> > If you show me not-truncated log,
> > I can give you more detail information.
> >
> > Now,
> > what only I can understand from your log is that you sent a ICMPv6 Echo
> Reply
> > like below.
> >
> > Frame_Ether
> > | Hdr_Ether
> > | | DestinationAddress = 00:00:00:00:01:00
> > | Packet_IPv6
> > | | Hdr_IPv6
> > | | | HopLimit = 64
> > | | | SourceAddress = 3ffe:501:ffff:100:21a:4bff:feae:6d90
> > | | | DestinationAddress = 3ffe:501:ffff:106:200:ff:fe00:a0a0
> > | | ICMPv6_EchoReply
> >
> > But some fields are mismatched with our expected packet.
> >
> > Thanks,
> >
> >
> >
> > On Tue, 12 Feb 2008 14:28:15 -0800
> > "Anthony Coon" <acoon@vmware.com> wrote:
> >
> > >
> > > Sorry, I should have been more specific.
> > >
> > > I ran a failed test with trace and got this:
> > >
> > > ##### execCmd()ret... std: 1202767248.683165 Send Echo Request with
> > > Routing Header ##### execCmd()... /usr/local/v6eval//bin/pktrecv -t
> > > /usr/local/v6eval//etc//tn.def -n /usr/local/v6eval//et c//nut.def -p
> > > /var/tmp/tmp.0.dYvLLa -l1 -i Link0 -e 5 u_ns_g2l_wo ns_l2l u_ns_l2l_wo
> > > u_ns_g2l u_ns_l2g_wo ns _g2g ns_g2l u_ns_l2l u_ns_g2g u_ns_g2g_wo
> > > u_ns_l2g ns_l2g echo_reply echo_reply_rh_rv ##### execCmd()ret...
> > > log:pktbuf timeout ##### Catch child die pid=42079 status=0x00000100
> > > Cannot receive Echo Reply NG
> > > --- Cleanup NUT
> > >
> > > I know that it failed because it did not receive an Echo Reply, but I
> > > am curious about the construction of the pktrecv command. The
> > > arguments are documented in the IPv6 Verification Tool User Manual,
> > > but the array of frame descriptions that follows is interesting. They
> > > map to the packet capture description in the <test number.html> file,
> e.g.
> > >
> > > ===u_ns_g2l_wo=================================
> > > ng compare _HDR_IPV6_u_ns_g2l_wo.HopLimit received:64 = 255 ng compare
> > > _HDR_IPV6_u_ns_g2l_wo.DestinationAddress
> > > received:3ffe:501:ffff:106:200:ff:fe00:a0a0 = fe80::200:ff:fe00:100 ng
> > > meta Packet_IPv6.ICMPv6_NS != Packet_IPv6.ICMPv6_EchoReply
> > > ===ns_l2l=================================
> > > ng compare _HETHER_nut2tnsolnode.DestinationAddress
> > > received:00:00:00:00:01:00 = 33:33:ff:00:01:00 ng compare
> > > _HDR_IPV6_ns_l2l.HopLimit received:64 = 255 ng compare
> > > _HDR_IPV6_ns_l2l.SourceAddress
> > > received:3ffe:501:ffff:100:21a:4bff:feae:6d90 =
> > > fe80::21a:4bff:feae:6d90 ng compare
> > > _HDR_IPV6_ns_l2l.DestinationAddress
> > > received:3ffe:501:ffff:106:200:ff:fe00:a0a0 = ff02::1:ff00:100 ng meta
> > > Packet_IPv6.ICMPv6_NS != Packet_IPv6.ICMPv6_EchoReply
> > > ===u_ns_l2l_wo=================================
> > > ng compare _HDR_IPV6_u_ns_l2l_wo.HopLimit received:64 = 255 ng compare
> > > _HDR_IPV6_u_ns_l2l_wo.SourceAddress
> > > received:3ffe:501:ffff:100:21a:4bff:feae:6d90 =
> > > fe80::21a:4bff:feae:6d90 ng compare
> > > _HDR_IPV6_u_ns_l2l_wo.DestinationAddress
> > > received:3ffe:501:ffff:106:200:ff:fe00:a0a0 = fe80::200:ff:fe00:100 ng
> > > meta Packet_IPv6.ICMPv6_NS != Packet_IPv6.ICMPv6_EchoReply
> > > ===u_ns_g2l=================================
> > > ng compare _HDR_IPV6_u_ns_g2l.HopLimit received:64 = 255 ng compare
> > > _HDR_IPV6_u_ns_g2l.DestinationAddress
> > > received:3ffe:501:ffff:106:200:ff:fe00:a0a0 = fe80::200:ff:fe00:100 ng
> > > meta Packet_IPv6.ICMPv6_NS != Packet_IPv6.ICMPv6_EchoReply
> > >
> > > ...and so on.
> > >
> > > While my immediate objective is to triage the fail, I also want to
> > > understand more generally how to triage TAHI fails.
> > >
> > > The descriptions such as ns_121 don't seem to be in the .def file.
> > >
> > > Any help or pointers are appreciated.
> > >
> > > cheers,
> > > Tony
> > >
> > > -----Original Message-----
> > > From: Yukiyo Akisada [mailto:akisada@tahi.org]
> > > Sent: Monday, February 11, 2008 7:45 PM
> > > To: Anthony Coon
> > > Cc: users@tahi.org
> > > Subject: Re: [users:00582] definition of frames
> > >
> > > Hi, Tony.
> > >
> > > Please just grep it!
> > >
> > > You can find it in "*.def" files.
> > >
> > > "u_ns_g2l_wo" and "ns_l2l" are just the local name of packet definition.
> > > pktsend and pktrecv can access the packet image (generate/expected)
> > > through such a parameter.
> > >
> > > Thanks,
> > >
> > >
> > > On Mon, 11 Feb 2008 16:36:18 -0800
> > > "Anthony Coon" <acoon@vmware.com> wrote:
> > >
> > > > Greetings,
> > > >
> > > > Can someone point me to the definition of the frames parameter that
> > > > is passed to pktsend/pktrecv? For example what is "u_ns_g2l_wo" or
> > "ns_l2l".
> > > >
> > > > Thanks,
> > > > Tony
> > > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > --
> > > Yukiyo Akisada <akisada@tahi.org>
> > >
> > >
> >
> >
> > ------------------------------------------------------------------------
> > Yukiyo Akisada <akisada@tahi.org>
> >
>
>
> ------------------------------------------------------------------------
> Yukiyo Akisada <akisada@tahi.org>
>
>
>
>
------------------------------------------------------------------------
Yukiyo Akisada <akisada@tahi.org>