You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Describe the bug
IP address information should be included in DICOM message summaries.
... should look similar to
Platform (please complete the following information):
tapirx -version
:Tapirx 1.0.0-17-g9042a2b
go version
:go version go1.11.5 darwin/amd64
The text was updated successfully, but these errors were encountered: