Strange Invalid Packets

I have done a few mods for SEQ, none added to a diff, mainly because I am such a novice that IF i were to do it, and knowing how people here act to "idiots" I would have been slammed from one side of the moon to earth and back.

Besides the point.

I have a trace function I have put into SEQ that trys to check packets attached to outbound data.

I get it from SEQ.

INVALID PACKET: Bad CRC32 [192.168.1.7:1418 -> 64.126.90.137:3823] seq 0000 len 2 crc32 (5a614100 != 83a68812)
INVALID PACKET: Bad CRC32 [192.168.1.7:1418 -> 65.35.119.250:2930] seq 0000 len 2 crc32 (5a614100 != 83a68812)
INVALID PACKET: Bad CRC32 [192.168.1.7:1418 -> 24.218.34.117:1214] seq 0000 len 2 crc32 (5a614100 != 83a68812)
INVALID PACKET: Bad CRC32 [192.168.1.7:1418 -> 24.213.30.149:4729] seq 0000 len 2 crc32 (5a614100 != 83a68812)
INVALID PACKET: Bad CRC32 [192.168.1.7:1418 -> 24.247.250.161:2984] seq 0000 len 2 crc32 (5a614100 != 83a68812)
INVALID PACKET: Bad CRC32 [64.126.90.137:3823 -> 192.168.1.7:1418] seq 0000 len 3 crc32 (5a614100 != 1f6ac2ad)
INVALID PACKET: Bad CRC32 [24.218.34.117:1214 -> 192.168.1.7:1418] seq 0000 len 7 crc32 (0ca6001e != 4102615c)

Then Isolate the possibles, and block the IP's from recieving information .. HOWEVER.. My question is,

WTF is SEQ doing sending packets to those IP's?
(Edited:)
Using "Sniffit" I managed to gather some packets and now trying to decrypt the packets.

My goal is to secure SEQ from sending information to anyone. I have a firewall setup, I have a blocking code in my router. But I still would like to know what/who the EQ Game PC is talking to and why.

ShowEQ does not transmit, end of story.


fee

Yes. I am sorry. Meant about those packets from my EQ box.

And End of story? How curt. Not end of story, SEQ does Transmit, but only ACK and CD packets recieved back on Layer 2.

Nothing to do with what I meant to address, those packets that were being sent to other machines, is the ones I am looking at from my EQ machine.

Is there any way to check those packets?

Quote:

---

But I still would like to know what/who the EQ Game PC is talking to and why.

---

Um.. no really.. ShowEQ transmits exactly nothing. It is a passive sniffer. Look up some of those addresses.. they are your ISP..

--Jeeves

You should stop using seq immediatly.. Usually after you see this like a week later it will manifest itself into something like this:


INVALID PACKET: Bad CRC32 [192.168.1.7:1418 -> 64.126.90.137:3823] unable to get last four of credit card (5a614100 != 83a68812)
INVALID PACKET: Bad CRC32 [192.168.1.7:1418 -> 65.35.119.250:2930] seq was unable to log into bank account (5a614100 != 83a68812)
INVALID PACKET: Bad CRC32 [192.168.1.7:1418 -> 24.218.34.117:1214] seq beggining to try to take over the world (5a614100 != 83a68812)


WTF.....

SEQ does not transmit. Period. Ever.

With that said, the problem you are experiencing has been addressed (by me, no less) before.

The problem is you have a shitty NIC, cables, or hub. Search for posts by me about 6 months to a year ago.

I get theese all the time when I run seq on my vmware box as its virtual network card aint up to the job. As Rat said is prolly just a dodgy nic, cable or hub. As for your EQ client sending data to ip addresses err..... how else do you expect the servers to know what you are doing ???

I get the same thing BUT only when I open Kazaa on another PC on the same hub as my EQ machine is on. Sometimes SHOWEQ even seg faults when I start Kazaa.

Kazaa uses a port in EQ's range, and the packets look similar enough to EQ packets that SEQ tries to decode them, with disasterous results. :)

Trolling the boards trying to turn myself from a SEQ/Linux newbie into someone who knows something. Thread title looked interesting enough, so I decided to have a peek. The bit about Kazaa causing segfaults was unexpected, but extremely helpful. I've been getting segfaults and have had no idea why. Even my bro has been at a loss. Now I know to turn the thing off when I turn SEQ on.

-Thanks Bunches

..if your SEQ box is also your gateway/firewall, just "turning off" Kazaa won't be enough though.

Most Kazaa clients retry the IP addresses they were hitting for some time after you exit your client. If ShowEQ is on your gateway, then it will continue to see these packets and *still* segfault, until the third parties stop sending them to you.

This is perhaps one of the largest disadvantages to having showEQ on your gateway machine.

Depends on which interface you put into promisc mode. Since you shouldn't be having SEQ look at the outside interface, then users outside your network won't affect SEQ.

I was able to deal with Kazaa by using Session Tracking, but last I saw from Fee, Session tracking isn't working right.

Session tracking isn't working right?

Hm. Well, maybe it's not working right as far as the code goes or in some weird situations, but on my linux box I've had up to four copies of SEQ running, each sniffing for seperate EQ sessions on the network, and session tracking seemed to be working fine for me.

Session tracking is the only way to keep seq from reading multiple EQ sessions' data and causing really screwy results.

This was right before the recent breakage.

I wonder what's not working about it.

were those 4 clients coming from the same machine?

Quote:

---

With that said, the problem you are experiencing has been addressed (by me, no less) before.

---

ACK and CD requests are still transmitted , Ratt. Any decent Packet Analyzer, "Sniffit", "Ethereal" or other known Protocol/Port analyzer can "see" them.

ACK requests/responces on layer 2 are JUST ACKNOWLEDGE of Packet Recieves. It contains NO DATA and or Header/Trailer information. It is just an acknowledgement of "receipt of packet" that is requested by the sender (i.e. the PC running EQ)

Now that you have placed a "." period after your statement, I will place a ".." double period behind mine.

If you would like the "PROOF" of ACK and CD requests, I would more than happily oblige you since you are so ALL Knowing and Godly here.

Go flame elsewhere.. I asked a pertinent question to determine the actual packet information that is received during a SEGMENT FAULT, when SEQ crashes.

Your inconciderate nature denotes you as a one who deems themselves higher than those that mayhaps don't know the INS and OUTS of Seq. Therefore you have something or know something that others do not, and that gives you some sort of 'leverage' over qualifying your reasons to flame people.

I asked WHAT those packets where, that my EQ machine was sending ( erroneously adding the "S" before the EQ, however.. I do also see that after that little typo I stated :

Quote:

---

But I still would like to know what/who the EQ Game PC is talking to and why.

---

Now, you suggested that I have shitty network cables, cards.. etc.. tells me you know little about what those packets are.. I use multiple computers, 1 is a Laptop. They have ALL encountered this little packet issue after a SEG fault occurs.

Grow up and give a qualified answer before you decide to flame, and I am not searching around for a dumbass response you MIGHT have made from 6 months ago!!

So, Ratts a dumbass because you posted incorrectly? (by saying it was the SEQ machine sending the packets, instead of the EQ machine). I dont get that.. If you read your original post, IT IS WRONG.. That is why you get the reaction you did.. You claim that ShowEQ sends packets, that is what you said.. regardless of what you meant, we can only go by what your wrote... it was wrong.. you got told it was wrong.. its just that simple..

--Jeeves