Applayer Detect protocol only one direction

I am running suricata 6.0.4 RELEASE and I keep getting the following alert when capturing from a network interface:

04/03/2022-20:41:59.670054 [**] [1:2260002:1] SURICATA Applayer Detect protocol only one direction [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 192.168.1.19:56069 -> 192.168.1.43:7000

I captured the traffic to a PCAP file via pcap-log and as far as I can tell it contains both directions:

1 0.000000 a8:20:66:46:06:8e → 3c:22:fb:ed:e6:da ARP 60 Who has 192.168.1.43? Tell 192.168.1.19

2 0.000002 192.168.1.19 → 192.168.1.43 TCP 78 56069 → 7000 [SYN, ECN, CWR] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=627513347 TSecr=0 SACK_PERM=1

3 0.000059 3c:22:fb:ed:e6:da → a8:20:66:46:06:8e ARP 42 192.168.1.43 is at 3c:22:fb:ed:e6:da

4 0.000357 192.168.1.43 → 192.168.1.19 TCP 78 7000 → 56069 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64 TSval=1724658650 TSecr=627513347 SACK_PERM=1

5 0.003264 192.168.1.19 → 192.168.1.43 TCP 66 56069 → 7000 [ACK] Seq=1 Ack=1 Win=131712 Len=0 TSval=627513388 TSecr=1724658650

6 0.003265 192.168.1.19 → 192.168.1.43 TCP 107 56069 → 7000 [PSH, ACK] Seq=1 Ack=1 Win=131712 Len=41 TSval=627513388 TSecr=1724658650 [TCP segment of a reassembled PDU]

7 0.003317 192.168.1.43 → 192.168.1.19 TCP 66 7000 → 56069 [ACK] Seq=1 Ack=42 Win=131712 Len=0 TSval=1724658654 TSecr=627513388

8 0.022540 192.168.1.43 → 192.168.1.19 TCP 1514 7000 → 56069 [ACK] Seq=1 Ack=42 Win=131712 Len=1448 TSval=1724658673 TSecr=627513388 [TCP segment of a reassembled PDU]

9 0.022618 192.168.1.43 → 192.168.1.19 TCP 279 7000 → 56069 [PSH, ACK] Seq=1449 Ack=42 Win=131712 Len=213 TSval=1724658673 TSecr=627513388 [TCP segment of a reassembled PDU]

10 0.024956 192.168.1.19 → 192.168.1.43 TCP 66 56069 → 7000 [ACK] Seq=42 Ack=1662 Win=130048 Len=0 TSval=627513409 TSecr=1724658673

11 0.024958 192.168.1.19 → 192.168.1.43 TCP 66 56069 → 7000 [FIN, ACK] Seq=42 Ack=1662 Win=131072 Len=0 TSval=627513409 TSecr=1724658673

12 0.025014 192.168.1.43 → 192.168.1.19 TCP 66 7000 → 56069 [ACK] Seq=1662 Ack=43 Win=131712 Len=0 TSval=1724658675 TSecr=627513409

13 0.025112 192.168.1.43 → 192.168.1.19 TCP 66 7000 → 56069 [FIN, ACK] Seq=1662 Ack=43 Win=131712 Len=0 TSval=1724658675 TSecr=627513409

14 0.027227 192.168.1.19 → 192.168.1.43 TCP 66 56069 → 7000 [ACK] Seq=43 Ack=1663 Win=131072 Len=0 TSval=627513411 TSecr=1724658675

When I feed the captured PCAP file to suricata via -r option, the alert doesn’t get logged in the fast.log even though the stats.log shows:

detect.alert | Total | 1

Any idea why the alert gets triggered in the first place and why the same alert is not logged when reading the packets from the PCAP file?

Can you share your config and more details about your setup?
Could be related to the capture method.
Also add the stats.log

I run Suricata on MacOS:

# suricata -i en6 -F filter.bpf -v

filter.bpf limits the traffic to a single IP address:

host 192.168.1.19

fast.log:

04/06/2022-11:45:39.142492 [**] [1:2260002:1] SURICATA Applayer Detect protocol only one direction [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 192.168.1.19:64527 -> 192.168.1.178:7000

Attached is the stats.log and a PCAP file corresponding to the stats.log.
Archive.zip (3.1 KB)

Alright I can reproduce it with your pcap, would you mind reporting this on our redmine?

Do you know more about what type of traffic it should be? From the log output Suricata seems to recognize it as http but can’t completely construct it. If you look into the EVE output you see event_type http.

I have submitted a bug on redmine (Bug #5247: Applayer Detect protocol only one direction - Suricata - Open Information Security Foundation).

It seems to be AirPlay traffic. It uses TCP port 7000 for the RTSP protocol to gather information from the AirPlay server.

RTSP protocol is not supported by Suricata indeed even if the beginning looks like HTTP