Can´t solve buffer overflow on wireless card

[myxiplx]

Ok, bear with me here, I´ve only been using Linux for about 2 weeks and while I´ve finally gotten ShowEQ running, I can´t solve these buffer overflow messages I´m getting.

I´m running Ubuntu 6 (Dapper Drake), I´ve tried following the guidelines in the FAQ and increasing the buffer values, but even doubling the figures there doesn´t help. Regularly when I either zone, or cast an Aura, ShowEQ will crash. I´ve researched both problems, for the aura thing I tried copying the latest spell text file across too with no luck.

The two errors I get are:

Error 1
=====================
Warning: SEQ: Giving up on finding arq 02a7 in stream zone-client cache, skipping!
Warning: SEQ: Giving up on finding arq 02a8 in stream zone-client cache, skipping!
Warning: !!!! EQPacketFragmentSequence::addFragment(): buffer overflow adding in new fragment to buffer with seq 02d6 on stream 3, opcode 35c0. Buffer is size 77302 and has been filled up to 77261, but tried to add 505 more!

Error 2
=====================
Spell: You begin casting Aura of Insight. Current Target is (0)
Info: SpellItem 'Aura of Insight' finished.
Spell: You begin casting Selo`s Song of Travel. Current Target is (0)
Warning: SEQ: Giving up on finding arq 0129 in stream zone-client cache, skipping!
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
Aborted

I´ve added the following lines to /etc/sysctl.conf:
net.core.rmem_default=524288
net.core.rmem_max=2097152
net.core.wmem_default=524288
net.core.wmem_max=2097152
net.core.netdev_max_backlog=3000

And ¨sysctl -p¨ or ¨sysctl -a¨ show that those values are configured, but the error is saying that the buffer size is only 77302.

I´m guessing there´s a setting somewhere I don´t know about, I tried adding the wmem parameters in case that helped with this being a wireless link but without knowing what I doing I´m really just guessing here.

any and all advice appreciated, even if it´s just enough to push me in the right direction.

Ross

[purple]

The buffer the seq messages are talking about is different than the buffer the operating system is using for storing packets. The seq buffer that is overflowing is working to reconstruct fragmented packets. But because packets are being dropped, the fragments couldn't be reconstructed properly, so the sizing did not work out and a buffer overflow occurred.

If packets are getting dropped, you have to do something to make this stop. Make sure you are using session tracking and have followed the instructions in the FAQ. If your local network is busy, you can use physical connections to help limit the amount of traffic your linux box is seeing. Any lessening of the number of packets that are being sucked in by your network card in promiscuous mode will help.

[myxiplx]

I´m already doing everything I can find documented to reduce the number of packets. I´m only monitoring one IP address and have session tracking turned on. Once I´m in a zone showeq has no problems at all, I can stay in one zone for hours and it never crashes, this only happens when I zone.

The network in question isn´t busy at all, there are two EQ clients running and that´s it, on a 2Mbit DSL line.

Is there any way to increase the size of the showEQ buffer, or anything else I can do to help this?

[purple]

Is there any way to increase the size of the showEQ buffer, or anything else I can do to help this?

That statement makes absolutely no sense.

When you zone, you receive a lot of packets in short period of time. Your operating system is dropping packets before showeq has a chance to request them to process them. So showeq is not seeing the full network stream.

Without the full network stream, showeq cannot reconsistitute large datagrams that are fragmented across multiple protocol packets. I'm lazy, so instead of gracefully handling this and letting you know that thnigs are screwed up and you have to zone to refix them, it crashes while shoving a fragment that doesn't belong onto the incomplete large datagram it was trying to rebuild.

So, what you need to do is one of:
1) Make showeq pull packets out of the operating system receive packet backlog buffer faster
2) Make the operating system receive packet buffers larger if you are filling it up, or make it the backlog hold packets longer if they are timing out
3) Make the operating system receive packet backlog not see as many packets in the first place

[myxiplx]

Hmm... so it could still be related to the network buffer settings then?

I don´t think I can do much about 1, I´m running showEQ on a laptop so upgrade potential is limited. Having said that I´m not seeing 100% cpu usage so I don´t think it´s a performance thing.

Ditto for 3, I doubt there´s much I can do to reduce the packets it´s seeing, especially if EQ sends a lot of packets while zoning.

So it looks like 2´s my only option. I´ll try increasing the OS packet limits again and see if that helps.

thanks,

Ross

[myxiplx]

Hmm... pushed the values way over the defaults now and I´m still getting this.

Parameters are currently set at:
net.core.rmem_default=8388608
net.core.rmem_max=16777216
net.core.wmem_default=8388608
net.core.wmem_max=16777216
net.core.netdev_max_backlog=24000

Even with nothing else running on either computer and negligable CPU usage on the laptop ShowEQ is crashing with the error:

Warning: SEQ: Giving up on finding arq 01e5 in stream zone-client cache, skipping!
Warning: Oversized packet fragment requested buffer of size 0 on stream 3 OpCode 0000 seq 0220
Time: Sun Aug 12,3212 - 10:15 pm
Warning: !!!! EQPacketFragmentSequence::addFragment(): buffer overflow adding in new fragment to buffer with seq 02ba on stream 3, opcode 0000. Buffer is size 77302 and has been filled up to 77012, but tried to add 505 more!

Any suggestions?

[purple]

I'm super busy right now, but if you want to do a tcpdump and pm me an url where I can download it, I can tell you again that you're dropping packets and you need to get that fixed before you have any chance of ever running seq.

To do a tcpdump:

Login to EverQuest and sit at server select or char select
On your linux box do: tcpdump -i eth0 -s0 -w lookatmecrash.log 'udp && host 192.168.0.1' (where eth0 is your net interface and 192.168.0.1 is whatever the IP of your EQ client is)
Choose your server/char in EQ and go run around until seq crashes
Control-C the tcpdump
gzip lookatmecrash.log
Get lookatmecrash.log.gz to me somehow