In doing a system upgrade that included upgrading: pptpclient from 1.4.0 to 1.5.0-r1 net-tools-1.60-r9 to 1.60.r11 My pptp connection to a pptpd server (also running gentoo) would no longer work. The problem was that GRE packets didn't reach either end. I did a tcpdump at both ends and could see 10:13:51.952870 IP 172.16.40.88 > xx.xx.xx.xx call 0 seq 2 gre-ppp-payload at both ends, but did not see the packets arrive. Setting debug for pppd gave: sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x831eb4d> <pcomp> <accomp>] repeated 10 times (at both ends) before both ends would give up with LCP: timeout sending Config-Requests I know this sounds like a routing problem, but the connection worked fine immediately before the upgrade, and doing emerge net-tools-1.60-r9 fixed the problem. I've tested with both versions of pptpclient (1.4.0 and 1.5.0-r1) and it makes no difference ie both versions work with net-tools-1.60-r9 and both fail to connect with 1.60-r11 Reproducible: Always Steps to Reproduce: 1.Setup working pptp configuration to a pptpd server with net-tools-1.60-r9 installed 2.Upgrade to net-tools-1.60-r11 Actual Results: Connection no longer works Expected Results: Connection should continue to work # cat /etc/ppp/options.pptp lock noauth nobsdcomp nodeflate mtu 1000 mru 1000 lcp-echo-failure 10 lcp-echo-interval 10 # emerge info Portage 2.0.51.19 (!/usr/portage/profiles/default-linux/x86/2004.0, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.11.2 i586) ================================================================= System uname: 2.6.11.2 i586 Pentium 75 - 200 Gentoo Base System version 1.4.16 Python: dev-lang/python-2.2.3-r1,dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 12 2005, 17:05:02)] distcc 2.16 i586-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-lang/python: 2.2.3-r1, 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=i586 -O2 -pipe" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=i586 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache distcc distlocks sandbox sfperms" GENTOO_MIRRORS="http://mirror.pacific.net.au/linux/Gentoo htttp://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2 -l2.8" PKGDIR="/var/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.au.gentoo.org/gentoo-portage" USE="x86 acl apache2 apm arts avi bitmap-fonts crypt curl emboss encode erandomexiscanacl fam font-server foomaticdb gif gtk2 imlib ipv6 kde libg++ libwww madmaildir mikmod motif mp3 mpeg mppe-mppc ncurses nls oav oggvorbis pam pdflib perl python quicktime readline samba sasl sdl slang ssl tcpd truetype truetype-fonts type1-fonts userlocales wildlsearch xml2 xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
I should add that the pptpd server being connected to is running net-dialup/pptpd-1.1.2-r1 (I am aware this is an old version but we have not been able to upgrade it due to other issues.)
My bad, it seems the problem was caused by upgrading to pptpclient-1.5. I'm not clear on the details as the problem was initially fixed by downgrading net-tools as described above. But then resurfaced and was only fixed after I downgraded pptpclient as well.
are you sure it is not a firewall problem? looks to me that you filtered important packages in INPUT chains. you should disable the firewall during the test. please take the usual precautions: emerge --newuse world rm ~/.revdep* revdep-rebuild
the reported didn't replied.
Positive it's not a firewall problem. The connection worked before upgrading and after downgrading with no changes made to the firewall. (latest portage sync broke my portage, I'll try the revdep-rebuild when I get it going again)
