BattleCom+EQ on same machine = Crashed SEQ

[gee]

Apparently Battlecom packets confuse SEQ and consistently cause it to crash.

Fixed it by changing the packet.cpp::decodePacket function to ignore any packets that contain the ip of the BattleCom server that I connect to.

Will probably change the code to exclude the following ports instead of just a specific ip. Not sure if this list of ports is complete, just pulled it off some random web site.

IN UDP 2300 - 2400
IN TCP 2300 - 2400
IN UDP 47624
IN TCP 47624

From looking through the documentation I couldn't tell if there was any kind of port/ip masking settings in SEQ. If there isn't, I'll add it.

After all that, the question is: Does SEQ have a way to exclude certain ports/ips from being processed?

[high_jeeves]

Problem is, EQ can use UDP ports in the range of 2300-2400, so disabling these ports in SEQ could cause it to also miss EQ traffic. You are probably better off sticking with the IP filter, or adding a more specific packet level filter.

--Jeeves

[gee]

Yeah, the only worry I have about it is when I run a battlecom server. A couple of other people who I play with use dialup so I can't really make a list of client IPS to filter on.

Another approach would be to get a list of ips used by EQ servers and filter to only use those. That actually might work better in the long run.

So maybe add a new setting AllowedIPs?

It would look something like:

AllowedIPs = 10.21.224.23, 10.21.224.21, 10.21.224.28

If a packet didn't have one of those ips in the source or destination it would be filtered out.

[high_jeeves]

There is go guarantee that those IPS dont change.. so, I'm not so sure this is a great idea... can you image a help forum on the day they changed the IPaddr of a server?

I think the best solution is to take a look at the battle com packets, and find a way to reject them (other than IP addr or port).. they must have some header that is identifiable, or atleast differ from EQ packets in some way which they can be filtered out.

--Jeeves

[fryfrog]

sony has to have a HUGE ip range for their servers (read they have something like 1200 of them) so just look up one at arin.net and find out what iprange they own.

and allow the entire thing (like, say 64.0.0.0).

[gee]

Jeeves,

I think I'm a bit too lazy to sit down and figure out how to differentiate BattleCom packets from EQ packets.

Fryfrog,

I'll look in the ip range bit, that would pretty much nail it down pat for me :)

[gee]

Looks like the ip range is: 64.37.128.0 - 64.37.191.255

[gee]

If anyone else has the same problem, add the following lines of code to packet.cpp in the EQPacket::decodePacket function. If you don't understand C++ then don't bother trying to add the code because adding it at the wrong spot will probably cause a crash.

There will be NO step by step instructions coming from me on how to get this to work :P



bool bTossPacket = true;
if (packet.getIPv4Source() >= 0x40258000 && packet.getIPv4Source() <= 0x4025BFFF)
bTossPacket = false;

if (packet.getIPv4Dest() >= 0x40258000 && packet.getIPv4Dest() <= 0x4025BFFF)
bTossPacket = false;

if (bTossPacket)
return;


Maybe if I get motivated I'll add a setting and get the SEQ guys to merge it in. Not motivated today :P

[Mr. Suspicious]

adding it at the wrong spot will probably cause a crash.

Or even worse, it won't crash *shivers at the thought*

[high_jeeves]

Might reduce overhead a bit by doing:



if ((packet.getIPv4Source() & 0xFFFFC000 != 0x40258000) && (packet.getIPv4Dest() & 0xFFFFC0000 != 0x40258000))
return;


Check my math, but that should mask off correctly...

--Jeeves

[gee]

Yeah, slap that baby in a 8051 and we are good to go! :D

[high_jeeves]

Just trying to save some cycles... If I had to guess, I'd say battlecom is a network hog, so you will be rejecting packets frequently...

--Jeeves

[devnul]

good work, this is something i've actually been meaning to do for a long time..

i've bracketed the code so ppl can see where to put it

...
emit numPacket(++m_packetCount);

//*** begin new code ***
if ((packet.getIPv4Source() < 0x40258000 || packet.getIPv4Source() > 0x4025BFFF) &&
(packet.getIPv4Dest() < 0x40258000 || packet.getIPv4Dest() > 0x4025BFFF))
return;
//*** end new code

if (showeq_params->logAllPackets)
...

to be safe i put it after the packet count increment but it probably could go before that

as long as the ip's dont change this can only help lessen seq's confusion and load

dn

[devnul]

oh good call.. use jeeves conditional not mine

his reply slipped in before mine;)

dn

[gain]

does anyone know, off hand, if this fix will work with the most recent packet.cpp? i poked around in it and didn't see where this could go. i imagine a lot has changed since then

i have the same problem, am adding a 2nd nic to my doze machine, mucking with routes and adding an ip to my gateway to route all battle com traffice through to avoid it mucking up seq... this should "fix" the seq crashing issue, but seems way overkill ;)

here is my post (http://seq.sourceforge.net/showthread.php?s=&threadid=1907) regarding the topic from a while back

thanks for any input

[high_jeeves]

I havnt confirmed this, but it should... The exact diff might have changed, but placing the conditional in a similar place in packet.cpp should have the same effects.

--Jeeves

[gain]

thanks, high_jeeves

i put it in the same place (right after the packet count increment), compiled and am now testing.

seq is working ok. just need my pal to wake up so we can test the bcom software

we did make a realization when talking about this again today. he was not affected by seq crashing when he ran the bcom server or otherwise. we determined a difference that seems a possible culprit in some way. he is using ipchains on his gateway to NAT bcom traffic to his pc and i'm using iptables.

i wonder if iptables NAT is doing something to his incoming bcom packets on my end that seq is barfing on but ipchains doesn't on his end. something else to ponder

[gain]

tried the suggested patch and as soon as my friend started talking (and, thereafter, even if he wasn't talking -- just his client attached) seq crashed immediately with this error over and over:

INVALID PACKET: Bad CRC32 [xx.xx.xx.xx:2350 -> 192.168.1.4:2350] seq 0291 len 4 crc32 (96b96d16 != 2ce4697b)

the "0291" and the "xxx != xxx" numbers change per line, fills a screen, then seg faults. the number following "len" flips between 1 and 4

if any of that helps. this is with the fix installed in packet.cpp