nus-snl / p4-traffictool Goto Github PK

• Support using both long options and short options. The sequence of options should be pretty flexible.
• It should automatically detect the P4 language version (P4_14 vs P4_16). See Barefoot Academy's p4_build.sh script for ideas on this.
• Interactive Mode: The top-level script should run the interactive mode by default and ask all missing options showing their default values. If certain options are specified by the user, it should not ask again for them, but only ask for remaining options. If the top-level script invocation specifies all options (especially the targets), then interactive mode should not be triggered.

The generated Wireshark plugin code is incorrect for the perc1 header. Also, possible issues with generated Scapy code for the guess_payload_class() function of the perc1 header. The expected next hop is based on the ACK field and later on the BOS field. This is sort of a multi-field transition but not expressed so by the P4 programmer. Common programmer expectation is to base the transitions between the PERC header based only on the BOS field. The ACK field check is only for other dataplane processing purposes.

Result: Wireshark doesn't parse the packet beyond perc1 header.

Attachments in zip:

1. perc.p4: source P4 program
2. perc_parser.pdf: parser graph for the P4 program
3. perc_sample.pcap: sample pcap file contain PERC packets

perc_issue.zip

Dockerfile is already written. Two main tasks:

• Integrate properly with Dockerhub with automated builds
  Currently the tool appears on Dockerhub at this url. On Docker hub, the organization is sysnetlab while the machine user is sysnetlabadmin (linked to [email protected]). Also, the Github account used by Dockerhub is nussnl-docker (linked to [email protected]).

• Figure out a way to invoke the tool from a simple single line Docker command along with the input file and options (if any). Passing arguments while instantiating a Docker container and doing volume mounting+copying is the challenge.

master and develop have diverged in their git histories, with conflicts on merge attempts.

Since they seem to differ in docs/ at master, and more code in develop, would it be better to migrate docs/ to develop and make develop the new master

The biggest impediment in formally announcing the tool is the lack of confidence in its correctness. The tool has not been tested extensively for all the backends that it supports with a variety of P4 programs. We can find more public domain P4 programs here for testing.

Possibly also need to craft custom P4 programs to test handling of corner cases.

For the generated Scapy code, replace tabs with spaces. Scapy isn't happy when you copy-paste that code into Scapy's commandline terminal.

The tool runs into errors for PcapPlusPlus and Scapy backends when the defined parser in P4 program contains a default transition to the next parser state. The type of error varies depending on how the default transition is:

1. Default transition via a transition select block: In this case the error is TypeError: 'NoneType' object has no attribute '__getitem__'

2. Default transition which is directly specified like transition parse_next_state: In this case the error is KeyError: u'bos'. Here the p4c compiler would merge the parser states and the said transition actually doesn't exist. This is a right thing to do from P4 perspective, but it confuses the tool.

Attached zip contains:

1. perc-tcp-options.p4: by default it is a working P4 file. Follow comments around "BUGGY Line #⁠1" and "BUGGY Line #⁠2" to reproduce the two error respectively. Reproduce only one error at a time.
2. graphs/ParseGraph-works.pdf: a working parser graph
3. graphs/ParseGraph-bug_line1.pdf: parser graph corresponding to the first error.
4. graphs/ParseGraph-bug_line2.pdf: parser graph corresponding to the second error.

perc-tcp-options.zip

Currently what we are doing in the top-level bash script p4-traffictool.sh is very weird - we are invoking the backend p4c-bm2-ss first and if it fails then we are invoking the frontend p4c. Ideally speaking we do NOT need to invoke any backend for our purpose. We only need the header and parser definitions as per standard P4_16.

• Try and use only the p4c frontend by default. No backends need to be invoked.
• If the above works correctly, then with proper addition of an include path, the p4c frontend should be able to handle code written for any architecture (NetFPGA, Tofino). See how microP4 does it. In fact, Barefoot's proprietary compiler uses the open-source p4c compiler frontend. This should take away a lot of pain in using the tool for programs written for Barefoot Tofino and avoid workarounds like --only-headers.

Index 1 of an edge in the graph is of type List. See common.py#L111, but is replaced with a string in some cases in GenTrafficScapy.py#L357

Incidentally, this does not generate a bug, since the cases in which it is replaced with a string - it is interpreted as a string later on, and as a List otherwise.

Not a good practice. Is this worth fixing @rajkiranjoshi ?

Here are some pointers that need to be looked into and corresponding information added to SimilarTools.md:

1. BB-Gen: https://p4.org/assets/P4WS_2018/3_BB-Gen_Abstract2.pdf
2. BMAcc: https://www.dpdk.org/wp-content/uploads/sites/35/2018/06/Accelerating-P4-based-Dataplane-with-DPDK.pdf
3. Enabling P4 in DPDK: https://youtu.be/uI29_q-SoPU?t=1400
4. T4P4S: https://github.com/P4ELTE/t4p4s

When p4c compilation fails, do display the errors. For a small syntax error like missing a semi-colon, the user is left clueless as to what went wrong.

Now there are PPA packages for p4c and behavioral model available for Ubuntu. So for Ubuntu users, we can simplify this task of having to build and install all the dependencies. See the mailing list post here.

./install.sh adds an alias to p4-traffictool.sh within the (downloaded) source code.

Ideally, it should copy the source code and p4-traffictool.sh to /bin, similar to what a .deb package would do.

• Design Rehaul: The current website isn't that great looking. Look at pcapplusplus.github.io OR erpc.io for a better inspiration.
• On both Github main page and website, the link to the poster's extended abstract should appear upfront. Can appeal modestly to cite our poster if they have benefited from the tool's use. Maybe like this?
• Current Readme.md shows some table at the top in master, but the same is not visible in develop. So I am sure we can get rid of the same while having all the website related stuff properly organized under docs/.

When the top-level bash script is invoked with a non-existent P4 file path, the file is not checked for existence and the p4c compiler is invoked leading to failing of the p4c compiler.

Our team try to introduce p4-traffictool into our p4 traffic test unit. However, when we try to use p4-traffictool to generate scapy code base on our p4 code, the tool says it cannot generate scapy.

Seems like this is an IOError in GenTrafficScapy.py, so I add traceback func in that part of code and get this

Looks like it try to open a temp file, but turns out some wrong happened, I think it is caused by DESTINATION variable received wrong value?