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>