New bug in 5.0.0.0-18?

[BlueAdept]

I installed it last night and have had 4 crashes since then.

I play 2 chars on one pc and use session tracking. It seems when ever I zone both chars (or get both ported) it crashes.


Zone: Zoning, Please Wait... (Zone: 'poknowledge')
Zone: ChangeCode: Server, Zone:poknowledge
Info: EQPacket: SEQClosing detected, awaiting next zone session, pcap filter: EQ Client 192.168.1.2
Info: EQPacket: SEQClosing detected, awaiting next zone session, pcap filter: EQ Client 192.168.1.2
Warning: INVALID PACKET: Bad CRC [199.108.15.130:9000 -> 192.168.1.2:1318] netOp 0300 seq 0000 len 44 crc (dae0 != ac2c)
Info: SpellItem 'Circle of Knowledge' finished.
Warning: INVALID PACKET: Bad CRC [192.168.1.2:1318 -> 199.108.15.130:9000] netOp 0900 seq 0000 len 176 crc (4b82 != 85dd)
Warning: !!!! EQPacketFragmentSequence::addFragment(): buffer overflow adding in new fragment to buffer with seq 0001 on stream 1, opcode 3bfb. Buffer is size 546 and has been filled up to 501, but tried to add 505 more!


Any ideas? I have nothing else running.

[purple]

There's a small window after session tracking opens up the pcap filter from host x.y.z.q && port w to just host x.y.z.q until it picks up a new zone server then re-locks down. That window opens when you see SEQClosing detected.

During that window, your two sessions both meet the pcap filter host x.y.z.q so both sets of packets are processed. Ideally, only one session key would be received, so other packets for the second session would be tossed because of CRC failures, but if it were working that way, then you wouldn't have a problem. Hrm. This is by no means new to 5.0.0.18.

My best guess is that when the second OP_SessionDisconnect is seen (this is where SEQClosing detected is printed), it resets the packetstreams tossing away some things it needed.

If you're interested in trying to fix this yourself, I'd recommend turning on PACKET_SESSION_DIAG and seeing where the session boundaries actually are. If you want me to fix this, please take a tcpdump of it breaking doing something like:

tcpdump -i eth0 -s0 -w ba-2boxcrash.log 'udp && host 192.168.1.2'

Then gzip ba-2boxcrash.log and get it to me somehow. I'm usually on IRC, or you can email it to [email protected] I guess. Or if it is small, you may be able to pm it to me here.

[BlueAdept]

Ok. Will do. I didn't seem to have any problems with this on 5.0.0.0-17. I might have been lucky though. Last night was my first night of actually running EQ for more than 20 minutes in a while.

Since last night was my first night of running 18, I probably need to test it a bit more to narrow it down.

Are we going to have problems with the new patch on Tuesday? Sounds like a lot of changes are going to happen. Anyone play on Test?

[purple]

There are a couple small changes I've seen on test. I don't expect it to be a big problem, but there will be some small changes.

You do know 5.0.0.19 is out, right? 8)

[Spaz]

Seems to be fine on test at the moment. Somewhere around two months ago I started getting periodic crashes, but they usually were once ever few days. They've increased in frequency lately, so I'll probably post the text of it.

[purple]

If you see crashing and are just running a normal setup, the first steps you should take are to increase arqSeqGiveUp to at least 512 and maybe higher and run with session tracking on even if you don't need it to cut down on the amount of packets that get handed off by pcap to seq.

The random crashing involves missed packets, then the cache filling up waiting for the missed packet, then a fragmentation error because the missed packet was important. You'll see this on the console as a couple giving up messages and then a packet fragmentation buffer overflow followed by a seqfault.

[BlueAdept]

I think I got the version numbers wrong. It is the newest one in the cvs as of Saturday night. I thought it was 18. I guess it is 19. I wont be able to tell until I get home from work.

[BlueAdept]

It worked fine. It was only when both of my toons zoned at the same time that it crashed. I spent about 3 1/2 hours on last night and it only crashed on zoning. I could zone separately without a crash but if I ported both or zoned in on both accounts at nearly the same time, crash.

Maybe something got screwed up on the build too. Ill do a fresh install and see if that helps and change the giveup time. I think it is set to 512 already.

[purple]

Ah, then it's possible that your problem started with 19. There were a couple fixes to oversized packet handling there to make them cache properly. So before, when you had two sessions being processed at once, the one that was behind would just have its packets silently dropped. Now, they are getting cached and used as appropriate, which in your case is inappropriate because the sessions are crossed.

[BlueAdept]

It is version 19 and does have give up at 512. I reinstalled it with a fresh install and it crashes every time I zone both my characters at the same time. As long as I zone them separately it is fine. I waited until the other char fully zoned before zoning my other one.

It crashes almost immedately when I zone both together.

Ill make some packet dumps tonight.