WinGate 6.1 - Checksum failure

[CatMix]

W2k SP4, WG 6.1, KAV 2.0
Ethernet Intel PRO/100+, LinkSys WAG54G (ADSL gateway) //MTU 1500

In Firewall it is a lot of messages Checksum failure. What it can be? It is possible-whether to disable somehow this check if there is no decision?

[adrien]

Hi

In these packets, what is the protocol and destination port?

Are these packets coming from your LAN, or from the Internet?

Adrien

[CatMix]

Hi

In these packets, what is the protocol and destination port?

Are these packets coming from your LAN, or from the Internet?

Adrien

Checksum failure packets coming only from Internet.
From 80, 443, 110, 53 (TCP/UDP), 21 ports.

[xwray]

W2k SP4, WG 6.1, KAV 2.0
Ethernet Intel PRO/100+, LinkSys WAG54G (ADSL gateway) //MTU 1500

In Firewall it is a lot of messages Checksum failure. What it can be? It is possible-whether to disable somehow this check if there is no decision?

I occasionally get the same message...mostly coming in on on port 80. My guess is that jerks are trying to get into your system and compromise it.

[CatMix]

W2k SP4, WG 6.1, KAV 2.0
Ethernet Intel PRO/100+, LinkSys WAG54G (ADSL gateway) //MTU 1500

In Firewall it is a lot of messages Checksum failure. What it can be? It is possible-whether to disable somehow this check if there is no decision?

I occasionally get the same message...mostly coming in on on port 80. My guess is that jerks are trying to get into your system and compromise it.

It appears from sites on which inquiries have gone.

[adrien]

Hi

Can you tell me what is in the flags column for these packets? You may need to enable viewing that column - right-click on the firewall window, choose "select columns", and select flags.

Most likely these are late RST packets coming in on a previously closed connection.

Adrien

[CatMix]

Hi

Can you tell me what is in the flags column for these packets? You may need to enable viewing that column - right-click on the firewall window, choose "select columns", and select flags.

Most likely these are late RST packets coming in on a previously closed connection.

Adrien

A ~ 75%
AP ~ 15%
FAP ~ 3%
null ~ 7% (only UDP)

It is especially appreciable in time downloadings of files, checksum failure falls constantly. I have specially put Intel PRO/100 + with the hardware flow control of frames.
It is not trusted that frames really bad.

[xwray]

In my case the flags were either A, S, or in a few cases SA. What do the flags indicate? It also looks like the majority of the IPs that were trying to get in were located in China.

[adrien]

S = SYN (synchronise - used to set up the connection in the first place)
A = ACK (acknowledge - used to acknowledge data sent by the other end)
F = FIN (Finish - used to close the connection)
R = RST (Reset - used to hard-close / terminate brutally the connection)
P = PSH (Push - used to indicate that the data should be pushed to the application)

Do you have Checksum offloading enabled on your network adapter?

Adrien

[xwray]

It doesn't appear that this card (IBM Netfinity10/100) has such a setting, at least it doesn't appear under the card's properties.

[CatMix]

Do you have Checksum offloading enabled on your network adapter?

Adrien

I not see checkbox TCP Checksum Offload. I don't know checksum offloading enabled by default.

http://www.intel.com/network/connectivi ... dapter.htm

[xwray]

Hi...it doesn't seem to me that this question was ever finally answered...is it now considered a dead issue? I would still like to understand what the checksum error actually means - is it a result of a penetration attempt or is it a hardware or software problem?

thanks

[adrien]

Basically it means that the packets were dropped due to having a bad checksum.

This can happen if the packet was corrupted in transit, or sent incorrectly, or in some cases where there may be an intermediate NDIS driver in your network stack that is messing with the checksums.

If received on the wire with a bad checksum, the rule is to drop the packet. We always did this before, but I figured we shouldn't drop packets without some notification, so I added the notification into 6.1

If there is some piece of software on your system that is breaking checksums, then that could cause good packets to be dropped. It is always possible there is some sort of exploit attempt being made as well.

Are you getting any complaints of people not being able to connect to you?

[xwray]

No complaints nor do I see anything untoward. I probably won't see more than a dozen such messages in a 24 hour period and almost always on port 80 from an IP most always in china. I would imagine if I had a software or hardware issue I would be seeing a lot more....

thanks

[genie]

WIngate behaviour changed a bit with 6.1 in regard to handling checksum failures - before 6.1 Wingate simply dropped the packets while in 6.1 it started reporting them - that's why it shows all these "Incorrect checksum" hits. If the number of dropped packets is low, there is nothing to worry about. If it becomes a stream of errors, then it is either a hardware fault somewhere on the line (interference) or it might indicate an attempt to attack the server.

[CatMix]

Basically it means that the packets were dropped due to having a bad checksum.

This can happen if the packet was corrupted in transit, or sent incorrectly, or in some cases where there may be an intermediate NDIS driver in your network stack that is messing with the checksums.

If received on the wire with a bad checksum, the rule is to drop the packet. We always did this before, but I figured we shouldn't drop packets without some notification, so I added the notification into 6.1

If there is some piece of software on your system that is breaking checksums, then that could cause good packets to be dropped. It is always possible there is some sort of exploit attempt being made as well.

Are you getting any complaints of people not being able to connect to you?

It is good idea, but you could add item in menu Firewall to not show checksum failure?

Clear All
Copy to Clipboard
Edit Columns
* Show Checksum Failure

Thanks.