Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DICOM parser fails to emit IP address information #4

Open
ransford opened this issue Feb 13, 2019 · 1 comment
Open

DICOM parser fails to emit IP address information #4

ransford opened this issue Feb 13, 2019 · 1 comment
Labels
bug Something isn't working
Milestone

Comments

@ransford
Copy link
Contributor

Describe the bug
IP address information should be included in DICOM message summaries.

$ tapirx -pcap testdata/dicom_arq_4_get_bogus_local.pcap -verbose | jq
{
  "ipv4_address": "",
  "ipv6_address": "",
  "open_port_tcp": "",
  "connect_port_tcp": "",
  "mac_address": "40:00:00:00:40:00",
  "identifier": "testclient",
  "provenance": "DICOM",
  "last_seen": "2019-02-13T12:55:40.737102-08:00",
  "client_id": ""
}

... should look similar to

$ tapirx -pcap testdata/HL7-ADT-UDI-OBX.pcap -verbose | jq
{
  "ipv4_address": "10.0.0.155",
  "ipv6_address": "",
  "open_port_tcp": "",
  "connect_port_tcp": "",
  "mac_address": "00:03:b1:b5:b6:48",
  "identifier": "Hospira Plum A+",
  "provenance": "HL7 OBX-18",
  "last_seen": "2019-02-13T12:56:04.895568-08:00",
  "client_id": ""
}

Platform (please complete the following information):

  • OS: [e.g., Windows 10, macOS 10.14.2, CentOS 7]
  • Output of tapirx -version: Tapirx 1.0.0-17-g9042a2b
  • Output of go version: go version go1.11.5 darwin/amd64
@ransford ransford added the bug Something isn't working label Feb 13, 2019
@ransford ransford changed the title DICOM parser fails to omit IP address information DICOM parser fails to emit IP address information Feb 13, 2019
@ransford
Copy link
Contributor Author

This specific problem is tickled only on loopback traffic, which doesn't use Ethernet framing. That's why it fails on the testdata data. The gopacket decoding stack we're using (see packet.go) pukes when it doesn't understand a layer, so after encountering the loopback layer, it doesn't find the IP or TCP layers.

It's easy to make a decoding stack that includes a loopback decoder below other layers, but less easy to set up a decoding stack that is alive to Ethernet and loopback packets at once, since we currently hard-code the decoding stack's first layer to Ethernet.

Options to fix this include:

  • When loading a stream (either live or pcap) for decoding, if the first frame is loopback, set up the decoding stack with loopback at the bottom layer, and then ignore Ethernet layers from then on.
  • Figure out how to assemble a gopacket decoding stack that branches on ethernet vs. loopback, similar to how it branches on IPv4 vs. IPv6 when the decoding stack includes both. May involve submitting a PR to gopacket, but unsure as I type this.

How we'll know when we're done: we can correctly extract IP address information for localhost from testdata/*dicom*.pcap, and also from other pcap files that include DICOM traffic not to/from localhost.

@ransford ransford added this to the 1.1.0 milestone Feb 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant