Dave, there is no sign of test framework installing/patching scapy in the log you provided.
Could you please do in the same workspace make test-wipe and then run the make test again? I don't think it'll actually help us, because there should be no way for a python inside virtualenv to get its hands on outside libs (unless there is a bug of course), but let's see what happens... Thanks, Klement Quoting Dave Wallace (2017-01-04 19:19:04) > Neale, > > I could not find scapy installed in the normal path (i.e. "which scapy"), > but I'm not sure if it is directly executable. You can find the "V=1 > TEST=mpls make test" output on > vagrant+virtualbox:puppetlabs/ubuntu-16.04.64-nocm in this pastebin doc: > [1]http://pastebin.com/uGAUREhK > > Thanks, > -daw- > > On 1/4/2017 10:59 AM, Neale Ranns (nranns) wrote: > > > > Hi, > > > > The reason the MPLS tests are failing is because scapy cannot decode an > MPLS label stack (output from some .show() instrumentation); > > > > <class 'scapy.layers.l2.Ether'> > > ###[ Ethernet ]### > > dst = 02:01:00:00:ff:02 > > src = 02:fe:e5:05:0e:13 > > type = 0x8847 > > ###[ MPLS ]### > > label = 33L > > cos = 0L > > s = 0L <<<<<< NON End-of-stack > > ttl = 254 > > ###[ Padding ]### > > load = '\x00\x061\xffE\x00\x00#\x00\x01\x00\x00@\x11 > \xa6\xac\x10\x01\x01\xac\x10\x01\x02\x04\xd2\x04\xd2\x00\x0f\xd0\x92257 > 1 1' > > > > we patch scapy for this purpose, see; > > <ROOT>/test/patches/scapy-2.3.3/mpls.py.patch > > > > on my vagrant 14.04 there is no other scapy installation, this patch > applies fine and all MPLS tests pass. > > On a UCS 14.04, with another scapy installation: > > /usr/local/lib/python2.7/dist-packages/scapy/contrib/mpls.py > > the MPLS test fail. > > On a UCS 16.04 no scpay installation, tests pass. > > > > Do you have scapy installed in the machines on which the tests > fail/pass? Or am I barking up the wrong virtualenv tree J > > > > Thanks, > > neale > > > > > > > > From: Dave Wallace [2]<dwallac...@gmail.com> > Date: Wednesday, 4 January 2017 at 15:38 > To: "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" > [3]<ksek...@cisco.com>, "Maciek Konstantynowicz (mkonstan)" > [4]<mkons...@cisco.com>, "Neale Ranns (nranns)" [5]<nra...@cisco.com> > Cc: [6]"csit-...@lists.fd.io" [7]<csit-...@lists.fd.io>, > [8]"vpp-dev@lists.fd.io" [9]<vpp-dev@lists.fd.io> > Subject: Re: [csit-dev] [vpp-dev] vpp make test for verify - are we > there yet ? [awoken] > > > > Klement, > > I'm in the process of modifying the base Vagrantfile/build scripts to > replace building the VPP native package and installing it in the VM to > simply running "make test" which takes much less time. All of the > test runs that I have performed are clean builds on a virgin git clone > repo. > > That being said, I'll give the "git clean -dfX */" a try and see if I > get different results on the 2nd pass and report back. > > Thanks, > -daw- > > On 1/4/17 10:23 AM, Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES > at Cisco) wrote: > > Hi Dave, > > > > could you please try running git clean -dfX */ in a workspace, where you see > > the failures, and then givet it another try? For me this seems to clear > issues > > up. Damjans recent changes might have caused (quoting Damjan) "major > > disturbances in the force", leaving build artifacts behind. > > > > Just be sure to stash/commit any changes you have in the workspace since > > the git clean nukes everything unknown from the ws. > > > > Thanks, > > Klement > > > > Quoting Dave Wallace (2017-01-04 16:12:38) > > As I mentioned on the VPP call yesterday, I'm seeing what appears to be > > the same GRE test failures on Ubuntu 16.10 (bare metal). I'm also seeing > > the same failures on vagrant+virtualbox with > > puppetlabs/ubuntu-16.04.64-nocm. I also am getting failures on 3 out of 4 > > MPLS tests on both environments. > > > > However, all tests pass on vagrant+virtualbox with > > puppetlabs/ubuntu-14.04.64-nocm. > > > > Thanks, > > -daw- > > > > On 1/4/17 9:47 AM, Maciek Konstantynowicz (mkonstan) wrote: > > > > baremetal trusty: > > > > $ lsb_release -a > > No LSB modules are available. > > Distributor ID: Ubuntu > > Description: Ubuntu 14.04.4 LTS > > Release: 14.04 > > Codename: trusty > > $ uname -a > > Linux homes1 3.16.0-77-generic #99~14.04.1-Ubuntu SMP Tue Jun 28 19:17:10 > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > > > -Maciek > > > > > > On 4 Jan 2017, at 13:42, Neale Ranns (nranns) [1][10]<nra...@cisco.com> > wrote: > > > > > > Hi Klement, Maciek, > > > > What environment are you running the tests in? > > I get different results. Running in the default vagrant env provided in > 17.0. Everything passes apart from: > > > > ====================================================================== > > Bidirectional Forwarding Detection (BFD) > > ====================================================================== > > verify session goes down after inactivity OK > > hold BFD session up OK > > large remote RequiredMinRxInterval ERROR [ temp > dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ] > > bring BFD session up ERROR [ temp > dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ] > > verify slow periodic control frames while session down ERROR [ temp > dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ] > > no packets when zero BFD RemoteMinRxInterval ERROR [ temp > dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ] > > > > details below. Different runs give different combinations of failures from > this BFD list. > > > > /neale > > > > ===================================================================== > > ERROR: large remote RequiredMinRxInterval > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File "/vpp/test/test_bfd.py", line 257, in test_large_required_min_rx > > self.bfd_session_up() > > File "/vpp/test/test_bfd.py", line 219, in bfd_session_up > > p = self.wait_for_bfd_packet() > > File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet > > p = self.pg0.wait_for_packet(timeout=timeout) > > File "/vpp/test/vpp_pg_interface.py", line 217, in wait_for_packet > > self.wait_for_capture_file(timeout) > > File "/vpp/test/vpp_pg_interface.py", line 204, in wait_for_capture_file > > raise Exception("Capture file did not appear within timeout") > > Exception: Capture file did not appear within timeout > > > > ====================================================================== > > ERROR: bring BFD session up > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File "/vpp/test/test_bfd.py", line 234, in test_session_up > > self.bfd_session_up() > > File "/vpp/test/test_bfd.py", line 219, in bfd_session_up > > p = self.wait_for_bfd_packet() > > File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet > > p = self.pg0.wait_for_packet(timeout=timeout) > > File "/vpp/test/vpp_pg_interface.py", line 217, in wait_for_packet > > self.wait_for_capture_file(timeout) > > File "/vpp/test/vpp_pg_interface.py", line 204, in wait_for_capture_file > > raise Exception("Capture file did not appear within timeout") > > Exception: Capture file did not appear within timeout > > > > ====================================================================== > > ERROR: verify slow periodic control frames while session down > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File "/vpp/test/test_bfd.py", line 187, in test_slow_timer > > self.wait_for_bfd_packet() > > File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet > > p = self.pg0.wait_for_packet(timeout=timeout) > > File "/vpp/test/vpp_pg_interface.py", line 217, in wait_for_packet > > self.wait_for_capture_file(timeout) > > File "/vpp/test/vpp_pg_interface.py", line 204, in wait_for_capture_file > > raise Exception("Capture file did not appear within timeout") > > Exception: Capture file did not appear within timeout > > > > ====================================================================== > > ERROR: no packets when zero BFD RemoteMinRxInterval > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File "/vpp/test/test_bfd.py", line 201, in test_zero_remote_min_rx > > p = self.wait_for_bfd_packet() > > File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet > > p = self.pg0.wait_for_packet(timeout=timeout) > > File "/vpp/test/vpp_pg_interface.py", line 217, in wait_for_packet > > self.wait_for_capture_file(timeout) > > File "/vpp/test/vpp_pg_interface.py", line 204, in wait_for_capture_file > > raise Exception("Capture file did not appear within timeout") > > Exception: Capture file did not appear within timeout > > > > Ran 64 tests in 84.161s > > > > > > > > > > > > > > On 04/01/2017, 09:45, [2][11]"csit-dev-boun...@lists.fd.io on behalf of > Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" > [3][12]<csit-dev-boun...@lists.fd.io on behalf of ksek...@cisco.com> wrote: > > > > I tried doing a git checkout origin/stable/1701 - is that the correct > > branch? On that one, the GRE indeed doesn't work, but I don't think it's > > 'make test' issue, here's a sample from packet trace: > > > > ------------------- Start of thread 0 vpp_main ------------------- > > Packet 1 > > > > 00:00:07:119382: pg-input > > stream pcap1, 88 bytes > > current data 0, length 88, free-list 6, trace 0x0 > > IP4: 02:01:00:00:ff:02 -> 02:fe:39:17:74:65 > > GRE: 2.2.2.2 -> 172.16.1.1 > > tos 0x00, ttl 64, length 74, checksum 0xc96f > > fragment id 0x0001 > > GRE 0x0001 > > 00:00:07:119802: ethernet-input > > IP4: 02:01:00:00:ff:02 -> 02:fe:39:17:74:65 > > 00:00:07:120048: ip4-input > > GRE: 2.2.2.2 -> 172.16.1.1 > > tos 0x00, ttl 64, length 74, checksum 0xc96f > > fragment id 0x0001 > > GRE 0x0001 > > 00:00:07:120113: ip4-lookup > > fib 0 dpo-idx 5 flow hash: 0x00000000 > > GRE: 2.2.2.2 -> 172.16.1.1 > > tos 0x00, ttl 64, length 74, checksum 0xc96f > > fragment id 0x0001 > > GRE 0x0001 > > 00:00:07:120404: ip4-local > > GRE: 2.2.2.2 -> 172.16.1.1 > > tos 0x00, ttl 64, length 74, checksum 0xc96f > > fragment id 0x0001 > > GRE 0x0001 > > 00:00:07:120495: gre-input > > GRE: tunnel 0 len 74 src 2.2.2.2 dst 172.16.1.1 > > 00:00:07:120543: error-drop > > gre-input: unknown protocol > > > > all 50 packets printed in the packet trace share the same fate... > > > > Thanks, > > Klement > > > > Quoting Maciek Konstantynowicz (mkonstan) (2017-01-03 18:46:19) > > > > // Typed this email before the live discussion on vpp call just now - > > still sending it out :) > > Hello, After the previous ver of this thread went into a frenzy of emails > > and fixes in vpp make test code, > > I wanted to re-check the situation. > > And as it is a New Year, I’m not lazy anymore, and did run make test in > > both vpp branches :) > > vpp master branch works, stable/1701 does not.. > > 1. master > > Ran 65 tests in 90.838s > > OK (skipped=5) > > make[1]: Leaving directory `/home/maciek/src/vpp2/test' > > 2. stable/1701 > > ====================================================================== > > ERROR: GRE tunnel Tests > > Exception: Capture file did not appear within timeout > > ====================================================================== > > ERROR: GRE tunnel L2 Tests > > Exception: Capture file did not appear within timeout > > ====================================================================== > > ERROR: MPLS Local Label Binding test > > AttributeError: label > > ====================================================================== > > ERROR: MPLS label imposition test > > IndexError: Layer [IP] not found > > ====================================================================== > > ERROR: MPLS label swap tests > > AttributeError: label > > ====================================================================== > > ERROR: MPLS Tunnel Tests > > ---------------------------------------------------------------------- > > IndexError: Layer [IP] not found > > Ran 64 tests in 59.980s > > FAILED (errors=6, skipped=5) > > make[1]: *** [test] Error 1 > > make[1]: Leaving directory `/home/maciek/src/vpp2/test' > > make: *** [test] Error 2 > > Fix? > > -Maciek > > > > On 12 Dec 2016, at 16:19, Maciek Konstantynowicz (mkonstan) > > [4][13]<[1]mkons...@cisco.com> wrote: > > Hello, Does anyone know if vpp make test is back on track to be ready to > > be used for vpp make verify jobs on a per patch basis? > > Being lazy I know - cause I could run it myself :) > > -Maciek > > > > References > > > > Visible links > > 1. [5][14]mailto:mkons...@cisco.com > > > > _______________________________________________ > > csit-dev mailing list > > [[15]6]csit-...@lists.fd.io > > [7][16]https://lists.fd.io/mailman/listinfo/csit-dev > > > > > > _______________________________________________ > > csit-dev mailing list > > [[17]8]csit-...@lists.fd.io > > [9][18]https://lists.fd.io/mailman/listinfo/csit-dev > > > > References > > > > Visible links > > 1. [19]mailto:nra...@cisco.com > > 2. > [20]mailto:csit-dev-boun...@lists.fd.ioonbehalfofklementsekera-x(ksekera-pantheontechnologiesatcisco) > > 3. [21]mailto:csit-dev-boun...@lists.fd.ioonbehalfofksek...@cisco.com > > 4. mailto:[[22]1]mkons...@cisco.com > > 5. [23]mailto:mkons...@cisco.com > > 6. [24]mailto:csit-...@lists.fd.io > > 7. [25]https://lists.fd.io/mailman/listinfo/csit-dev > > 8. [26]mailto:csit-...@lists.fd.io > > 9. [27]https://lists.fd.io/mailman/listinfo/csit-dev > > > > References > > Visible links > 1. http://pastebin.com/uGAUREhK > 2. mailto:dwallac...@gmail.com > 3. mailto:ksek...@cisco.com > 4. mailto:mkons...@cisco.com > 5. mailto:nra...@cisco.com > 6. mailto:csit-...@lists.fd.io > 7. mailto:csit-...@lists.fd.io > 8. mailto:vpp-dev@lists.fd.io > 9. mailto:vpp-dev@lists.fd.io > 10. mailto:nra...@cisco.com > 11. > mailto:csit-dev-boun...@lists.fd.ioonbehalfofklementsekera-x%28ksekera-pantheontechnologiesatcisco%29 > 12. mailto:csit-dev-boun...@lists.fd.ioonbehalfofksek...@cisco.com > 13. mailto:[1]mkons...@cisco.com > 14. mailto:mkons...@cisco.com > 15. mailto:6]csit-...@lists.fd.io > 16. https://lists.fd.io/mailman/listinfo/csit-dev > 17. mailto:8]csit-...@lists.fd.io > 18. https://lists.fd.io/mailman/listinfo/csit-dev > 19. mailto:nra...@cisco.com > 20. > mailto:csit-dev-boun...@lists.fd.ioonbehalfofklementsekera-x%28ksekera-pantheontechnologiesatcisco%29 > 21. mailto:csit-dev-boun...@lists.fd.ioonbehalfofksek...@cisco.com > 22. mailto:1]mkons...@cisco.com > 23. mailto:mkons...@cisco.com > 24. mailto:csit-...@lists.fd.io > 25. https://lists.fd.io/mailman/listinfo/csit-dev > 26. mailto:csit-...@lists.fd.io > 27. https://lists.fd.io/mailman/listinfo/csit-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
