Dot1Q obscuring underlying CiscoDiscovery/CiscoDiscoveryInfo
- Dominant language
- Go
- Stars
- 6.8k
- Forks
- 1.2k
- PR merge metrics
- No merged PRs in 30d
Description
I hope this is the right place to pose my question; I searched for a forum for asking How Do I questions, but couldn't seem to find one.
I'm currently using `gopacket` to capture network discovery packets. I've been able to successfully collect `LLDP` information across our environments, but `CDP` has proven to be a bit trickier. In essence what I've tried is the following:
- verify packet existence using `tcpdump` (with filter `ether[20:2] == 0x2000`)
- make a packet source using `gopacket/pcap` and a BPF (identical to what is used in my `tcpdump`tests)
- capture a single packet
- parse the appropriate struct as:
```
cdpL := p.Layer(layers.LayerTypeCiscoDiscoveryInfo)
if cdpL == nil {
return r, errors.New("nil CDP Info layer")
}
cdi, ok := cdpL.(*layers.CiscoDiscoveryInfo)
if !ok {
return r, errors.New("cannot parse CDP Info layer")
}
if cdi == nil {
return r, errors.New("no packets found")
}
```
Using packet captures from `tcpdump` in both the working and failing environments I created some unit tests that use this `testdata` to verify behavior. After digging around a bit I noticed the main difference in the packets captured in these environments is that the broken one has a `Dot1Q` layer, as:
```
Ethernet > Dot1Q
```
vs the working environment which has:
```
Ethernet > LLC > SNAP > CiscoDiscovery > CiscoDiscoveryInfo
```
My question is this: upon visual inspection of the bytes in the top-most layer payload in each case does eventually have something that looks like a `CDP` packet in it. My confusion stems from a few things:
- What's the right approach to get past the `Dot1Q` layer? I've tried searching to see if I could pass in a sub-slice into some decode method, but I failed to find such a thing. Am I missing something obvious? I feel like if I do the parsing myself I've jettisoned 50% of the utility of this package, but that is the next thing I'm going to try.
- `tcpdump` doesn't seem to be confused by the `Dot1Q` layer; do I have something misconfigured?
Sadly I don't feel comfortable sharing any more of the code I've written, but am happy to answer questions to get to the bottom of this.
Thanks for any pointers here.
Contributor guide
Assessment
This issue has not been assessed yet.