seq crashing - BFC related

[gain]

after updating seq last week, seq is crashing often. i identified a definite association and can reproduce the effect

a friend and i have used Battlefield Communicator (later versions entitled Battlecomm and eventually became some M$ product I believe. I will refer to it as BFC.) voice software for years as it works well and sounds good to boot. seq worked happily alongside it for a long time. when i recently upgraded my seq, it now crashes whenever BFC sends voice data

BFC is running on a windows machine. the ports forwarded for it's use on my firewall have been the same for years. after latest update, seq and BFC work just great until either of us speak. at that point, seq crashes instantly... often times with errors about bad packets to or from my BFC machine to my friend's BFC machine in the first forwarding range below (2300-2400).

BFC ports:
2300:2400 (udp and tcp)
28800:28900 (udp)
47624 (udp and tcp)

Notes:

I have updated and verified my libEQ.a

I have compiled with a fresh cvs pull.

I read the posts about the possibility of my hardware causing the problem. My eq and seq machines are in a netgear 10Mb hub off of my switch (switch is an older Kingston 1u rackmount retired from data center). both the seq machine and the windows machine (running eq and BFC) are communicating via NAT. i don't have any other reason to believe there is a problem with the network hardware than this.

I have compiled with and without suggested change: 'comment "#define PACKET_PEDANTIC 2" in packet.cpp'. This seems to make a difference for the better, but seq still eventually crashes

The two following back traces are from an unmodifed packet.cpp source and one with the PEDANTIC line commented out, respectively:


#0 0x08087fcf in EQPacket::decodePacket(int, unsigned char*) (this=0x81fe328,
size=46, buffer=0xbfffe50e "E") at packet.h:108
#1 0x080878ac in EQPacket::processPackets() (this=0x81fe328) at packet.cpp:810
#2 0x401eccea in QObject::activate_signal(char const*) ()
from /opt/qt-gcc3-2.3.2/lib/libqt-mt.so.2
#3 0x4023efa2 in QTimer::timeout() ()
from /opt/qt-gcc3-2.3.2/lib/libqt-mt.so.2
#4 0x40222a00 in QTimer::event(QEvent*) ()
from /opt/qt-gcc3-2.3.2/lib/libqt-mt.so.2
#5 0x401a928f in QApplication::notify(QObject*, QEvent*) ()
from /opt/qt-gcc3-2.3.2/lib/libqt-mt.so.2
#6 0x40175608 in qt_activate_timers() ()
from /opt/qt-gcc3-2.3.2/lib/libqt-mt.so.2
#7 0x40173230 in QApplication::processNextEvent(bool) ()
from /opt/qt-gcc3-2.3.2/lib/libqt-mt.so.2
#8 0x401ab33b in QApplication::enter_loop() ()
from /opt/qt-gcc3-2.3.2/lib/libqt-mt.so.2
#9 0x40172d98 in QApplication::exec() ()
from /opt/qt-gcc3-2.3.2/lib/libqt-mt.so.2
#10 0x080626b5 in main (argc=1, argv=0xbffff814) at main.cpp:937
#11 0x405dc657 in __libc_start_main (main=0x805f428 <main>, argc=1,
ubp_av=0xbffff814, init=0x805afb0 <_init>, fini=0x8174410 <_fini>,
rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff80c)
at ../sysdeps/generic/libc-start.c:129


#0 0x08087d5a in EQPacket::decodePacket(int, unsigned char*) (this=0x81fe598,
size=46, buffer=0xbfffe4ee "E") at packet.cpp:1064
#1 0x080878ac in EQPacket::processPackets() (this=0x81fe598) at packet.cpp:810
#2 0x401eccea in ?? ()
#3 0x4023efa2 in ?? ()
#4 0x40222a00 in ?? ()
#5 0x401a928f in ?? ()
#6 0x40175608 in ?? ()
#7 0x40173230 in ?? ()
#8 0x401ab33b in ?? ()
#9 0x40172d98 in ?? ()
#10 0x080626b5 in main (argc=1, argv=0xbffff7f4) at main.cpp:937
#11 0x405dc657 in ?? ()


Be glad to post anything else that might help. I will post actual error codes from seq prior to crash when I am at seq machine again.

Thanks

[high_jeeves]

The problem here is really quite simple, the solution however is a bit more complicated.

Your BFC broadcasts over ports which are in the valid port range for EQ. ShowEQ captures those packets, tries to decode them, and boom (my guess is, the BFC packets resemble a valid EQ packet, but I dont know that for sure).

A couple of possible solutions:

1) Modify the ports the BFC uses (not sure if this is possible)
2) Modify the ShowEQ code to be a bit smarter about ignoring the BFC traffic, or locking on a port, or something similar.
3) Use a telephone.

--Jeeves

[Cryonic]

I don't know if SEQ supports this, but if it does, then you might want to use BPF to keep SEQ from seeing the BFC data.

[gain]

Originally posted by high_jeeves
Your BFC broadcasts over ports which are in the valid port range for EQ. ShowEQ captures those packets, tries to decode them, and boom (my guess is, the BFC packets resemble a valid EQ packet, but I dont know that for sure).

A couple of possible solutions:

1) Modify the ports the BFC uses (not sure if this is possible)
2) Modify the ShowEQ code to be a bit smarter about ignoring the BFC traffic, or locking on a port, or something similar.
3) Use a telephone.

good suggestions. i'll see if BFC port use is user definable.

using a telephone isn't an option though. we live several thousands of miles from one another. ;) using the built-in, text communication is an option, but is, obviously, much less effective.

i may look into other viable IP based voice communication though if the seq/BFC issue isn't easily resolved. i'm not able to make those changes to seq myself (not at that level of programming by a long shot).

thanks

[Ratt]

I think there may be a decode problem that cropped up in the last couple commits.

I've noticed some wonky console output, which usually points to SEQ trying to decode packets that aren't meant for it, or the packet lengths being wrong (from what's expected).

This may or may not be all or part of your problem though.

[S_B_R]

Hmmm, "Wonky" That's must be a technical term I'm not familiar with ;)

[Mr Guy]

wonky

/wong'kee/ adj. [from Australian slang] Yet another approximate synonym for broken. Specifically connotes a malfunction that produces behavior seen as crazy, humorous, or amusingly perverse. "That was the day the printer's font logic went wonky and everybody's listings came out in Tengwar." Also in `wonked out'. See funky, demented, bozotic.
y.



Bozotic. Now THERE is a word we don't see enough.

[gain]

Originally posted by Ratt
I think there may be a decode problem that cropped up in the last couple commits.

I've noticed some wonky console output, which usually points to SEQ trying to decode packets that aren't meant for it, or the packet lengths being wrong (from what's expected).

That would seem to explain a lot if it is the case. I tend to think that might be the case. I had not trouble at all before upgrading.

Should have stuck to the "if it ain't broke, don't fix it" statement. hehe

Unfortunately, I do not have old cvs to rebuild seq with the latest libEQ.a. I pulled a new cvs version at the same time I pulled a new version of the lib just to keep everything up to date. Should have just pulled the lib I guess. :)

if i can provide any further information to help with a resolution, please feel free to ask. i'd be glad too

[fryfrog]

try the "cvs --help" option (specifically cvs -d i think). it will let you pull any "version" of showeq you want (by date). just figure out which date you wanna use and grab/compile it. i don't think libeq has changed in a while, so you should be able to go pretty far back.

[gain]

Originally posted by fryfrog
try the "cvs --help" option (specifically cvs -d i think). it will let you pull any "version" of showeq you want (by date). just figure out which date you wanna use and grab/compile it. i don't think libeq has changed in a while, so you should be able to go pretty far back.

cool. thank you for that tip. i hadn't updated either seq or libEQ for quite some time so I did get a new version of libEQ when I did go looking.

i imagine i only need to go back a few versions. i originally only updated seq and still had some pesky issues with decoding and whatnot. at that point i went searching for a new libEQ and found one. the combination of updating them both fixed most/all the issues i had been experiencing, but the whole thing went to pot when we fired upt BFC.

[Cryonic]

Would be interesting if ShowEQ supported BPF for stopping some stuff from even reaching the packet decoding engine.

showeq not port 2002-2004

or something. I have Snort running on some machines and I'm able to feed it BPF commands when I start it up.