Session tracking should ignore when IP to monitor is changed
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.
1 Attachment(s)
Re: Session tracking should ignore when IP to monitor is changed
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
Re: Session tracking should ignore when IP to monitor is changed
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.
Re: Session tracking should ignore when IP to monitor is changed
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?
Re: Session tracking should ignore when IP to monitor is changed
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.
Code:
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
1 Attachment(s)
Re: Session tracking should ignore when IP to monitor is changed
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
Re: Session tracking should ignore when IP to monitor is changed
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.
Re: Session tracking should ignore when IP to monitor is changed
Yes, errno 1 is EPERM - operation not permitted.