This bug refers to bug #99099, please see detailed explanation why this is so odd there. Testing results: pppd-2.4.2-r12 + libpcap-0.8.3-r1 [pppd] error in active-filter expression: inbound/outbound not supported on linktype 0_ pppd-2.4.2-r12 + libpcap-0.9.3 (pppd reemerged against 0.9.3) [pppd] error in active-filter expression: snaplen of 0 rejects all packets pppd-2.4.3-r6 + libpcap-0.9.3 [pppd] error in active-filter expression: inbound/outbound not supported on linktype 9_ Used filter expression: active-filter 'outbound and not icmp[0] == 3 and not tcp[13] &4 != 0' Maybe this also affects pppd packages... Reproducible: Always Steps to Reproduce: 1. emerge pppd-2.4.3-r6 + libpcap-0.9.3 2. setup filter expression with inbound/outbound keyword 3. watch pppd fail Actual Results: no reliable idle detection due to incomplete active-filter support for ppp links Expected Results: detect only wanted packets for line activity with complete filter support on ppp links Gentoo Base System version 1.6.12 Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4. 20041102-r1, 2.4.31-grsec i686) ================================================================= System uname: 2.4.31-grsec i686 Pentium III (Katmai) dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.10 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentiumpro -fomit-frame-pointer -pipe" CHOST="i686-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="-O3 -march=pentiumpro -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/ distributions/gentoo" LC_ALL="de_DE@euro" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 activefilter bitmap-fonts bzlib crypt ctype dbm emboss erandom ethereal flatfile fortran ftp gdbm gnutls hardened icc ifc maildir mbox memlimit mhash m ime mmap mmx mp3 mysqli ncurses nls pam pcntl pcre perl pic pie posix readline r ecode sasl shared sharedmem slang sockets socks5 sse ssl sysvipc szip tcpd truet ype-fonts type1-fonts unicode zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
i think the folowing link could help you out (patch is included there) http://www.tcpdump.org/lists/workers/2004/11/msg00068.html
Thank you for pointing to the patch, it should be coordinated that pppd-2.4.3 + libpcap-0.9.3 become a working combination, I think there are a lot of affected users out there. People heading for a immediate solution could use the patch, the others have to wait until revised packages is avialable.... If there is something to test, I would gladly spent some time. Please advise if a bug for pppd should be filed as well.
Reassigning to ppp's maintainers, since the patch is on ppp's side.
Created attachment 64216 [details, diff] ppp-2.4.2-pcap.patch Attaching patch for convenience.
(In reply to comment #2) > Thank you for pointing to the patch, it should be coordinated that pppd-2.4.3 + > libpcap-0.9.3 become a working combination does pppd-2.4.2 + libpcap-0.9.3 become a working combination as well? on the other hand, pppd upstream commited in CVS another fix for that ( http://www.samba.org/cgi-bin/ppp-bugs/CVS?id=1225;expression=pcap;user=guest ). can you confirm that it works on pppd-2.4.[23] and libpcap-0.9.3?
> does pppd-2.4.2 + libpcap-0.9.3 become a working combination as well? > > on the other hand, pppd upstream commited in CVS another fix for that ( > http://www.samba.org/cgi-bin/ppp-bugs/CVS?id=1225;expression=pcap;user=guest ). > can you confirm that it works on pppd-2.4.[23] and libpcap-0.9.3? > hmm, I
> does pppd-2.4.2 + libpcap-0.9.3 become a working combination as well? > > on the other hand, pppd upstream commited in CVS another fix for that ( > http://www.samba.org/cgi-bin/ppp-bugs/CVS?id=1225;expression=pcap;user=guest ). > can you confirm that it works on pppd-2.4.[23] and libpcap-0.9.3? > hmm, I´m a bit confused right know... due to the several days outtake of my DSL line, I´ve lost a bit track of things. Please advise explicitly what combinations of pppd + patch + libpcap should be tested. My initial thought was that this becomes fixed for libpcap 0.9.3 + pppd 2.4.3 + nescessary patch... Due to my broke away DSL line, I have to fall back to a ISDN link where it turned out that ipppd also lacks working active-filter support (libpcap 0.9.3 + isdn4k-utils-3.6_pre20041219-r1). Maybe this should be preferable extended to the isdn4k-utils maintainers than filing a new bug since the whole story is comprehensible here...
I think the patch in question (the one given by upstream) could be applied to any pppd/ipppd version. What I want from you is confirmation that patched ppp-2.4.2, ppp-2.4.3 and (why not) ipppd works with libpcap-0.9.3.
Turns out that it works only with >=virtual/libpcap-0.9.3. netmon herd, I kindly request that libpcap-0.9.3 be marked stable as soon as humanly possible. I've fixed this bug in ppp versions as follows: - ppp-2.4.3-r7 - apply all current upstream CVS patches - ppp-2.4.2-r13 - apply patch posted in comment #4 The only thing remaining to be fixed is ipppd from isdn4k-utils. genstef or sbriesen, can any of you do it?
Before my time permits testing the patches by myself, you
Before my time permits testing the patches by myself, you´ve already provided new versions, so I test the current ebuilds... > I've fixed this bug in ppp versions as follows: > - ppp-2.4.3-r7 - apply all current upstream CVS patches > - ppp-2.4.2-r13 - apply patch posted in comment #4 Feedback for ppp-2.4.3-r7 + libpcap-0.9.3: with active-filter 'outbound and not icmp[0] != 8 and not tcp[13] & 4 != 0' DOD is not working, it seems that outgoing packets no longer trigger the connection, removal of active-filter statement restores DOD connection init by pppd. Now testing ppp-2.4.2-r13 + libpcap-0.9.3 ...
please test it with active-filter outboud and active-filter inbound
(In reply to comment #10) > please test it with > active-filter outboud > and > active-filter inbound done for 2.4.3-r7, no different result, no connection, seems to ignore all traffic that should trigger a connection as long as an arbitrary active-filter statement is in options file... pppd-2.4.2-r13 + libpcap-0.9.3 "[pppd] error in active-filter expression: inbound/outbound not supported on linktype 9_" complains exactly like the unpatched 2.4.3
you probably don't have CONFIG_PPP_FILTER activated in your kernel. you're right about pppd-2.4.2-r13 + libpcap-0.9.3 (I've tested 2.4.2 only with libpcap-ringbuffer). turns out that patch posted at comment #4 have several problems: - all modifications applied to demand.c are wrong - the used link type should be DLT_PPP_WITH_DIRECTION or DLT_PPP_WITHDIRECTION (depending on what virtual/libpcap is installed) I've added kernel configuration checks to ppp-2.4.3-r7 and ppp-2.4.2-r14. Also, I've fixed the activefilter-libpcap-0.9.3 patch in ppp-2.4.2-r14. I've tested these versions using a on-demand PPPoE connection in conjunction with libpcap-0.9.3 and libpcap-ringbuffer-1.0.20041001. The active filter was "active-filter outbound and icmp" which managed to start the PPPoE link in all 4 combinations. I reiterate my request to netmon herd to mark libpcap-0.9.3 as stable.
hold on.. I've realized that I've tested only with "active-filter icmp"
ok, seems that we should patch demand.c after all. this afects only on-demand links, with filters that contains "inbound" or "outbound" keywords. I will submit the new versions (ppp-2.4.3-r8 and ppp-2.4.2-r15) as soon as I can.
versions submitted to cvs. also, I've sent the patch to the upstream.
Alin, we will mark libpcap-0.9.3 stable as soon as we can, but given that a lot of packages depend on it and it has only been available for 14 days, we would like to wait a bit longer.
@Alin: can I apply just your patch to ipppd? If, then I would include it ASAP to isdn4k-utils.
@Marcelo: ok, but keep in mind that it is a priority for net-dialup herd. @Stefan: yes, you should apply my patch. also, you should apply options.c part of the patch posted at comment #4 (if not already applied, of course).
@Alin: it seems, that ipppd is somewhat outdated and not comparable anymore to recent pppd's. So I have to check how to apply that patch. Takes some more time. ;) @all: if you have a CAPI based card (mISDN also works!) then you really should use pppd with capiplugin instead of ipppd.
Just want to report that ppp-2.4.3-r7 + libpcap-0.9.3 works fine for days on a production system, now testing ppp-2.4.2-r13 ....
ppp-2.4.2-r15 works also like expected, so people can use pppd for ISDN cards with CAPI support for reliable DOD, only users with ISDN cards only supported by i4l are in need of a patched ipppd...
Created attachment 65899 [details, diff] ipppd-pcap-0.9.3.patch Stefan, please verify the attached patch. If ipppd supports on-demand links, you should check it with "active-filter outbound icmp" and see if a echo request packet raise the connection. If this patch works, it should be sent to upstream.
huh. I first have to create an testing-environment for this (I'm using ppp normally). But I try to apply your patch later and test if it works at all. btw: I have some other enhancements in the queue for capi4k/isdn4k (already in my local-portage tree). So I have to merge it carefully... ;)
patch doesn't apply with latest isdn4k-utils (even afert fixing header). But patch looks simple and I found the places where the patch should be applied. I investigate this further tomorrow.
ok, I now have the patch applied and it compiles fine. But I have no possibility to test it. But since it compiles now and the patch looks simple, I just include it and let you test the next version. ;-) I will add 'activefilter' USE flag and try to do the same as in net-dialup/ppp. But since I have some other enhancements in my queue which I have to finish first, I will release the new revision in a few days, not immediately.
new version of isdn4k-utils with patched activefilter support is in portage now.
(In reply to comment #26) > new version of isdn4k-utils with patched activefilter support is in portage > now. please add a info message regarding the new USE flags, see bug #104867. Another minor problem: * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 2.4.31-grsec * Checking for suitable kernel configuration options * CONFIG_ISDN_I4L: should be set in the kernel configuration, but isn't * Please check to make sure these options are set correctly. * Once you have satisfied these options, please try merging * this package again. The ebuild only checks for Kernel 2.6 config, my current active Kernel is 2.4 and of course build with I4l support, please modify for an explizit warning message and regard 2.4 configs (CONFIG_ISDN=y) as well.
After circumventing the above ebuild limitations (added CONFIG_ISDN_I4L=yes in .config), I
After circumventing the above ebuild limitations (added CONFIG_ISDN_I4L=yes in .config), I´ve succesfully emerged isdn4k-utils-3.7_pre20050821, but: * Starting ipppd for ippp1 ... In file /etc/ppp/options.ippp1: unrecognized command active-filter * Failed to start ipppd [ !! ] active-filter support seems not to be available in the ipppd binary....
1. I don't have any 2.4 kernels anymore, but I will fix the checks somehow 2. I activate 'filter' in the build config if 'activefilter' is selected. So it should work. But perhaps there's a bug either in the Makefile or in the ebuild. I will check this later.
ok, first the CONFIG_* checker: I will fix it ASAP. But since there's no easy solution (no eclass-function available) I have to figure out first, how to solve this best. but for the active-filter part: 'activefilter' is dependend on 'ipppd'. if you set both, CONFIG_IPPP_FILTER=y will be activated in .config and if this is done, then #define IPPP_FILTER should be set by configure. [ipppd/options.c] #ifdef IPPP_FILTER { "pass-filter", 1, setpassfilter}, /* pass filter */ { "active-filter", 1, setactivefilter}, /* link-active filter */ #endif /* IPPP_FILTER */ strange... I have to investigate why CONFIG_IPPP_FILTER doesn't work as expected.
hmpf! looks like we have to call 'autoconf' in ipppd/ first. The 'configure.in' has active-filter option, but 'configure' not. :-/ I think I will call autoconf in every relevant sub-tree, just to be on the safe side... *grrr*
ok, fixed. ;-) * renamed ebuild to correct version (isdn4k-utils-3.8_pre20050821) * fixing activefilter issue * adding mschap support for ipppd * disabled kernel-config checks for the time being (needs rework) please test! thanks!
any new results? should work now, but someone should test it. ;-)
(In reply to comment #33) > any new results? should work now, but someone should test it. ;-) sorry for the delay, I
(In reply to comment #33) > any new results? should work now, but someone should test it. ;-) sorry for the delay, I´m a bit under pressure @work... It compiles fine, but I want to test it thoroughly and verify that the active filter works like expected and DoD is reliable... Please stand by for my feedback when it passes/fails my test enviroment...
I've marked ppp-2.4.2-r15 stable on x86. I hope the other arches will soon follow.
Alexander, did you find the time to test ipppd?
(In reply to comment #36) > Alexander, did you find the time to test ipppd? yes, finally I managed to set up a test environment on weekend and nothing odd occured, the active filter works under heavy p2p traffic, DoD seems reliable again, so I think its save to make it stable soon... When the most of my current work is done, a few boxes will be put in live production environments. If something unexpected happens, I will report immediately. Thanks to all persons who put in their expense into solving these issues...
stefan, please close this bug the moment you mark isdn4k-utils-3.8_pre20050821 as stable.
Stefan, what is keeping you from marking isdn4k-utils-3.8_pre20050821 stable on x86 ?
I will mark it stable end of this week.
stable on x64 and amd64. But I can't test alpha and ppc.
s/x64/x86/g ;-)
good enough for me. bug closed!
