1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

RV082 and Firmware 1.3+ don't like gentoo

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by BigHusky, Oct 26, 2006.

  1. BigHusky

    BigHusky LI Guru Member

    Very strange issue started to show up with any of the 1.3+ firmwares for the RV082. When using gentoo on a PC on the LAN behind the RV082 we can ssh to an outside ssh host. But as soon as we do any commands such as a ps ax we get a few lines scrolling and then the session hangs and has to be killed.

    We tried 4 other distributions and none of them has this issue. We also downloaded a gentoo live CD and it is behaving the exact same way.

    No issue with Firmware 1.1.x and also no issue with 5 other routers we swapped out to try. Tried various MTU's and a few sysctl settings to match the various distros.

    This is with Kernel 2.6.17 which I have also successfully tried in other distros.

    Any idea on where to even start looking. We have one developer who is on gentoo and currently we had to move him to a wireless connection on another network. Don't really want to go back to the 1.1.x firmware.

    Here is part of the tcpdump just before the hanging happens:


    Code:
    14:33:31.026545 IP 192.168.8.130.43808 > example.com.ssh: P 1861:1909(48) ack 1649 win 70 <nop,nop,timestamp 181136 857241295>
    14:33:31.035904 IP example.com.ssh > 192.168.8.130.43808: P 1649:1697(48) ack 1909 win 11392 <nop,nop,timestamp 857241425 181136>
    14:33:31.036037 IP 192.168.8.130.43808 > example.com.ssh: . ack 1697 win 70 <nop,nop,timestamp 181137 857241425>
    14:33:31.653614 IP 192.168.8.130.43808 > example.com.ssh: P 1909:1957(48) ack 1697 win 70 <nop,nop,timestamp 181198 857241425>
    14:33:31.665005 IP example.com.ssh > 192.168.8.130.43808: P 1697:1745(48) ack 1957 win 11392 <nop,nop,timestamp 857241488 181198>
    14:33:31.665186 IP 192.168.8.130.43808 > example.com.ssh: . ack 1745 win 70 <nop,nop,timestamp 181199 857241488>
    14:33:31.788494 IP 192.168.8.130.43808 > example.com.ssh: P 1957:2005(48) ack 1745 win 70 <nop,nop,timestamp 181212 857241488>
    14:33:31.800181 IP example.com.ssh > 192.168.8.130.43808: P 1745:1793(48) ack 2005 win 11392 <nop,nop,timestamp 857241501 181212>
    14:33:31.800333 IP 192.168.8.130.43808 > example.com.ssh: . ack 1793 win 70 <nop,nop,timestamp 181213 857241501>
    14:33:31.914175 IP 192.168.8.130.43808 > example.com.ssh: P 2005:2053(48) ack 1793 win 70 <nop,nop,timestamp 181225 857241501>
    14:33:31.937563 IP example.com.ssh > 192.168.8.130.43808: P 1793:1841(48) ack 2053 win 11392 <nop,nop,timestamp 857241514 181225>
    14:33:31.937692 IP 192.168.8.130.43808 > example.com.ssh: . ack 1841 win 70 <nop,nop,timestamp 181227 857241514>
    14:33:32.615539 IP 192.168.8.130.43808 > example.com.ssh: P 2053:2101(48) ack 1841 win 70 <nop,nop,timestamp 181295 857241514>
    14:33:32.625231 IP example.com.ssh > 192.168.8.130.43808: P 1841:1889(48) ack 2101 win 11392 <nop,nop,timestamp 857241584 181295>
    14:33:32.625382 IP 192.168.8.130.43808 > example.com.ssh: . ack 1889 win 70 <nop,nop,timestamp 181296 857241584>
    14:33:33.547813 IP 192.168.8.130.43808 > example.com.ssh: P 2101:2149(48) ack 1889 win 70 <nop,nop,timestamp 181388 857241584>
    14:33:33.560511 IP example.com.ssh > 192.168.8.130.43808: P 1889:1937(48) ack 2149 win 11392 <nop,nop,timestamp 857241676 181388>
    14:33:33.560666 IP 192.168.8.130.43808 > example.com.ssh: . ack 1937 win 70 <nop,nop,timestamp 181389 857241676>
    14:33:33.581805 IP example.com.ssh > 192.168.8.130.43808: P 1937:2017(80) ack 2149 win 11392 <nop,nop,timestamp 857241679 181389>
    14:33:33.581912 IP 192.168.8.130.43808 > example.com.ssh: . ack 2017 win 70 <nop,nop,timestamp 181391 857241679>
    14:33:33.584451 IP example.com.ssh > 192.168.8.130.43808: P 2017:2145(128) ack 2149 win 11392 <nop,nop,timestamp 857241679 181389>
    14:33:33.584532 IP 192.168.8.130.43808 > example.com.ssh: . ack 2145 win 79 <nop,nop,timestamp 181392 857241679>
    14:33:33.599892 IP example.com.ssh > 192.168.8.130.43808: . 2145:3545(1400) ack 2149 win 11392 <nop,nop,timestamp 857241680 181391>
    14:33:33.600017 IP 192.168.8.130.43808 > example.com.ssh: . ack 3545 win 100 <nop,nop,timestamp 181393 857241680>
    14:33:33.612002 IP example.com.ssh > 192.168.8.130.43808: . 3545:4945(1400) ack 2149 win 11392 <nop,nop,timestamp 857241680 181391>
    14:33:33.612099 IP 192.168.8.130.43808 > example.com.ssh: . ack 4945 win 122 <nop,nop,timestamp 181394 857241680>
    Thanks
     
  2. pablito

    pablito Network Guru Member

    Do you have the very latest firmware version? I had a similar problem on Centos and it was an MTU issue on ADSL. That is now fixed with the lastest version. If you are on PPPoE DSL you might try setting MTU to 1492 or lower. There are some threads about a Fedora issue with specific kernel versions which is a slightly different problem but could be what you are seeing.
     
  3. BigHusky

    BigHusky LI Guru Member

    Yup. Tried every firmware version up to the latest released one. Have a T1 connected to it. Tried various MTU sizes on both the RV082 and on Gentoo to no success.
    As mentioned, with other distros I don't have this problem. CentOS, RHEL, PCLinuxOS, Suse, Solaris 10/11 all work.
    So I even tried to match the sysctl net settings from the working OS's onto the Gentoo one to no success. On some of those other distros I even have matching kernel version.

    This is one of our main developers and is not going to use another distribution. At first I suspected it was just an issue with his installation.
    But then I went and downloaded the 2006.1 LiveCD and was able to reproduce the situation immediately.

    So it looks that we will have to downgrade the firmware to the 1.1.6.3 version when all OS's could connect.

    Thanks

    BH
     
  4. Toxic

    Toxic Administrator Staff Member

    does gentoo it have some sort of TCP scaling or large packet size feature at all perhaps?
     
  5. BigHusky

    BigHusky LI Guru Member

    So after googling for TCP Window Scaling it seems that the change in the Kernel happened between 2.6.7 and 2.6.8. According to multiple articles the change made us discover the broken routers. The workaround is to revert the scaling back to 0.

    What gets me though is that with the RV082 this only started to happen with the 1.3.3.x firmware releases. So Linksys/Cisco re-introduced a 'broken' behavior?

    Now I sure hope that this will be properly fixed in the next firmware.

    Thank you

    BTW: Here is just one such article:
    "... In the 2.6.7 kernel, the default scale factor is zero; in Linus’s BitKeeper tree and the 2.6.7-mm kernels, instead, it has been increased to seven. This change has brought the broken router behavior to light; suddenly people running current kernels are finding that they cannot talk to a number of systems out there. One of the higher-profile affected sites is packages.gentoo.org. Gentoo users are, unsurprisingly, not pleased. ..."
     

Share This Page