| commit | b98c6ee8cdc83a4fced26938b0e9c0a350f0ff7b | [log] [tgz] |
|---|---|---|
| author | Andrew Jeffery <andrew@aj.id.au> | Thu Mar 28 17:38:54 2019 +1030 |
| committer | Andrew Jeffery <andrew@aj.id.au> | Tue Apr 02 04:04:33 2019 +0000 |
| tree | 110ff776dce11e932c0be594aef444eb78642664 | |
| parent | 761484a11d7027bea1648cca28f3f20a2b2a4f4f [diff] |
dbus-pcap: A DBus packet parser and matcher for pcap captures busctl(1) offers a `capture` option that's useful for recording DBus traffic on a system. The resulting pcap can be loaded into wireshark where it can be analysed, but the wireshark dissector has (had?) limitations (only parsed header fields and not the body of the packet). dbus-pcap will parse the pcap using scapy to read the packets, then implements a dbus wire-format dissector with DBus match expression support to filter the packet stream according to the supplied match rules. Here's an example invocation that extracts IPMI transport messages during the boot process of an OpenPOWER OpenBMC system: > $ ./dbus-pcap witherspoon-boot.pcap "type='signal',path='/org/openbmc/HostIpmi/1'" > > [[[108, 4, 1, 1, 14, 9982], [[1, "/org/openbmc/HostIpmi/1"], [2, "org.openbmc.HostIpmi"], [3, "ReceivedMessage"], [8, "yyyyay"], [7, ":1.14"]]], [206, 58, 0, 90, [4, 56, 28, 19, 2, 0]]] > [[[108, 4, 1, 1, 14, 9984], [[1, "/org/openbmc/HostIpmi/1"], [2, "org.openbmc.HostIpmi"], [3, "ReceivedMessage"], [8, "yyyyay"], [7, ":1.14"]]], [207, 58, 0, 90, [4, 57, 125, 16, 2, 0]]] > [[[108, 4, 1, 1, 14, 9986], [[1, "/org/openbmc/HostIpmi/1"], [2, "org.openbmc.HostIpmi"], [3, "ReceivedMessage"], [8, "yyyyay"], [7, ":1.14"]]], [208, 58, 0, 90, [4, 58, 134, 17, 2, 0]]] The messages are emitted in JSON form and can be parsed by `jq`. Zero or more DBus match expressions can be provided. A match occurs when the current packet matches all rules in an expression, for any expression supplied on the commandline. If no expressions are provided then all packets are matched by default. Neither argN nor namespace match rules are supported in this initial patch. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Change-Id: I3130426451207f556f33a17d540d6b32794e8503
The goal of this repository is to collect the two-minute hacks you write to automate interactions with OpenBMC systems.
It's highly likely the scripts don't meet your needs - they could be undocumented, dysfunctional or utterly broken. Please help us improve!
Then this repository aims to be the default destination for your otherwise un-homed scripts. As such we are setting the bar for submission pretty low, and we aim to make the process as easy as possible.
openbmc-events: Query error events on the target serveropenbmc-sensors: Query sensors on the target serveropenbmc-sfw: Manage host and BMC firmware images on the target serveropenbmctool: A general purpose tool for user interactions with OpenBMCpretty-journal: Convert journalctl's 'pretty' output to regular outputupload_and_update: Upload a tarball to TFTP server and update BMC with itnetboot: Painless netboot of BMC kernelsobmc-gerrit: Automagically add reviewers to changes pushed to Gerritreboot: Endlessly reboot OpenPOWER hoststracing: Enable and clean up kernel tracepoints remotelywitherspoon-debug: Deploy the debug tools tarball to Witherspoon BMCscla-signers: Check if a contributor has signed the OpenBMC CLAopenbmc-autobump.py: Update commit IDs in bitbake recipes to bring in new changesPlease use gerrit for all patches to this repository:
Do note that you will need to be party to the OpenBMC CLA before your contributions can be accepted. See Gerrit Setup and CLA for more information.
So long as your patches look sane with a cursory glance you can expect them to be applied. We may push back in the event that similar tools already exist or there are egregious issues.
We don't ask for much, but you need to give us at least a Signed-off-by, and put your work under the Apache 2.0 license. Licensing everything under Apache 2.0 will just hurt our heads less. Lets keep the lawyers off our backs. ^
^Any exceptions must be accompanied by a LICENSE file in the relevant subdirectory, and be compatible with Apache 2.0. You thought you would get away without any fine print?
There's no standard way to install the scripts housed in the here, so adding parts of the repository to your PATH might be a bit of a dice-roll. We may also move or remove scripts from time to time as part of housekeeping. It's probably best to copy things out if you need stability.