IAM ====== Name: Packet Capture for OpenSolaris Submitter: Darren Reed Owner: Garrett D'Amore Intern: Darren Reed Interest: Status: meeting scheduled 04/29/2009 Exposure: open Comment: SUMMARY ======= ISSUES ====== issues for Inception (04/29/2009): seb-1 On the IPNET version bump: Given that the feature has only been out there for a few OpenSolaris builds and that the only known consumer of DLIOCIPNETINFO is the snoop program, preserving backward compatibility is not important. Bumping the version number is fine, but I think it would be sufficient to reject DLIOCIPNETINFO ioctls that select version 1. seb-2 Related to seb-1, given that we'll have no applications that support both version 1 and version 2 (why would we?), I don't believe that you need a dl_ipnetinfo_v2_t structure. A single dl_ipnetinfo_t structure representing the "current" version should be sufficient, cleaner, and simpler. seb-3 Also related to seb-1, I don't think you should go out of your way to keep support for the parsing of version 1 IPNET headers in snoop, but that's obviously your call. djr In answer to seb-1 through seb-3, if PSARC is happy for version 1 IPNET headers to be "obsolete" and unsupported, I'm happy to remove it from existance. Given that version 1 was publicly documented I opted to take the safe path. seb-4 On the new DLT_LOOP_SOLARIS DLT type: Given that this DLT type represents an IP pseudo data-link type for observability of all IP interfaces (and not just loopback, unless I'm misreading the spec), I'm uncomfortable with the of the chosen name for this type. Would something like DLT_IPNET not be more appropriate? djr If you feel strongly enough about it, I'm happy to use that name. seb-5 "struct ifreq" is Obsolete, yet it is used by /dev/bpf ioctls. Should these not be using "struct lifreq" instead? djr Compatibility. Software (ie libpcap) using BPF is currently only written using "struct ifreq". Additional definitions to support "struct lifreq" could be added. ===========> include definitions seb-6 How do BIOCSETIF callers select whether the desired observability point is to be at the MAC layer or the IP layer? djr By default the MAC layer is selected and packets from it are presented. This is in part an implementation artifact as it is the first "registration" of an interface in BPF that becomes the default. What this means is that when a device attaches to the MAC layer via mac_register(), it gets inserted in BPF. Later when plumb'd into IP, the IPNET bit is inserted into BPF. seb-7 Are all ifreq fields other than ifr_name ignored when processing BIOCSETIF? djr Yes. seb-8 I don't understand the implications of the Project-Private 32-bit ioctls. Can a 32-bit program not set a BPF filter when running on a 64-bit kernel using Committed interfaces? djr The structure names of the 32bit-format structures are Project Private. They are only used by the kernel module to get the correct layout of data from applications, allowing a 64bit kernel to work with a 32bit application. seb-9 What are the interactions between /dev/bpf and zones? Logically there is probably a restriction of datalinks that BIOCSETIF will allow from a non-global zone, but I didn't find that in the spec (other than the bit about IPNET in shared-stack zones). seb-10 PF_PACKET is about more than "packet capture", it's a full-fledged socket API for interacting with the link-layer. DLPI overlaps this functionality almost exactly. The Background section implies that this project (and DLPI) is just about "packet capture", which is confusing. seb-11 Given that PF_PACKET depends on BPF for filtering, what interfaces does PF_PACKET use from what is being delivered by the BPF "case" (I realize it's not a separate case, but it probably should be)? Does BPF provide some sort of kernel-level API for packet filtering that isn't described in this case? A diagram might help. djr PF_PACKET uses the following interfaces from BPF: struct bpf_program32 struct bpf_program struct bpf_insn bpf_validate() bpf_filter() seb-12 Exclusive-stack zones _do_ have the net_rawaccess privilege by default, contrary to what's described in the "Zones" section of pfp-psarc.txt. I don't think this has any impact on the architecture described, however, since I don't believe that lx branded zones have that privilege, and so PF_PACKET still won't work from lx branded zones. djr Correct, LX branded zones don't have that privilege. seb-13 It doesn't make sense to me to tie IP-layer interface indices to PF_PACKET (see sll_ifindex, mr_ifindex, etc.). IP interfaces are only tangentially related to the objects that PF_PACKET ineracts with, which are datalinks. Also, one should be able to use PF_PACKET over a link even when IP isn't plumbed on that link. Of course, if the SIOCGIFINDEX ioctl on PF_PACKET sockets doesn't return the IP "interface index", then that would address my concern. What does it return? djr The same Id as BPF uses: the link ID from DLS. On a related note, I think a more serious and general problem exists for OpenSolaris (not specifically this project) when it comes to porting Linux or BSD networking functionality. On these operating systems, the "interface index" represents the "interface" at all layers of the stack where it exists. On Solaris, it is only a concept at the IP layer, and this creates incompatibilities as described here. Perhaps advice needs to be doled out to investigate and address this for Solaris. seb-14 What flags could possibly be gotten or set using SIOC*IFFLAGS on a PF_PACKET socket? djr The only one that is currently checked for is IFF_PROMISC. seb-15 What is the definition of "host" for PACKET_HOST and PACKET_OTHERHOST? I believe that these sll_pkttype values are ill-conceived and ill-defined (as you already know). djr The "Linux" definition, in this instance, references to the interface in question. seb-16 There is no discussion of privileges in the BPF materials. Given how deficient DLPI is in this area, this case would be a great place to introduce some more fine-grained privileges for observability (beyond "net_rawaccess"). For example, "net_observability" was introduced a little while ago. Can that be leveraged? djr BPF (also) requires "net_rawaccess". Because the definition of net_observability is suggested to be for /dev/ipnet only, it isn't clear if it should be used by bpf. THE NEXT STEP ============= BPF must be accesible in shared zones & documented in case material. The behavior of BCF with Mac Layer & IP ... needs to be researched and documented. Mac layer - document how it is being used by project team. TCR - define shared zones much more clearly.