Randomly stopping decode / processing

[xerxes]

Warning: EQPacket: Unhandled net opcode 5200, stream client-zone, size 39
Info: Filtering packets on device eth0
Debug: PCAP Filter Set: udp[0:2] > 1024 and udp[2:2] > 1024 and host 192.168.100.10 and ether proto 0x800 and not broadcast and not multicast
Info: EQPacket: SessionDisconnect detected, awaiting next zone session,  pcap filter: EQ Client 192.168.100.10

Had to camp out and back in to get things working again.

[cn187]

Do you have session tracking turned on or off?

[xerxes]

It was off at the time.

[cn187]

Thanks. That's what I had assumed based on the log snippet, but wanted to verify.

Basically, there was some non-EQ traffic that matched the capture filter, and one packet happened to look to SEQ like a session disconnect.

With session tracking enabled, there's an additional check to validate that the session ID in the disconnect packet matches the current session ID that SEQ knows about. So the chance of it disconnecting due to a non-EQ packet is low.
But without session tracking, it just looks for the disconnect opcode. If an arbitrary non-EQ packet happens to have the disconnect opcode in the correct place, it's interpreted as a disconnect packet and treated accordingly.

I *think* the size of the disconnect packet is pretty consistent, so I might be able to add a size check for the disconnect packet to help reduce the chance of this happening when session tracking isn't used. But using session tracking is the best way to all but eliminate it (even with session tracking, there's theoretically a chance of it happening, but it's extremely unlikely).

That said, I know that in the past, session tracking has caused problems for you with your setup, so I understand why you wouldn't want to use it. Though, I would be interested to know if you've tried using it since I made all the capture changes that released with 6.4.0. I think some of the changes I made should have improved the issues were seeing.

Anyway, I'm not sure when I'll get to it (life is super busy right now), but I'll look into adding a size check for the disconnect packets, and see if there's anything else I can come up with that might also help.