_ipproto_to_str in pox.lib.packet.packet_utils.py

[bk2zsto]

I know expanding the list of IP protocols that can be string-ified is a hassle waiting to happen but wrote quick tool to generate the _ipproto_to_str list from the IANA website

https://github.com/bk2zsto/IANA_IP_Proto

[MurphyMc]

Hmm... do we know whether we can redistribute the IANA list? It seems like we might go the route of the OUI info which is to actually include the upstream source (the IANA CSV file in this case) directly in the repo and build the proto list from it at runtime. That way we update by just pulling the new CSV into the repo and not have to keep tweaking the code itself...

[bk2zsto]

If the IANA info is authoritative (as it shud be in the case of IP protos) then that makes alot of sense. I can follow up on the redist permission and a util module to encapsulate.

I know this issue was IP protos but it makes sense to try the same thing for ethertypes, yes? Unfortunately, it looks like IEEE is authoritative for this not IANA. Their info (http://standards.ieee.org/develop/regauth/ethertype/eth.txt) is not great (not easily parsable, the Wikipedia page has better info, etc.). I can try to find a machine-parsing-friendly source, check on redist, etc.

It almost makes sense to provide a Wireshark-esque "Decode as ..." option but not sure how to expose it to the user or if it would be worth their time to use. Slippery slope too: if the types are decoded, then there must be "dissectors" for them too?

Your original strategy of putting in the popular protos/types as static lists and letting ppl Google the rest may be the most practical (least code bloat). I just spotted a chance to actually use some of the Python I am trying to skill up on ;-)

[bk2zsto]

Updated https://github.com/bk2zsto/IANA_IP_Proto/blob/master/ipproto.py to maybe prevent wheel reinvention but still avoid a static table. Composes a table at runtime from socket.IPPROTO_* constants, then overlays the host system's protocols database (e.g. /etc/protocols) if available. Provides get(), getbyname() and dump(). Going to add some set*() methods to allow users to customize runtime configuration.

ethertypes are still on the outside looking in.

Trying to get up-to-speed on git and propose an integration into packet_utils but looking for feedback on the approach in the meantime

[MurphyMc]

I think ideally we'd also generate "constants" for these at runtime too, not just the string names (that is, generate xxx_PROTOCOL attributes for packet.ipv4 based on the same input). Especially in that context, I worry that pulling from the host system is a bad idea since it essentially makes the code sort of dependent on the host environment, and that including the list in the repo fixes this.

As far as the PR goes, this seems like it would fit nicely in ipv4 or maybe better yet into packet_utils, no? (Rather than a separate module.)

[bk2zsto]

Ah. UTSL. The "OUI route" makes sense now. I think there is value in delegating to socket.* and the host database but if you are already maintaining external files in the repo for eth OUIs, that ship has sailed. I agree the code logically belongs in packet_utils and the placement of the _load_oui_names method in pox/lib/addresses.py makes it clear how this shud work. Was worried about creating per-packet/constructor call overhead but _load_oui_names() only gets called when the module is imported. Updating PR

[bk2zsto]

new PR #101. Still unsure about how constant generation will work. Does that mean referring to the CSV and burning in the constants when the code is edited or somehow making the caller update their namespace with the return value from packet_utils.something()?

[bk2zsto]

[IANA #724103] re: CSV redistribution.

IEEE website contact form filled out re: the current state of their Ethertype registry, request for alternate format.

[bk2zsto]

Re: redist of IANA files. See also https://github.com/bk2zsto/pox/blob/dart/tools/getdatabases.py

From: Bikram Zesto II bk2zsto@gmail.com Date: Fri, Nov 8, 2013 at 3:39 PM To: iana@iana.org

Hi,

Working on a s/w project that displays textual representations of the protocol field in IP packets it receives. Wanted to include a copy of the

http://www.iana.org/assignments/protocol-numbers/protocol-numbers-1.csv

in the distro to ease runtime computation of this.

I am guessing since part of IANA's mission is to make these records public and get them used, there should be no problem with including them w/the s/w.

If this is OK, are there any terms/conditions that need to be considered?

Thanks,

bk

---

From: Amanda Baber via RT iana-questions@iana.org Date: Fri, Nov 8, 2013 at 4:34 PM To: bk2zsto@gmail.com

Hi Bikram,

The use of material from ICANN's IANA web site (www.iana.org) is permissible with the following conditions:

1. Provide attribution to the source, including provision of a URL so that users can find out the complete context if they choose;
2. The materials are used in context; You may not edit or selectively quote the material to make it false or misleading;
3. You do not use the materials in a way that implies ICANN sponsorship or approval of your work. This includes not reproducing the ICANN or IANA logos separate from where they may appear within the materials.

With the above conditions, you may use materials from ICANN's IANA site.

Best regards,

Amanda Baber IANA Request Specialist ICANN

---

From: Bikram Zesto II bk2zsto@gmail.com Date: Fri, Nov 8, 2013 at 6:51 PM To: iana-questions@iana.org

Amanda,

Thanks for the quick feedback. I guess there shud be a header in the file or a protocol-numbers-1.README file in the distro to this effect.

Does the appended cover what IANA needs?

Thanks,

bk

= = = BEGIN IANA HEADER ===

####### See http://www.iana.org/assignments/protocol-numbers for details ####### Permission to use this file does not constitute an endorsement of this software by IANA or ICANN

---

From: Amanda Baber via RT iana-questions@iana.org Date: Mon, Nov 11, 2013 at 3:57 AM To: bk2zsto@gmail.com

Hi,

That looks fine.

thanks, Amanda