PDA

View Full Version : Session tracking should ignore when IP to monitor is changed



xerxes
02-19-2024, 11:23 AM
Seeing behavior where, in an effort to make it easier with multiple client's being visible to ShowEQ, I enable Session Tracking. However, when I want to swap monitoring to another IP that it sees, changing the monitored IP does not pick up any new sessions, since it's locked onto the other one.

This would normally make sense, however, if I am changing the IP to monitor, that would mean I want it to monitor that IP. Now, you have to disable it, then enter the new IP, then re-enable it.

cn187
02-19-2024, 12:44 PM
Nice catch!

I can't test it right now, but I think it's a simple fix. Mind trying this patch and letting me know? Apply it with
patch -p1 < patch.txt

xerxes
02-19-2024, 02:30 PM
Tested and recompiled and reinstalled. The patch applied successfully, however, it does not detect the new IP when zoning. Additionally, it no longer detects the original client either. So it's letting it go, but not seeing the zone change from the new IP.

cn187
02-19-2024, 03:04 PM
Hmm...

Assuming you're compiled with debug enabled (the default), then after you set the IP, you should see a message about the PCAP filter changing, and that should have the new IP in it but not the old session port. Can you confirm?

xerxes
02-19-2024, 03:59 PM
Correct. The port is changing.

I don't think is related, but I also tried setting Real Time Thread as a part of other testing. The process is running as root, but is unable to enable that. That may be broken.


ChangeCode: Server, Zone: xxxxxPCAP Filter Set: udp[0:2] > 1024 and udp[2:2] > 1024 and ether proto 0x0800 and host 192.168.75.1 and not broadcast and not multicast
Failed to set capture thread realtime.
EQPacket: SessionDisconnect detected, awaiting next zone session, pcap filter: EQ Client 192.168.75.1
PCAP Filter Set: udp and (portrange 9000-9007 or port 9876 or port 64586) and ether host XXXXX and ether proto 0x0800 and not broadcast and not multicast
Failed to set capture thread realtime.
EQPacket: SessionRequest detected, pcap filter: EQ Client XXXXX, Client port 64586. Server port 2110
EntryCode: Client
<snip>
Listening for IP client: 192.168.75.6
PCAP Filter Set: udp[0:2] > 1024 and udp[2:2] > 1024 and ether proto 0x0800 and host 192.168.75.6 and not broadcast and not multicast
Failed to set capture thread realtime.
PCAP Filter Set: udp and (portrange 9000-9007 or port 9876 or port 53946) and ether host XXXXX and ether proto 0x0800 and not broadcast and not multicast
Failed to set capture thread realtime.
EQPacket: SessionRequest detected, pcap filter: EQ Client XXXXX, Client port 53946. Server port 9009
Listening for IP client: 192.168.75.1
PCAP Filter Set: udp[0:2] > 1024 and udp[2:2] > 1024 and ether proto 0x0800 and host 192.168.75.1 and not broadcast and not multicast
Failed to set capture thread realtime.
EQInterface::savePrefs()
- isVisible()
Finished saving preferences to file: /root/.showeq/showeq.xml
- ==> EQInterface::savePrefs()
- isVisible()
Finished saving preferences to file: /root/.showeq/showeq.xml
- ==> EQInterface::savePrefs()
- isVisible()
Finished saving preferences to file: /root/.showeq/showeq.xml
ChangeCode: Client, Zone: xxxxx

cn187
02-19-2024, 04:21 PM
OK. Thanks for testing and the additional info. I'll have to try to test it here and see if I can figure out what's going on.

I haven't seen any issues with toggling realtime. If you want, the attached patch will cause it to print the return value from the underlying function, which we can look up and see why it doesn't like it. Apply with -p1

xerxes
02-19-2024, 08:36 PM
Warning - Failed to set capture thread realtime with error 1.

My best guess is because it's running in a container, it doesn't have access to something on the host system.

cn187
02-20-2024, 08:57 AM
Yes, errno 1 is EPERM - operation not permitted.

cn187
06-27-2024, 06:10 PM
I've been reworking some of the capture/filter/session code, hoping to improve the reliability of session detection, etc.

Based on my testing, I think things have improved considerably, but I'm not really set up to do meaningful testing of switching between multiple concurrent sessions.

Xerces, if you have some time, would you mind testing the attached patch (apply with -p1) and see if it helps with your session detection and char switching issues?

If not, let me know what you're seeing, and I'll try to figure it out. If it works, then let me know that, too. I'd like to merge it as part of the 6.4 update.

Thanks.


Edit: Updated the patch with an additional fix (v2).