1/16/13 changes

[ShortBuss]

I think I finally found the cause. I enabled global log and that is helping me see more details. Looks like ShowEQ is picking up my mumble traffic and firing on it sometimes. Digging through the code I found that 0x500 opcode is session disconnect. And right at the time of my last packets in zone log I see a 0x500 opcode picked up going mumble server -> my client.

I hid the IP, but here's what it looks like. This log is about 100ms after my last zone log entry.

Jan 24 2013 22:21:40:311 [<My Mumble Server IP>:7506->client:58368] [Size: 110]
[OPCode: 0x500]
000 | 00 05 61 99 9b 7a da 72 6e e5 42 90 e7 90 88 87  | ..a..z.rn.B..... 
016 | 86 d8 95 87 0e 81 e6 a0 59 48 b7 19 95 10 ef c4  | ........YH...... 
032 | 66 79 c2 23 c6 e2 62 b9 33 97 c0 6a c2 49 cf b4  | fy.#..b.3..j.I.. 
048 | 1e 02 05 6d 33 6c a8 c8 c6 5d 05 0c e3 39 19 fc  | ...m3l...]...9.. 
064 | f4 e1 5f 21 e1 c7 fb 61 a7 3a 84 01 a0 86 f0 c7  | .._!...a.:...... 
080 | 57 3c b3 ea fe 9b f5 29 83 fa 90 18 23 cc 52 e0  | W<.....)....#.R. 
096 | af bf 36 07 39 df 6f a3 1c ee 42 46 d3 af        | ..6.9.o...BF..

So now I just need to figure out a way to block my mumble server IP address from being ready by ShowEQ.

[ShortBuss]

Seems there's no easy way outside of modifying the code to filter out specific IPs or ports. If there is then I missed it. I modified the pcap filters in packetcapture.cpp to ignore the port, 7506, and a couple of the IPs related to the mumble server. This should at least prevent the false disconnect (0x0500). Unfortunately it means I will be applying a custom patch on top of any built, but that's not a big issue. I see other bad traffic being looked at, like itunes for example, but I'll leave it alone as long as it doesn't cause any problems.

[fransick]

Seems there's no easy way outside of modifying the code to filter out specific IPs or ports. If there is then I missed it. I modified the pcap filters in packetcapture.cpp to ignore the port, 7506, and a couple of the IPs related to the mumble server. This should at least prevent the false disconnect (0x0500). Unfortunately it means I will be applying a custom patch on top of any built, but that's not a big issue. I see other bad traffic being looked at, like itunes for example, but I'll leave it alone as long as it doesn't cause any problems.

Pardon me if I am suggesting something that's either been tried, painfully obvious or way off base, but have you tried session tracking within SEQ? I recall that for some it was an effective way to ignore unecessary network traffic.

[ShortBuss]

I turned Session Tracking on again, but for some reason even with it on I'm still seeing mumble traffic being processed by ShowEQ. It could be something to do with my setup. I'm running EQ on Windows (of course). I'm running ShowEQ on Linux from within a VirtualBox VM on the same system as EQ. The VirtualBox network is setup as Bridged and Promiscuous mode set to all.

[purple]

Oh and if you're sitting at character select or just not in a zone, session tracking won't have locked down yet. You'll be unlocked watching world server traffic and waiting for zone server traffic to lock on to.