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>