What is this Invalid Flag Combination?

How can I fix this invalid flag combination? I am runnig comodo, nod 32, peerguardian2 6c, bitcomet and opera. All at the same time.

Port 12446 is the one used by bitcomet.

Please help.


There’s some setup advice for Bitcomet on their forums here which may be relevant.

There's some setup advice for Bitcomet on their forums here which may be relevant.

This topic is not even close to what I need. Canyouseeme.org can see me just fine.


An identical question in an earlier topic


Either a badly written remote user fileshare client, or a clumsy attempt to shape traffic. Properly written TCP/IP stacks don’t put that combination of flags together.









From the first two pictures it can be seen that I have two IP adress but I think it is ok since I am using a modem and voip/router.

But look at the 3rd and the 4th pictures [comodo screen shots], the source and the destination are both using my own adresses. Note: Distination has different port for different log.

Can this thing be fix or Is it normal that it’s blocking something? If you need more informations or screen shots just let me know and I will post it here.


Your picture 3 shows destination port 1903, and picture 4 shows destination port 1943. Source address is your Internet address, destination address is your LAN address behind your NAT/router.

That is not normal traffic. I’m an eyeblink away from calling it hostile. A pair of packets alone does not necessarily make an attack, but a spoofed source address (your Internet address, in this case) is decidedly unfriendly. If you are seeing packets like this in volume, then something is definitely wrong somewhere.

One thing though, is that this is getting past your NAT/router. What kind of router is it (make and model)? It might have some ability to block some of this buried down in its configuration settings.

Behind my modem is Linksys SPA 3102 for voip. Just let me know if you need more screen shots of linksys. Here is the link and screen shot:



Another comodo screen shot. Log filled up with the ■■■■:


I think we can say this traffic is hostile.

I’ve downloaded and done a real fast eyeball read of the SPA3102 user guide. Nothing immediately obvious stands out as a security setting to change.

I’m suspecting this is related to VoIP oriented attacks that have been in the security news forums over last few months. Evidently somebody has discovered a particular structure of malformed packet can be passed thru the router, and used to deliver something to a host on a LAN. My guess is that the packets that CFP is logging are scan attempts to locate a host to infect. Since CFP is blocking the packets, the scan isn’t finding anything, so the search widened, and you’re seeing more and more log entries.

To cut down on the log traffic, I’ll suggest adding a CFP rule to block, and not log, all traffic inbound from your Internet address. Something like this:

block protocol IP from to any

You can still access your router by using its LAN address of And I’d suggest changing passwords on your router. A good random password generator is at https://secure.pctools.com/guides/password/

I noticed in the SPA3102 User Guide there is an ICQ download feature. I’ll recommend that you check to make sure that is turned off. If somehow a password could be guessed, this feature could be turned on, and stuff downloaded to your machine.

That should help for the time being. Where the traffic is coming from is another question, as the source address is being spoofed.

To cut down on the log traffic, I'll suggest adding a CFP rule to block, and not log, all traffic inbound from your Internet address. Something like this:

block protocol IP from to any

I don’t have a permanent IP address, It keeps on changing every now and then.

I observe this thing just now. After 2 hours on line, not a single log appeared when bitcomet is shutdown but a soon as I opened bitcomet the log just keep on coming and filling up all the spaces.

Bitcomet is using port 12446. Any suggestion is worth trying.

Edit: I change the port of bitcomet but the log is still coming using port 12446.

I have another thread but I don’t have the slightest idea if it has some thing to with this problem.

I don't have a permanent IP address, It keeps on changing every now and then.

It would probably be easiest to block a range of addresses, as IP assignments usually don’t change all that much. Something like this:

block protocol IP from range to any host

If you get assigned an IP address that is not in that range, just add another rule using a new range of x.x.x.0-x.x.x.255.

After 2 hours on line, not a single log appeared when bitcomet is shutdown but a soon as I opened bitcomet the log just keep on coming and filling up all the spaces.

That would imply that the source of all this is coming from a remote fileshare client, that becomes aware of when you are and are not running bitcomet. I would guess that the remote client is a malware zombie host of some kind.

I did a quick look at your other topic, but haven’t gone thru those rules in any kind of detail. I’ll get back to you on that. It just may be some bit later in the day.

I guess you should contact Linksys tech support and ask them why your router doesn’t apply ingress filtering on your WAN interface.

Having had a few moments between dayjob craziness today, it occurred to me that these may not actually be spoofed packets. The reasoning may be a little convoluted, but goes something like this.

A packet comes in from the Internet. It is sent to a port on a Linksys router that is being forwarded internally to LAN host. The packet is malformed, with certain TCP flags set.

The router does it’s NAT thing, changing the destination address to the LAN host. Because of the malformed packet, it forwards the packet to the LAN host. The LAN host replies, the router gets the reply, and like a good NAT box, sends the reply back to the original sender.

Otherwise, sending a packet to a host with varying ports, and not the one being forwarded, does really gain anything as there can’t be a reply back. That would imply someone has found a firmware bug, and is exploiting it, or at least trying to.

Since this particular Linksys router is fairly new, and is at firmware release 1.0, there doesn’t seem to be an update or patch available.

If we could capture the packets on the Internet side of the router, it’d be easy to confirm or deny the spoofed packet, and how it’s getting thru the router. Packet capture on the Internet side is not something I’d recommend trying.

Gibran is right though, in that Linksys should be contacted. I’d suggest thru the Linksys support web pages, and given them a pointer to this topic so they have a chance of understanding what’s going on.

Yep but the issue is that the source IP is lomayok WAN IP address.
This should mean that some peer is spoofing his public IP.

So long as the router isn’t doing some mixed up address translation, you’re correct. A malformed packet may be tripping some boundary test condition that is causing the router to do a NAT, but do it incorrectly. If so, that’s a bug in the firmware.

There was another topic about this invalid flag combination https://forums.comodo.com/help/invalid_tcp_flag_rule_before_network_rules_in_processing_order-t2684.0.html;msg20544#msg20544 but the souce IP was usually from another peer.

That topic is informative. Thank you.

In that other topic, one thing that shows in the posted CFP logs, is that the destination ports are in numeric order as time goes by. And each fileshare peer that has several log entries seems to always use the same source port. That’s not all that obvious in the way the text mode logs are written, but if laid out in a table format (like a spreadsheet) the sequence becomes much more obvious.

The suspicious thing here that lomayok is encountering is the source address being the NAT/router Internet IP address. If the ports are in ascending numeric sequence, it would lend support to this being just a router firmware bug, and not something malicious.

Easy enough to find out, if lomayok would post a log export.

I’m much more biased toward a spoofed IP. Anyway whatever the real reason is. it is clear tha a patch is needed.
Linksys should know if there is ingress filtering. Either it should be possible to test this sending a spoofed packet over the internet.

Anyway if ingress filtering is in place then I guess the only explanation is the one you suggested.