Is 5.0.0.22 broken?

[Wr6TAG7ju1I=]

After a recent (05/27/05) build of -.22, I logged onto SEQ under root and viola !! skittles!!

However, after my first zone-out, the colors disappeared and shortly therefore, I got unusual error messages referring me to opcodes and such.

The Error message refers to EQPacketFragmentSequence::add Fragment( ): seq 00f8 on stream 3, opcode 2db5.

I did the build on RH8 using QT-3.3.3

Is -.22 broken?

[tanner]

Works for me.

Is the problem and the solution recommended here help you?

http://www.showeq.net/forums/showthread.php?t=4481

[purple]

I'm guessing a 2 year old thread has nothing to do with something in a net layer that was totally reworked 4 months ago.

5.0.0.22 isn't broken. If you want help, please bother to put the entire error message in here with some relevant context. Just picking a couple words out of it is like seeing an entire java stack trace that identies exactly where the problem is and only picking out ArrayOutOfBoundsException when you tell someone what happened.

[mungtor]

Redhat 9, QT 3.1.1-6. Just compiled 5.0.0.22 tonight (5/27) and it initalized fine, but crashed after I had been in the zone with: (server and toon name snipped)

Player: ExpAA: Set: 0 total, with 0 aapoints
Info: Loaded map: '/usr/local/share/showeq/maps/bazaar.map'
Info: Loading Zone Filter File: /root/showeq-5.0.0.22
Zone: Zoning, Please Wait... (Zone: 'bazaar')
Debug: Player::zoneBegin(): Pos (-786.500000/1161.375000/2.500000) Heading 1.000
000
Zone: EntryCode: Server
Debug: SEQ: Giving up on finding arq 007b in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 007c in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 007d in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 007e in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 007f in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0080 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0081 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0082 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0083 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0084 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0085 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0086 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0087 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0088 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0089 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 008a in stream zone-client cache, skipping!
Warning: Oversized packet fragment requested buffer of size 0 on stream 3 OpCode
0000 seq 00a6
Debug: SEQ: Giving up on finding arq 00ae in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00af in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b0 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b1 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b2 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b3 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b4 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b5 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b6 in stream zone-client cache, skipping!
Warning: !!!! EQPacketFragmentSequence::addFragment(): buffer overflow adding in
new fragment to buffer with seq 00fb on stream 3, opcode 0000. Buffer is size 3
8302 and has been filled up to 38302, but tried to add 505 more!

Just for info. If I should upgrade QT or anything just let me know.

Thanks for all the work you put into this.

[purple]

No, you need to increase the size of your socket receive buffers. You should have an /etc/sysctl.conf where you can up net.core.rmem_default and net.core.rmem_max. What you should set it to depends on how much ram you have and how many active connections you machine has. If it's not many and the machine is only for seq, try something big like 8388608. If the machine is used for other stuff, start at 1/8th of that.

As low as you can set it and still work is best. man sysctl for more information on setting the params and /etc/sysctl.conf.

[Wr6TAG7ju1I=]

Dear Purple,

Thanks for the info on sysctl.

After reading the sysctl man and thinking about diving into my kernal (gulp), I took the plunge and was pleasantly surprised. After opening a terminal and typing sysctl -a and then modifying net.core.rmem_default and .rmem_max to 8388608, I seem to have gotten rid of my EQPacketFragment Sequence errors, similar to the previous poster. However, I am still plagued with the --

SEQ:Giving up on finding arq 0xxx in stream zone-client cache, skipping.

Playing around with the arq values under the Network--Advanced tabs in session helps reduce these debug errors, but after I zone out of any zone for the first time, the mobs disappear.

Is this something particular to the RH distro that ShowEQ has used for quite sometime. I'd hate to have to install the Fedora core just for ShowEQ use.

[BlueAdept]

Errors like "Debug: SEQ: Giving up on finding arq 00ae in stream zone-client cache, skipping!" can be caused by a a hub or network card dropping packets.

I get it occasionally when I 2 box on one computer.

[Wr6TAG7ju1I=]

I am running a somewhat large home network. Eight machines off of a Kingston 8 port hub, but I've been using SEQ since 4.x.x and this is the first time I'm seeing a lot of these debug error messages.
I have tabbed on my Session tracking, increased my arq give up number to 898, bumped up my net.core.rmem_default and _max = 8388608 and increased my net.ipv4.tcp_rmem = 4096.

Zoning into Lavastorm and then into Nek usually generates the mobs, but rezoning back into Lava destroys the mob array.

Not sure where to go at this point, but thanks for all of your help, now and in the past.

[purple]

There has to be something weird about your setup then. Do you two box on one machine or on separate machines without using session tracking? How much traffic does the seq box see? Are those 8 machines all generating traffic that the seq box can see?

I have a very hard time this just started with 5.0.0.22. There has been very little changes to the network layer in seq in the past months. The main changes recently that are aggravating are a lot more traffic while zoning (sometimes the entire server guild list, which is HUGE) is sent, and also there's a lot new client->server traffic that can get large. Bear with me while I explain to you what is happening.

When you see "SEQ: Giving up on finding arq 0084 in stream zone-client cache, skipping!" that means that packets are being dropped or not seen (specifically in that message packet #0084). That happens when the cache gets really large. This is what arqSeqGiveUp defines - "How large should I let the packet cache become before I give up ever seeing a packet I need".

So, either your net stream is so totally out of order that a packet is 898 positions out of order (unlikely, but maybe try bumping it up to 1024 or higher if you want) or you are dropping packets.

The only way to "fix" streams that are horribly out of order is to increase arqSeqGiveUp. The higher arqSeqGiveUp is, the more of a chance that you are just delaying the problem, though. This is what you are seeing when you say the mob list "is destroyed". You zone into a place, but the stream is missing a packet. When arqSeqGiveUp is too high, showeq will just be waiting for the packet it needs for a long time and you'll see nothing happening. Usually though this is a dropped packet and not the stream being exceedingly out of order. The most out of order I've seen is around 500.

There are a couple things you can do to help with dropping packets. I'm assuming you are running a recent 2.6 kernel. Do you have multiple packet sniffing applications running? Are you using session tracking? What version of libpcap do you have?

Ideally, session tracking would restrict the amount of packets that get into the kernel's receive buffers so that non-seq packets don't dominate the buffer. If you have lots and lots of traffic that your hub sees and if you have stuff sniffing in promiscuous mode with no strict filters, that's going to really put a strain on that receive buffer and make it hard for an application to drain the buffer before it need to cycle to keep up.

Showeq requires the full stream to run right now. Dropping packets makes for bad things (tm). So you need to figure out how to make things work.

Increasing your net.core.rmem* will raise the size of the receive buffer giving applications more time to drain the buffer before it cycles itself and loses packets. But if the problem is so severe that you can't get it going with a non-obscene value on net.core.rmem*, you might want to solve the problem another way by makeing your linux box see less traffic. You can do this either through tighter pcap filters or changing your physical network layout.

If you have not tried setting an ip address for seq, I'd try that (pass --ip-address=[ip of eq client machine]). This will cause the pcap filter to only access packets to/from that ip address. You might also try realtime on your network thread (though I've never used this) by passing --realtime to showeq. This should help the packet capture thread get more CPU time so that it has more of a chance to drain the buffer before it fills up.

You need to make sure that nothing else is sniffing the network on this machine too. Even if showeq's pcap filter is tight (with session tracking + --ip-address, it should tighten down to host and client port which will only be EQ traffic), if something else has a loose pcap filter, the kernel needs to fill the receive buffer with what the loosest demands.

Worst case, you can relayout your network so that the traffic from the other machines doesn't get seen by the showeq box. Whether this is reasonable or not is up to you.

I hope some of this helps you.

[uRit1u2CBBA=]

Dear Purple,


Looks like someone else landed in the same naming glitch that I landed in . :) lol

[ThanosOfTitan]

I think this is my problem, just bought a new hub. Question is, how can I tell what speed my Fedora Core box is running at so I can switch (probably a bad chouce of words) my windows box to match?

[tanner]

mii-diag?

# mii-tool
eth0: no autonegotiation, 10baseT-HD, link ok
SIOCGMIIPHY on 'eth1' failed: Operation not supported
SIOCGMIIPHY on 'eth2' failed: Operation not supported

# mii-diag
Using the default interface 'eth0'.
Basic registers of MII PHY #24: 3000 782d 0041 6800 05e1 0021 0004 2001.
Basic mode control register 0x3000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
Your link partner is generating 10baseT link beat (no autonegotiation).
End of basic transceiver information.

[BlueAdept]

I think this is my problem, just bought a new hub.

That is probably your problem. I don't think that true hubs are made anymore. Everything I have seen for sale are switches now. If it is a switch your won't see the traffic.

Most hubs/switches I have seen have different lights to show if it is connected at 10mb or 100mb (mine it is red for 10mb and green for 100mb (mine is a switching hub it acts as a hub if all the same speed and a switch if different)).

[ThanosOfTitan]

I ran it by a friend who has more unix ability than me and he suggested mii-tool. Testing out now if that fixed it

eth0: negotiated 100baseTx-FD flow-control, link ok
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

[tanner]

I do not know of many (if any sold any more) 100BaseT hubs, so I'd lean towards you got a switch.

[Tor K'tal]

eth0: negotiated 100baseTx-FD flow-control, link ok

FD in the 100baseTx-FD stands for Full Duplex. By nature hubs are only 1/2 duplex devices

Full Duplex = Transmit and Recieve at the same time
Half Duplex = Transmit or Recieve at a time, not both

While there are some FD Hubs out there, they really are a type of switch that broadcast to every port (so hub like still).

More than likely it's a switch, but I thought he commented on getting data in the console... or did I miss understand what was said earlier? So the question would seem to head toward; does he have a bad switch that is producting his data or does he have a bad hub that is corrupting his data OR is it something completely different?

~ TK

[purple]

I think the problem was that someone took over a post that had nothing to do with their problem stating "I think this is my problem, just bought a new hub" when really that has absolutely nothing to do with the thread!

[Wr6TAG7ju1I=]

Dear Purple,

You're right. Someone did hijack the thread.

And, I am still have problems with the:

Debug: SEQ: Giving up on finding arq 007b in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 007c in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 007d in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 007e in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 007f in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0080 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0081 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0082 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0083 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0084 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0085 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0086 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0087 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0088 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 0089 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 008a in stream zone-client cache, skipping!
Warning: Oversized packet fragment requested buffer of size 0 on stream 3 OpCode
0000 seq 00a6
Debug: SEQ: Giving up on finding arq 00ae in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00af in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b0 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b1 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b2 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b3 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b4 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b5 in stream zone-client cache, skipping!
Debug: SEQ: Giving up on finding arq 00b6 in stream zone-client cache, skipping!
Warning: !!!! EQPacketFragmentSequence::addFragment(): buffer overflow adding in
new fragment to buffer with seq 00fb on stream 3, opcode 0000. Buffer is size 3
8302 and has been filled up to 38302, but tried to add 505 more!

A lot of times, after I getting this display, ShowEq also crashes. As I said earlier, I have used ShowEq since 4.x.x days, but I am really mystified over this one. And, as I said earlier, I am running one cable line from Comcast into a D-link DCM-100 cable modem . The link from the DCM-100 goes to a D-Link DI-604 router (they call it a Residential Gateway) and that line feeds into an eight port Kingston KNE8TP/WG hub and all 8 ports are used. I do have people using Ventrillo and such, so I am not quite sure how I can re-wire things so that the hub only sees the traffic on one WinXP EQI box as opposed to all eight.

Any ideas?

[purple]

I explained exactly why showeq crashes and what the problem most likely is in post #9. You need to figure out how to solve it. I recommended like 6 things to you. Did none of them work?

You can keep saying "but I've used showeq for a long time!" all you want. The network layer changed drastically in January of this year when Sony significantly changed the underlying protocol.

I explained everything I know about this as clearly as I could in post #9. It's not really a showeq problem. It's a linux problem that manifests itself in showeq because showeq needs perfect packet monitoring but isn't getting it. If someone knows more about pf_packet and/or pcap that can make this work better, I'm all for it!

[purple]

Hmm, maybe try upping net.core.netdev_max_backlog too. Try like 3000 or something.