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.

[xerxes]

Session tracking continues to cause issues. If it's enabled, it works fine when zoning multiple clients.

If I enter a new IP address to monitor, with Session Tracking enabled, and zone that new client, it does not pick up the stream. Nothing shows in the console. If I turn off Session Tracking and zone, nothing shows in the console.

However, if I select "Monitor Next EQ Client Seen" and zone, then it picks up immediately and starts working. I can then enable Session Tracking and zone and it continues to work.

There's some kind of funkiness with Session Tracking enabled and then switching to a new IP address to monitor. I multibox and sometimes want to check a zone and will send a different machine and need to flip between them.

[cn187]

When you say "nothing shows in the console" I assume you mean zoning-related stuff... You're getting the messages about "listening for client on IP address", right? (and if you have debug enabled, the pcap filter settings). And they match whatever you're changing the IP to?


I'd like to be able to reproduce it (it would make fixing it a lot easier), but I'm not currently set up to run multiple clients with showeq. And it will probably be a bit before I can spare the time to go through the hassle that will be necessary to do that.

But in the interest of trying to get this sorted out for you, I'll at least go through the code again and see if I can figure out what's happening.

[xerxes]

When you say "nothing shows in the console" I assume you mean zoning-related stuff... You're getting the messages about "listening for client on IP address", right? (and if you have debug enabled, the pcap filter settings). And they match whatever you're changing the IP to?


I'd like to be able to reproduce it (it would make fixing it a lot easier), but I'm not currently set up to run multiple clients with showeq. And it will probably be a bit before I can spare the time to go through the hassle that will be necessary to do that.

But in the interest of trying to get this sorted out for you, I'll at least go through the code again and see if I can figure out what's happening.

Yeah, there isn't any error related info in the console when it occurs, other than what I shared in the OP. It shows that it is changing to monitor the new machine but doesn't appear to do anything after that.