ShowEQ 4.3.18 unknown spawn discussions

[Alfred]

First and foremost; Great work Zaphod and I hope you conitinue your work.

Second, I have noticed in HoH and at least a few other zones, that I end up with unknown spawns (as has happened in a previous release until Zaphod nailed it) with the latest release. This happens at some point after I have been in the zone for a few minutes. Once it starts, everything new becomes an unknown.

I am using:

ShowEQ 4.3.18, Built from 'main.cpp' on Nov 11 2003 at 07:57:33
CVS: $Id: main.cpp,v 1.33 2003/10/25 00:20:59 dohpaz Exp $
Using GCC version: 3.2.3
Using glibc version: 2.3
Using Qt version: 3.1.2
Using headers from linux version: 2.4.19
Using EQItemDB: @(#) $Id: itemdb.cpp,v 1.10 2003/10/25 00:20:59 dohpaz Exp $
Using GDBM: This is GDBM version 1.8.0, as of May 19, 1999.
Running on Linux release 2.4.20-gentoo-r7 for processor i686


I would be happy to provide a capture log if you have the time and inclination to track this down. I hope others (if there are any) will post if they are seeing the same thing. If you do want a capture log, give me a quick description of how you want it done. Thanks.

Regards,

Alfred

[Alfred]

So I assume that I am the only person to see unknowns?

I admit it doesn't happen all the time, but it does happen.

If you see this happen at all please post. Thank you.

[a_corpse_02]

I got a couple unknowns last night in Skyfire Mountains helping a cleric friend farm pearl frags for about 4 hours. But, we were slaughtering mobs by the truckloads so there would be a lot of repops and I only got one or two unknowns. I didn't think much of it.

[Dark]

My unknown spawns: Plane of Nightmares

Player::zoneBegin(): Pos (1668.000000/282.000000/212.000000) Heading: 5.000000
EQPacket: SEQClosing detected, awaiting next zone session, pcap filter: EQ Client 192.168.1.155
EQPacketFragmentSequence::addFragment: WARNING OpCode 0x6951 will not be processed due to loss
EQPacketFragmentSequence::addFragment(): recieved Out-Of-Order fragment seq 0x0006 (0x0002) expected 0x0000


I'm still getting some spawns but not many.

[cheese_poker]

An easy way to recreate an unknown spawn is to make a horse, and click it off. FYI.

[sea4th]

Unknown spawn behaviour described by Al is also observed in PoStorms but it is erractic. When there are very few peeps in zone or I am the only one hunting forest frogs the new spawns work fine. The spawn points light up and new spawns are decoded properly. When I first noticed unknown spawns or new spawns not being decoded it was right after the 4.3.18 release had been compiled from a fresh download and thought maybe the prior patched 4.3.17 did not exhibit this behaviour. After reinstalling the 4.3.17patched executable, the undecoded spawns are present.

In checking the spawn logs I have the following observation. I am soloing the frogs and someone else pops into the zone and takes a frog - after this frog is killed and they leave the next spawns were not decoded. I also noticed that the spawn log does not connect my player ID to the kills I make but does connect other players and my pet.

One last wrinkle - looking at the spawn list window shows unknown spawns are occuring even when forest frogs are being decoded. Rezoning / camping clears up the unknowns but loses the spawn point timer.

If there are other things or items I can watch for or test out please reply to this thread. With a spawn timer of 20mins it takes an hour to detect when unknown spawns are occurring.


Suggestions?

[Cryonic]

record a log of the packets and then see if Zaphod or another active dev can run through it to see why it is starting to do that. If it is showing things like:
Player::zoneBegin(): Pos (1668.000000/282.000000/212.000000) Heading: 5.000000
EQPacket: SEQClosing detected, awaiting next zone session, pcap filter: EQ Client 192.168.1.155
EQPacketFragmentSequence::addFragment: WARNING OpCode 0x6951 will not be processed due to loss
EQPacketFragmentSequence::addFragment(): recieved Out-Of-Order fragment seq 0x0006 (0x0002) expected 0x0000

Then maybe set Network -> Advanced -> Arq Seq Give Up to something higher than 256 (512 or maybe 1024).

It is possible that if packets are getting fragmented, then SEQ may be missing pieces coming over the wires and so once it gets an unknown mob it can't decode any after it (something to do with the way encoding is done now).

[tamasine]

I'm getting this error since upgrading to DSL - but only when running down/uploads from the same computer as everquest.. i thought it might be the network card - but it did occur to me that if showeq is capturing all packets from a host - then it might get overloaded.

t.

[SeqTester]

I do get unknowns also now and then. Not a big deal.. more wanted to comment on the "SEQ seeing other traffic"

I have found if SEQ is running when I remote desktop another machine from my EQ box it will crash. And EQ isn’t even running.

So yes it does see other packets, that’s what a packetsniffer does.

ST

[tamasine]

the pcap libraries have the ability to filter packets. if seq is requesting a full snoop of another machine, i can see that if it does a large transfer in the background, then seq may get overloaded with data. if however the snoop is of udp, eq-likely ports then it won't. (hmm. anyone know if bittorrent uses udp or tcp? - that'd explain it if the filter is "udp". i should really go and hack that bit to add "and not port <insert port here>")

"that's what a packet sniffer doesn" is relatively unhelpful. you meant "that's what a promiscuous interface does" - a packet sniffer is configurable to what packets it'll notice... as demonstrated by the network option to only snoop packets from a specified ip address

[Cryonic]

Most file sharing protocols are of the TCP variety. As for EQ, I would think that it would have a little of both. TCP to maintain your presence in the game and to receive data when zoning, UDP to deal with movement and combat.

[Zaphod]

The EQ protocols that ShowEQ monitors are all UDP based and come in on a wide variety of ports. You can see the current pcap filter being used by ShowEQ at any time. Just bring up the "Network Diagnostics" window from the "View" menu. Then look under the "Pcap Thread" entry's "Filter" sub-entry.

As far as what else is UDP based, almost all audio/video conferencing and streaming protocols, some file sharing protocols, part of DNS, most network file system protocols, dhcp, and a wide array of others. I just looked at the bittorrent protocol specification and it is TCP based, so as long as the pcap filters aren't seriously malformed it shouldn't capture them.

Feel free to have a go at improving the filtering ShowEQ does.

Enjoy,
Zaphod (dohpaZ)

[tamasine]

hmm. i had a feeling it would be. which means the problem is likely to either be the hub, or that network card, or the seq computer being unable to keepup with a 10bT network at the same time as running X+seq.. which actually might be the case. (showeq on idle [no EQ running] is taking 40% cpu)

bleh. ;)

[tamasine]

hum. wierder and stranger said alice.

if i kill all the torrents, nothing changes. restart seq - and it's back to its normal damn-good self.

puzzling.. i'll keep poking.
(and 40% cpu was with no eq running. start eq up and showeq drops to 10%

[Cryonic]

Wonder if SEQ is getting up in a loop dealing with packets when EQ isn't going. I leave SEQ running when EQ is off and don't see that kind of problem. I run it on a P150 laptop and a Quad-PPro 200 box. System load on both is 0.00 when EQ isn't up. I do have things like BT going on in the background whether I'm in EQ or not on several systems, same with Kazaa at times.