{"id":17149862,"url":"https://github.com/rickmark/pcapng_linktype_hardware","last_synced_at":"2026-01-05T06:49:11.016Z","repository":{"id":113227007,"uuid":"450659062","full_name":"rickmark/pcapng_linktype_hardware","owner":"rickmark","description":"A proposal for a SPI linktype for `libpcap`","archived":false,"fork":false,"pushed_at":"2022-01-21T23:47:27.000Z","size":7,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"main","last_synced_at":"2025-01-29T17:11:29.567Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/rickmark.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-01-21T22:35:43.000Z","updated_at":"2022-01-22T03:49:38.000Z","dependencies_parsed_at":null,"dependency_job_id":"1f58910d-3134-4b70-bcde-2ad156fb836e","html_url":"https://github.com/rickmark/pcapng_linktype_hardware","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rickmark%2Fpcapng_linktype_hardware","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rickmark%2Fpcapng_linktype_hardware/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rickmark%2Fpcapng_linktype_hardware/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rickmark%2Fpcapng_linktype_hardware/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/rickmark","download_url":"https://codeload.github.com/rickmark/pcapng_linktype_hardware/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245266939,"owners_count":20587452,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-14T21:34:19.323Z","updated_at":"2026-01-05T06:49:10.989Z","avatar_url":"https://github.com/rickmark.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# pcapng_linktype_spi\n\nA proposal for a SPI linktype for `libpcap`\n\n## Reason\n\nToday there are several network protocols covered by the standard pcapng format.  This is because the pcapng format was intended to serve as a generic encapsulation of interfaces, and the binary data passed to and from enpoints on that interface.  This led to the generic adoption of `pcapng` to begin to represent other protocols such as USB.  The proposal is to create a specified and standardized method of encapsulating other hardware protocols, the first of which being commonly used in many embedded systems today as SPI.  On top of SPI which is a generic serial link, a common usage is the JEDEC flash memory standard.  Because SPI lacks all of the required descriptors, the specification of this \"next layer protocol\" must often be explicitly specified.\n\n## Decision Points\n\n### Multiple Slave Devices\n\nSPI is a master to slave protocol, with the capability of using multiple CS (chip-selects) to specify the device to which the master speaks.  This implies that an \"interface\" in SPI packet capture parlence should be 1:1 with a master, and that there should be a reasonable number of devices specified by integer as to which device a transfer occurs.\n\nAn alternative would be to specify one interface per M/S pair.  This has the addtitional advantage of allowing the embedding of pairwise data in the interface record, but would loose critical data about how the links inter-relate.\n\nA final design possability is the one interface per master, embedding N slave details in the interface.\n\n### Block Type - `BLOCK_LINK_TOPOLOGY`\n\nThis might best be represented by a new block type of `BLOCK_LINK_TOPOLOGY` - it would include some amount of standard data about if the link is 1:1, 1:many or many:many, if the link is up or down, if the link supports resets or state changes, if the link is full/half duplex or if that can be changed, if the link has the ability to transition speeds or encodings.  The block would also encapsulate a namespace of options specific to the LINKTYPE for which it is related.  For SPI this is a great place to put any \"next layer protocol\" data like JEDEC as that is M/S link specific.\n\nThis block type would be useful in other contexts like `LINKTYPE_ETHERNET` by signaling STP/RSTP (spanning tree), ARP table, or port change on a switch which is recording this capture.  The block should be generically useful for signaling topology information passing by the interface.  This differes from a name resolution block as it doesnt enrich a identifier but indicates the correlated identifiers to an interface.\n\nIt seems reasonable to make the assumption that all master slave relationships are fixed for the span of a transfer.\n\n### Handling Link Reset and Speed Changes\n\nThe RESET line allows a M/S to transition back through initial state.  This as well as SPI =\u003e Dual / Quad SPI changes should be logically captured as link level events, but are not themselves particularly interesting as the frames captured (one can almost think of RESET as a side channel to the actual transfers and lacks a way to repressent as an octet stream).\n\nThis seems to be an unhandled case of pcapng itself.  A proposal would be to create a new block type for `BLOCK_LINK_CHANGE` that would allow resets, speed changes etc to be sideband data to the packet frames.  The SPI format would plumb through some relevent data (e.g. SPI/Dual/Quad) in every EPB as to free the readers from having to maintain a state machine to process these events.\n\nIt occurs that `LINK_CHANGE` should incude a `link_id` which would correlate to `BLOCK_LINK_TOPOLOGY` allowing for the passing of changes for links other then the primary one.\n\n## Transfer Frames\n\nEach transfer frame should include direction/target, SPI/DualSPI/QuadSPI, timing, clock rate (average/skew), and raw data.  They should also include a monotonic increasing value indicating number of resets (so that each stream of transfers can be correlated.\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frickmark%2Fpcapng_linktype_hardware","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frickmark%2Fpcapng_linktype_hardware","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frickmark%2Fpcapng_linktype_hardware/lists"}