Re: RV325 xt_TCPMSS error

adaniel95 · ‎01-06-2016

Hello,

I have owned an RV325 for the past 3 weeks now, and it's been running great. However, yesterday (1/5/16) I began getting this error in the incoming log, "kernel: xt_TCPMSS: bad length (320 bytes)." This happens several times per day. I have tried rebooting the router, modem, and the wireless access point connected to it, however this doesn't solve the issue. I have not introduced anything new on the network, and my network configuration has remained the same.

Any help would be greatly appreciated.

Thank you

invictus-tech · ‎02-17-2016

Hi adaniel95,

I also have a RV325 and started having the same problems as you are having about a week ago. I think its either bad hardware and i need to replace the router (although its less than 6 months old), or more likely related to a firmware upgrade i did last week to v1.2.1.14

did you recently do a firmware upgrade ? to what version ? what was your previous version ?

Glenn Martin · ‎02-19-2016

Hi invictus and adaniel.

I will explore this and update you on this post.

Glenn

SMB Community Manager

invictus-tech · ‎02-29-2016

Hi Glenn,

Just wondering what you found in your research .....

invictus-tech · ‎03-30-2016

thanks glenn,

some updates and more info. i replaced the cisco rv325 with another rv325 and still getting the xt_TCPMSS bad length errors. so, this indicates it's not bad hardware but something to do with the firmware. i can not remember for sure if i updated the firmware for sure (i have other customers with cisco equipment) and if i did, not sure what the previous version was. about once a week the router dhcp server stops giving out ip #'s and i have to reboot it, so i assume this is related some how to these errors. the only thing connected to the rv325 router is two cisco aironet 3602i access points (static ip's). previously, i had two cisco aironet 1142N access points. the best i can tell the errors started after i upgraded to the cisco aironet 3602i access points, but also, i think may have i did a firmware upgrade to cisco rv325.

i think the cisco rv325 firmware is some kind of linux based kernel. tonight, i did some research and found a programmer discussion on this xt_tcpmss bad length error in the context of a linux kernel of some other router firmware. although i am not a programmer, from what i can tell from reading the discussion is that the error is caused by a bug in the code of the router firmware and the solution is to make a change in the firmware code. all the symptoms discussed appear to match the issues with the cisco rv325 router.

here is a partial excerpt, but please read the full discussion from the the link below and let me know your thoughts.

http://www.gossamer-threads.com/lists/linux/kernel/1179515

The TCPMSS target is dropping SYN packets where:
1) There is data, or
2) The data offset makes the TCP header larger than
the packet.

Both of these result in an error level printk.

This change fixes the drop of SYN packets with data
(because the MSS option can safely be modified) and
passes packets with no MSS option instead of adding
one (which is not valid).

http://www.gossamer-threads.com/lists/linux/kernel/1179515

Erik F · ‎10-01-2016

Same story. Any updates?

Running firmware:

v1.3.1.12 (2016-04-27, 10:46:12)

cbjwthwm · ‎04-02-2017

I'm seeing the same thing about once a day on a RV130W running the latest firmware r22 from late 2016 as well. Sometimes I see three of them in a row, with inconsistent lengths when they occur.

ctilexcom · ‎04-22-2017

Has a fix been found yet? Is anyone from Cisco watching this site?

Phil Trubey · ‎05-18-2017

This is the firmware stating that it received an improperly formatted TCP packet. It is probably a hacker probing the router to see if it can breach the router's security. Presumably the router's firmware handles this correctly (discards the packet) without any harm.

rvatalaro · ‎07-18-2020

I started getting these recently (yesterday, 2020-07-17). I am running VERY OLD firmware because at one point a Cisco "upgrade" caused the router to break. I was able to rebuild it (with the help of having saved the configuration and old firmware). I have not upgraded since. I tried rebooting the RV325. No luck -- a message appeared later. The messages I've been receiving are one of these:

kernel: xt_TCPMSS: bad length (589 bytes)
kernel: xt_TCPMSS: bad length (219 bytes)

The ONLY thing I can think of that forced this was I "upgraded" some Ubiquiti UniFi equipment. My RV325 is downstream of the Ubiquiti UniFi equipment (a so-called Security Gateway, or USG: basically a semi-fancy router with a firewall). It's also possible that hackers are just now trying something new, so any Ubiquiti change is just a coincidence. However, if a lot of others are using Ubiquiti and changed the S/W recently...

rvatalaro · ‎07-21-2020

I'll reply to myself. Ya know, I don't know who reads these things, but complaints here in my experience tend to server no useful purpose with Cisco. Now, Cisco is supposed to be a world leader in networking. How can they be that with all the STUPID BUGS in their S/W? Take the RV325. I own one (obviously?). I had to revert my firmware two times in a row because of bugs and/or undesirable incompatible changes. But just to see if this problem somehow went away with a firmware update, on a provisional basis I installed the current RV325 firmware. All seemed to work. I looked at things. All seemed OK. But still, in the back of my mind, I kept thinking, what was wrong last time? Is it fixed!? And then I went to refresh the Incoming log. I see others seem to have no complains about that. ON MY RV325, the incoming log did not "refresh." The last entry stayed the same -- no update. I then saved the current log (with copy and paste) and emptied the log. Then to my amazement, I started getting log entries. It seemed I had no reason to deinstall this firmware! Yeah! And then later I refreshed the log. THE NEW LOG ENTRIES ALL HAD THE SAME TIMESTAMP AS THE FIRST LOG ENTRY! ARGH! Something as simple as timestamping log entries was SCREWED UP by some pathetic programmer at Cisco. IT USED TO WORK! HOW DOES THIS COMPANY STAY IN BUSINESS? I have tried to submit error reports, but I cannot. They won't let me. Even though I am a valid home user, all I can do is rant in this forum, where Cisco persons sometimes contribute and maybe even try to work on a fix. I wouldn't know. I don't think I've ever seen one. So now I have to decide -- drop back to firmware (which will require re-applying the config) so I can have a sane log or leave it as is, not caring about timestamps. I CARE ABOUT THESE LOG ENTRIES, but maybe the time is not that important. It doesn't excuse the lame regression Cisco did. And now it will be end-of-life. It's already half-dead, thanks to Cisco programming.

rvatalaro · ‎07-22-2020

A final reply. I am running v1.3.2.02 (2016-09-23, 15:17:06) because all (three that I found) subsequent firmware versions have bugs and/or regressions that make them unusable for my needs. I have no hope of support from Cisco.