10/21 patch

[cn187]

It doesn't look like opcodes/structs changed, so things should still be working. Please post if you run into issues, as there could be changes to things I don't usually check.

[creekcg]

Not working for me :/ anyone have the updated offsets ?

[whr2]

Not working here either

[cn187]

OK, I've confirmed the issue. The opcodes and (usual) structs didn't change, but there was another change in the stream that's affecting decoding. I'll start looking into it.

[Newby]

Seems to work fine for me, no changes necessary. Maybe they're closing in?

[whr2]

Newby, can you post what is working for you?

[Newby]

Not sure what you want me to post, my source tree matches whats in the repo.

[BlueAdept]

I think I found what it is. It doesnt detect the Next Client seen and by what ETH. I had to manually put in the IP address for it to see the packets. It does seem to work but I think some opcode has changed.

I saw a lot of this until I specified my IP

Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261
Warning: EQPacket: Unhandled net opcode 0000, stream zone-client, size 237
Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261
Warning: EQPacket: Unhandled net opcode 0000, stream zone-client, size 237
Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261
Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261
Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261
Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261
Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261
Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261
Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261
Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261

[cn187]

Nice catch! I can confirm that specifying the IP seems to work around the problem, at least for me.

[Newby]

Yeah, I have my IP specified in my showeq.xml file.

[b4rad1234]

Where am I supposed to be specifying the IP? Not locating a "showeq.xml" file in the directory. Sorry, new here. :)

[cn187]

On further reflection, some of the people reporting issues may have been MySEQ users (one mentioned offsets, and the post history of the other indicates MySEQ)... Someone posted the new offsets here, so I moved that to the other forum.

For what it's worth, I've been needing to manually select "Monitor Next EQ Client Seen" for quite a while, so I figure this is just an extension of whatever has been causing that.

I've been meaning to dig into the SEQ networking code to learn more about it and the EQ protocol, so maybe this will give me a good excuse to actually do it... Fortunately, since specifying the IP seems to work around it, everyone's not dead in the water for however long it takes me to figure it out.

[b4rad1234]

This makes sense. Tyvm...

[BlueAdept]

I have done further testing. It will not work without setting the IP. I turned on logging but don't know how to figure out what it is looking for.

From the Global log:

Oct 21 2020 19:08:53:085 [10.10.70.XXX:54915->10.10.70.255:54915] [Size: 263]
[OPCode: 0x4d00]
000 | 00 4d 53 49 00 00 00 00 70 dc c4 a6 89 02 00 00 | .MSI....p.......
016 | a0 b6 7f 93 fb 00 00 00 00 00 00 00 00 00 00 00 | ................
032 | 33 27 00 00 00 00 00 00 60 dc c4 a6 89 02 00 00 | 3'......`.......
048 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
064 | 00 00 00 00 00 00 00 00 7c 6a b9 6a 00 00 00 00 | ........|j.j....
080 | c8 a3 16 6b 00 00 00 00 d9 ba 7f 93 fb 00 00 00 | ...k............
096 | 00 00 00 00 00 00 00 00 10 5f 5d a6 89 02 00 00 | ........._].....
112 | 24 b7 7f 93 fb 00 00 00 40 b7 7f 93 fb 00 00 00 | $.......@.......
128 | 28 f1 2c 7b FF FF FF FF 39 61 39 38 2d 32 37 66 | (.,{12345678-27f
144 | 36 2d 34 65 32 62 2d 39 66 63 35 2d 33 38 35 66 | 6-4e2b-9fc5-1234
160 | FF FF FF FF FF FF FF FF 7d 00 00 00 00 00 00 00 | 12345678}.......
176 | 01 00 00 00 fb 00 00 00 20 b7 7f 93 fb 00 00 00 | ........ .......
192 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
208 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
224 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
240 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
256 | 00 00 00 8e a8 a3 30 | ......0

Oct 21 2020 19:08:53:274 [10.10.70.xxx:32978->XXX.255.255.XXX:1900] [Size: 101]
[BAD CRC (f28c != d0a)! Sessions crossed or unitialized or non-EQ packet! ]
[SessionKey: 0]

It seems to be getting the right IP but I think the paket is bigger than it is supposed to be. The struct may need to be corrected.

That is the same packet it is complaining about in the main window when you dont specify an IP.

Warning: EQPacket: Unhandled net opcode 4d00, stream client-zone, size 261

[Newby]

That's actually a different protocol. Most of EQ's stuff is in the zone log. Global is an entirely different protocol that's used to set up the zone protocols, as near as I can figure.

[cn187]

I don't think that's the global EQ stuff either (despite being in the global log).

I think that's unrelated LAN traffic that's getting captured and misinterpreted as being an EQ packet.

Note that the destination address ends in .255 - that's the broadcast address for the local subnet. All the EQ traffic should be point to point (AFAIK)

[kkmonte]

Yea the past two months i haven't had to change anything, I always specify my IP address and everything has been working fine. probably about 6 months ago, i would occasionally not work when I did monitor next eq client seen so once i switched it all worked great.

[BlueAdept]

IDK. At least there is a workaround. I dont know enough to diag it any further.

[cn187]

My initial impression was that something in the protocol changed, but honestly, the whole problem may just be local LAN traffic getting misinterpreted. Maybe I should spend some time trying to tune the capture filters. I think ignoring broadcast and multicast traffic would be low-hanging fruit that would likely have some decent results. Limiting the capture to traffic going to/from DBG's IP block could be helpful too, though that should probably be configurable.

[cn187]

I don't think that's the issue. For example I don't see any world traffic on 9000 OR 9001, but rather a different port 900x port.

Looking at a wireshark capture, there are a series of packets sent by the login server that show what world server and port should be used depending on the server you want to connect to.

As an example:



0040 00 00 00 00 17 00 00 00 65 71 77 6f 72 6c 64 2d ........eqworld-
0050 30 33 2e 65 76 65 72 71 75 65 73 74 2e 63 6f 6d 03.everquest.com
0060 00 2f 23 00 00 00 00 00 00 21 01 00 00 66 00 00 ./#......!...f..
0070 00 42 65 72 74 6f 78 78 75 6c 6f 75 73 20 2d 20 .Bertoxxulous -
0080 53 61 72 79 72 6e 00 45 4e 00 55 53 00 00 00 00 Saryrn.EN.US....
0090 00 01 00 00 00 65 71 77 6f 72 6c 64 2d 30 32 2e .....eqworld-02.
00a0 65 76 65 72 71 75 65 73 74 2e 63 6f 6d 00 2a 23 everquest.com.*#
00b0 00 00 00 00 00 00 21 01 00 00 68 00 00 00 42 72 ......!...h...Br
00c0 69 73 74 6c 65 62 61 6e 65 20 2d 20 54 68 65 20 istlebane - The
00d0 54 72 69 62 75 6e 61 6c 00 45 4e 00 55 53 00 00 Tribunal.EN.US..
00e0 00 00 00 02 00 00 00 65 71 77 6f 72 6c 64 2d 30 .......eqworld-0
00f0 32 2e 65 76 65 72 71 75 65 73 74 2e 63 6f 6d 00 2.everquest.com.
0100 28 23 00 00 00 00 00 00 21 01 00 00 69 00 00 00 (#......!...i...
0110 43 61 7a 69 63 2d 54 68 75 6c 65 20 2d 20 46 65 Cazic-Thule - Fe
0120 6e 6e 69 6e 20 52 6f 00 45 4e 00 55 53 00 00 00 nnin Ro.EN.US...
0130 00 00 03 00 00 00 65 71 77 6f 72 6c 64 2d 30 32 ......eqworld-02
0140 2e 65 76 65 72 71 75 65 73 74 2e 63 6f 6d 00 2d .everquest.com.-
0150 23 00 00 00 00 00 00 21 01 00 00 6a 00 00 00 44 #......!...j...D
0160 72 69 6e 61 6c 20 2d 20 4d 61 65 6c 69 6e 20 53 rinal - Maelin S
0170 74 61 72 70 79 72 65 00 45 4e 00 55 53 00 00 00 tarpyre.EN.US...
0180 00 00 04 00 00 00 65 71 77 6f 72 6c 64 2d 30 31 ......eqworld-01
0190 2e 65 76 65 72 71 75 65 73 74 2e 63 6f 6d 00 28 .everquest.com.(
01a0 23 00 00 00 00 00 00 21 01 00 00 6d 00 00 00 45 #......!...m...E
01b0 72 6f 6c 6c 69 73 69 20 4d 61 72 72 20 2d 20 54 rollisi Marr - T
01c0 68 65 20 4e 61 6d 65 6c 65 73 73 00 45 4e 00 55 he Nameless.EN.U
01d0 53 00 00 00 00 00 05 00 00 00 65 71 77 6f 72 6c S.........eqworl
01e0 64 2d 30 31 2e 65 76 65 72 71 75 65 73 74 2e 63 d-01.everquest.c
01f0 6f 6d 00 2c 23 00 00 00 00 00 00 21 01 00 00 6f om.,#......!...o
0200 00 00 00 46 69 72 69 6f 6e 61 20 56 69 65 20 28 ...Firiona Vie (
0210 52 6f 6c 65 70 6c 61 79 69 6e 67 20 50 72 65 66 Roleplaying Pref


So it looks like Bertox uses eqworld03 on 9007, Bristlebane uses eqworld02 on 9002, Cazic uses eqworld02 on 9000, etc.

I'm guessing either you were testing on a different server than previously, or perhaps they swapped the ports around on the back-end during the patch.

But in any event, it would appear that SEQ hasn't been picking up the world server traffic in the majority of cases if it's only listening on 9000.

Honestly, I don't know what world-level stuff SEQ uses (other than just logging), so I don't know if we should expand the filters (or detect the port and change it on the fly) to handle all of the various world server ports, or if it's fine as is.

[Newby]

The code where it locks onto what IP address you're playing on (if you haven't specified it on the command line or in your .xml file) is in packet.cpp at the very beginning of function EQPacket::dispatchPacket. The m_detectingClient variable is True if you haven't specified an IP. All the two "if" statements do is test that and then check if the packet source or dest port is 9000. If it is, it locks onto that IP address.

If they're using a different ports now, then you'd have to change the "if" statements to detect a range of ports, once you figure out what that range is.

The packetfilter strings in packetcapture.cpp would need to be changed to a range check too. I'm not sure why they're pulling bytes out and comparing them to 9000 instead of using the "portrange" keyword, maybe that was the only way to do it back then.

[cn187]

Yeah, I'm working on the changes to the if statements as we speak. And I agree about the portrange. I think I'll try to adjust the captures to use that instead, and also to filter broadcast/multicast like I mentioned earlier.

[cn187]

Also, range looks to be 9000-9007. I've got a patch compiling now for testing. I'll post it once I've verified it checks out.

[cn187]

Here's a patch to expand the capture filters and the client detection to use the full 9000-9007 world server port range. It also filters out broadcast and multicast traffic, so that should quiet down the logs a bit regarding weird packets (like BlueAdept's example from upthread).

Running around in game, it seems fine. I've tried it with/without session tracking, and with/without specifying my host IP and haven't had any noticeable issues.

[BlueAdept]

I have tested the patch and it does seem to rectify the network issue. Therefore I have updated the SVN and File section with the fix.

Thanks again!