mirror of
https://github.com/zeek/zeek.git
synced 2025-10-03 07:08:19 +00:00
9b0d525728
Conceptually, a TCP-based application analyzer should not need any knowledge about the underlying TCP analysis; it's supposed to just process its reassembled input stream as it's handed over. But our analyzers break that assumption at a few places because sometimes knowledge about the TCP state of the connection can be helpful for heuristics. This is fine as long as there actually *is* a TCP parent analyzer available. Sometimes, however, there isn't: if the payload stream is encapsulated inside another application-layer protocol, the semantic link to TCP is broken. And if the outer connection is even UDP, then we don't have a TCP analyzer at all. We didn't handle this situation well so far. Most analyzers needing TCP state would just crash if there's no TCP analyzer (in debug mode with an `assert`, in release mode with a null pointer deref ...). Only HTTP did the right thing already: check if TCP is available and adapt accordingly. We know extend that check to all other analyzers as well: all accesses to `TCP()` are guarded, with reasonable defaults if not available. It's actually a pretty small change overall, which is evidence for how little this layering violation actually matters. The existing behavior is what's causing https://github.com/corelight/zeek-spicy-openvpn/issues/3. |
||
|---|---|---|
| .. | ||
| scripts | ||
| src | ||
| .btest-ignore | ||
| CMakeLists.txt | ||