Suricata

more smb example:

{
  "timestamp": "2019-02-15T19:26:50.117953+0100",
  "flow_id": 556954253130233,
  "pcap_cnt": 52,
  "event_type": "smb",
  "src_ip": "172.16.10.97",
  "src_port": 49892,
  "dest_ip": "172.16.10.2",
  "dest_port": 445,
  "proto": "TCP",
  "smb": {
    "id": 14,
    "dialect": "NT LM 0.12",
    "command": "SMB1_COMMAND_NT_TRANS",
    "status": "STATUS_SUCCESS",
    "status_code": "0x0",
    "session_id": 2051,
    "tree_id": 4100
  },
  "ether": {
    "src_mac": "00:08:02:1c:47:ae",
    "dest_mac": "a4:1f:72:c2:09:6a" 
  }
}
{
  "timestamp": "2019-02-15T19:26:49.915961+0100",
  "flow_id": 556954253130233,
  "event_type": "smb",
  "src_ip": "172.16.10.97",
  "src_port": 49892,
  "dest_ip": "172.16.10.2",
  "dest_port": 445,
  "proto": "TCP",
  "smb": {
    "id": 9,
    "dialect": "NT LM 0.12",
    "command": "161",
    "session_id": 2051,
    "tree_id": 4100
  },
  "ether": {}
}

Can you turn these examples in to SV tests?

Of course, will do that

So we narrowed it down to two issues, the first one is rather simple:

The `EveAddCommonOptions` is missing for dcerpc, which is also true for mqtt, quic, pgsql in that version. But this is fixed due to the changes in version 7.0.0. So now all protocols should add the EVE additional information like ethernet and community id (if enabled).

The second one for the smb and http pcap are the same issue with 7.0 but is a bit more complicated. The packets all pass `DecodeEthernet` correctly and the ethernet data is there but once they need to be written, some of those run into `CreateJSONEther` with `p->ethh` being `NULL` which shouldn't be since it was present at the decoding state.

Also note that tunneled traffic exhibits similar behavior.

When TmThreadsSlotVarRun runs the Decode* routines to parse a packet and encounters a
tunnel packet, it runs DecodeGRE().

It then calls PacketTunnelPktSetup() to parse the inner packet and calls PacketEnqueueNoLock().
In doing so, the newly enqueued packet has no p->ethh.

This causes CreateJSONEther() to fail.

But in this case, I take it that we can't do anything about it given the nature of tunneling?
Or does it still make sense to copy over the ethh from the parent packet?

Juliana Fajardini Reichow wrote in #note-8:

Hey @Sascha Steinbiss would you like to take this one?

Hmm, I am not sure I can currently dedicate the appropriate time to this right now. But it sounds like an attractive learning opportunity to dive into the way packets are passed through Suricata. So... if this needs to be done in time for a release, I'd rather leave it to someone else. If there is time, I might take it.

The current timeline for 8.0.0-beta1 is June 4th, would that be doable considering what you've said? If you think it is, we'd be happy to have you work in it! :)

Unlikely, sorry. I'd rather focus on #5912 as I don't have to dive into unknown code to fix it (and I also kind of told Andreas that I would do it ;))

Sascha Steinbiss wrote in #note-11:

Unlikely, sorry. I'd rather focus on #5912 as I don't have to dive into unknown code to fix it (and I also kind of told Andreas that I would do it ;))

That's fair! Thanks for working on the other task, and for being responsible about the time you have at the moment. :)

Sascha Steinbiss wrote in #note-11:

Unlikely, sorry. I'd rather focus on #5912 as I don't have to dive into unknown code to fix it (and I also kind of told Andreas that I would do it ;))

Hey, I messed up when mentioning the release date for 8.0.0-beta1! It's for 2024! Not put pressure in changing your answer, but because my prior message doesn't make a lot of sense, without that part >__<' Sorry about this confusion...

Hi, is anyone working on this ticket? If not, may I pick it up?

At least I am not. I'd say go for it? :)

Joyce Yu wrote in #note-14:

Hi, is anyone working on this ticket? If not, may I pick it up?

What Sascha said, and thanks for contributing to Suri! :) I've granted you developer role, so you should be able to claim the ticket, now.