Are you seeing the proper pcap filter locking with session tracking? Lines like
... are what you are looking for.Code:Debug: PCAP Filter Set: udp[0:2] > 1024 and udp[2:2] > 1024 and ether proto 0x0800 and host 192.168.0.115
Session tracking should lock down to a specific port when it sees a SessionRequest on the zone channel and then unlock when it gets SessionDisconnect. We used to get crashes from something called MS Teredo and from teamspeak but session tracking fixed it I thought.
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.
It seems to work as described now that I've backed out my changes to the pcap filters. I enabled session tracking then zoned in. Starting mumble I didn't see any problems. I then zoned a few times. The first two zones were fine, but on the third the map never changed. It saw the disconnect and waited:
But no more console information after that. Looking at global.log I can see it started getting false op codes from my mumble server again. My guess is that mumble got an EQ like packet in first before the EQ server did, after the Disconnect. Maybe it locked down onto the mumble ports.Code:Debug: PCAP Filter Set: udp[0:2] > 1024 and udp[2:2] > 1024 and ether proto 0x0800 and host 192.168.0.115 Info: EQPacket: SessionDisconnect detected, awaiting next zone session, pcap filter: EQ Client 192.168.0.115
The timing in global.log seems to line up to this theory. The first op-code from the mumble server shown is just after the last entry shown in the zone.log.
I happened upon a segfault zoning into bazaar. Details look very similar to the previous post that mentioned it. Before I could do any real debugging on it the character causing the problem logged and the segfault stopped happening. . Here are the details I managed to get before he left:
And here is the related entry from zone.log that caused the segfault:Code:Program received signal SIGSEGV, Segmentation fault.0xb7618fc0 in strcpy () from /lib/tls/i686/cmov/libc.so.6 #0 0xb7618fc0 in strcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0x08072cac in SpawnShell::fillSpawnStruct (this=0xb080cae8, spawn=0x0, data=0x850c7e4 "XXXXXXXX", len=446, checkLen=true) at /usr/include/bits/string3.h:107 #2 0x08076cd8 in SpawnShell::zoneEntry (this=0xb080cae8, data=0x850c7e4 "Deadrepp", len=446) at spawnshell.cpp:747 #3 0x08077228 in SpawnShell::qt_invoke (this=0xb080cae8, _id=8, _o=0xbfffc370) at spawnshell.moc:395 #4 0xb7b4c19a in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/lib/libqt-mt.so.3 #5 0x08091f7f in EQPacketDispatch::signal (this=0x83c0dc8, t0=0x850c7e4 "Deadrepp", t1=446, t2=2 '\002') at packetinfo.moc:99 #6 0x0808dacd in EQPacketStream::dispatchPacket (this=0x83cdd18, data=0x850c7e4 "Deadrepp", len=446, opCode=24744, opcodeEntry=0x8324510) at packetstream.cpp:435 #7 0x0808fc03 in EQPacketStream::processPacket (this=0x83cdd18, packet=..., isSubpacket=true) at packetstream.cpp:754 #8 0x0808ff13 in EQPacketStream::processPacket (this=0x83cdd18, packet=..., isSubpacket=true) at packetstream.cpp:892 #9 0x0808fc70 in EQPacketStream::processPacket (this=0x83cdd18, packet=..., isSubpacket=false) at packetstream.cpp:659 #10 0x080905d8 in EQPacketStream::handlePacket (this=0x83cdd18, packet=...) at packetstream.cpp:572 #11 0x080997be in EQPacket::dispatchPacket (this=0x8395ef0, packet=...) at packet.cpp:659 #12 0x08099915 in EQPacket::dispatchPacket (this=0x8395ef0) at packet.cpp:583 #13 EQPacket::processPackets (this=0x8395ef0) at packet.cpp:400 #14 0x0809c7f8 in EQPacket::qt_invoke (this=0x8395ef0, _id=2, _o=0xbfffe7b8) at packet.moc:577 #15 0xb7b4c19a in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/lib/libqt-mt.so.3 #16 0xb7b4e168 in QObject::activate_signal(int) () from /usr/lib/libqt-mt.so.3 #17 0xb7eacd99 in QTimer::timeout() () from /usr/lib/libqt-mt.so.3 #18 0xb7b7066e in QTimer::event(QEvent*) () from /usr/lib/libqt-mt.so.3 #19 0xb7ae73d7 in QApplication::internalNotify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #20 0xb7ae834b in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #21 0xb7adce42 in QEventLoop::activateTimers() () from /usr/lib/libqt-mt.so.3 #22 0xb7a921b6 in QEventLoop::processEvents(unsigned int) () from /usr/lib/libqt-mt.so.3 #23 0xb7b003b0 in QEventLoop::enterLoop() () from /usr/lib/libqt-mt.so.3 #24 0xb7b00256 in QEventLoop::exec() () from /usr/lib/libqt-mt.so.3 #25 0xb7ae7a2f in QApplication::exec() () from /usr/lib/libqt-mt.so.3 #26 0x0806a33b in main (argc=1, argv=0xbffff444) at main.cpp:737
**UpdateCode:Jan 27 2013 XX:XX:XX:XXX [Decoded] [Server->Client] [Size: 446] [OPCode: 0x60a8] [Name: OP_ZoneEntry][Updated: 01/16/13][Type: uint8_t (1) nc] 000 | XX XX XX XX XX XX XX XX 00 94 61 00 00 47 41 3a | XXXXXXXX..a..GA: 016 | b2 40 00 20 02 00 38 91 00 00 80 bf 00 00 00 00 | .@. ..8......... 032 | 01 01 00 00 00 64 ff ff 09 09 ff ff 00 00 00 00 | .....d.......... 048 | 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 c0 40 | ...............@ 064 | 03 1f 85 eb 3e 33 33 33 3f 80 00 00 00 00 cb 00 | ....>333?....... 080 | 00 00 54 01 00 00 05 00 00 00 0b 00 64 00 00 XX | ..T.........d..X 096 | XX XX XX XX XX 00 03 00 00 00 01 00 00 00 00 00 | XXXXX........... 112 | 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | .@.............. 128 | 00 ff ff ff ff ff ff ff ff 00 00 a0 ff 00 00 a0 | ................ 144 | ff 00 14 c8 ff 00 00 a0 ff 00 00 a0 ff 00 14 c8 | ................ 160 | ff 00 00 a0 ff 00 00 00 00 00 00 00 00 01 00 00 | ................ 176 | 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 | ................ 192 | 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 208 | 00 0a 00 00 00 01 00 00 00 00 00 00 00 00 00 00 | ................ 224 | 00 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 | ................ 240 | 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 | ................ 256 | 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 | ................ 272 | 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 288 | 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 | ................ 304 | 00 00 00 00 00 01 00 00 00 5a 2b 00 00 00 00 00 | .........Z+..... 320 | 00 00 00 00 00 00 00 00 00 00 00 00 00 da 27 00 | ..............'. 336 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 352 | 00 00 00 00 00 42 84 83 00 dd 03 00 3a 00 c0 9c | .....B......:... 368 | 05 42 58 04 20 4c 69 63 68 20 4c 6f 72 64 00 00 | .BX. Lich Lord.. 384 | 00 00 00 00 00 00 00 00 30 30 30 30 30 30 30 30 | ........00000000 400 | 30 30 30 30 30 30 30 30 00 ff ff ff ff ff ff ff | 00000000........ 416 | ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 432 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ..............
Seems like the problem is with the decision on spawn->otherData. In this case the value is 0x91. if(spawn->otherData & 1). True in this case, and based on the comments in the source that means it's a chest or untargettable, which it isn't. Following the logic and the data read for the chest/untargetable block consumes the last name data before it should be read. This means that later in the code when the last name is read it's going to read something random.
Last edited by ShortBuss; 01-27-2013 at 05:39 PM.
Looks like the bit for identifying chest/untargetable is no longer &1. I see this bit set on players (and it can be unset on players). I confirmed &16 is still title, &32 is still suffix, &4 is still aura. I can't figure out any objects that would fall under the previous &1 to test where this bit may have moved to.
*Update
&1 appears to now be buyer flag for bazaar
&2 seems to be Offline flag for bazaar buyers, though I only found 2 to verify with.
Commented out the if block in spawnshell.cpp (if(spawn->otherData & 1)...). Now when I zone into bazaar I can see the buyers on the map, not just sellers.
Last edited by ShortBuss; 01-27-2013 at 07:19 PM.
I hate it when they change those bit fields.
Razzle
It may be that the old &1 was combined with &4. I found a chest in the bazaar that's has the &4 bit set, which should be auras, based on the code comments. I also saw auras that were still flagged with &4.
Session tracking opens and closes. Each time you zone, the zone server renegotiates a new different port. So when you're zoning, after the original zone server sends the session disconnect but before the new zone server sends a session request, the filter is wide open. You can actually see the negotiation of the new server port on the world server, but I never added handling for it, though I was tempted because I had a perfect log file from BA that I could use for testing. It causes problems for people who two box on the same box too. If you point seq at that box and you zone both characters at the same time, sometimes seq will flip from one character to the other. Anyways, I just never got around to it.
Someone needs to spend time actually methodically going through the spawn flags. Or someone needs to get into disassembly of the client and see what it actually does.
A little more information on the otherData flags after parsing several log files:
&1 = Buyer in the Bazaar (/buyer)
&2 = Offline mode in the bazar (/buyer or /trader)
&4 = Aura's, NPC corpses (not players), Training Dummies, Chests, some unknown things (Name = _29, _30, _28, _31, _07 ...)
&8 = Have not yet seen this one set on anything
&16 = Has Title
&32 = Has Suffix
&64 = Unknown. Have seen both set and unset on same character. No impact on fillSpawnStruct logic either way.
&128 = Unknown. Have seen both set and unset on same character. No impact on fillSpawnStruct logic either way.
Still unable to figure out 8, 64, & 128. Confirmed both 64 and 128 don't impact the fillSpawnStruct logic by looking at the differences in the same character having the flags set and unset in different instances. I can't find anything with 8 set. I've seen several chests now with 4 set so I think it was maybe combined with auras. I've seen both targetable and untagettable things set with 4.
For now it seems the temporary fix is to comment out the section of fillSpawnStruct code using &1. This patch below is for that change and also includes showeq42's fix for bodytype = 0.
I tried this out last night for several hours and did not have any problems.Code:Index: src/spawnshell.cpp =================================================================== --- src/spawnshell.cpp (revision 783) +++ src/spawnshell.cpp (working copy) @@ -568,6 +568,7 @@ // skip unknown3, unknown4 netStream.skipBytes(8); + /* &1 now is for /buyer in auction house. Chest/Untargetable may now be combined in &4. if(spawn->otherData & 1) { // it's a chest or untargetable @@ -596,6 +597,7 @@ // skip the last long netStream.skipBytes(4); } + */ if(spawn->otherData & 4) // aura stuff { @@ -610,19 +612,26 @@ #endif i = spawn->charProperties; - do + if(i == 0) + { + spawn->bodytype = 0; + } + else { - nTmp = netStream.readUInt32NC(); + do + { + nTmp = netStream.readUInt32NC(); - if(i == spawn->charProperties) - { - spawn->bodytype = nTmp; + if(i == spawn->charProperties) + { + spawn->bodytype = nTmp; #ifdef FILLSPAWNSTRUCT_DIAG - seqDebug("bodytype = %d", spawn->bodytype); + seqDebug("bodytype = %d", spawn->bodytype); #endif - } + } + } + while(--i); } - while(--i); spawn->curHp = netStream.readUInt8(); #ifdef FILLSPAWNSTRUCT_DIAG @@ -882,7 +891,7 @@ if (dir != DIR_Client) { - int16_t y = (pupdate->y + pupdate->y) >> 3; + int16_t y = pupdate->y >> 3; int16_t x = pupdate->x >> 3; int16_t z = pupdate->z >> 3;
Hi, thank you all for continuing this. Just one question. I'm having problems to get the maps to show up right on the latest expansion. Is there a new mapconvert that I am missing? EDIT: AH I just noticed I needed to change the time to "Beginning" to see the old threads. Will look through those. Sorry.
Last edited by Razzy; 02-10-2013 at 11:23 AM.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote