Steps to Reproduce:
mppe-mppc don't working!
i.e with manual patch of kernel all working.
maybe need correct ebuild ...
Some explanation of what "mmpe-mppc" actually is would be nice..
its the vpn encryption used in microsoft VPN's.
its inclusion is questionable from a legal stance, but aside from that, I would have nothing against its inclusion.
Would you like me to put this forward to the trustees to question its legality?
It's not really the sort of patch we like to apply, and its not GPL, so doubtful that we'd want it...
its actually something worth considering when we taker into account server environments, since its not that uncommon to find edge routers or vpn servers peering with windows networks.
the question is, does it warrant inclusion into g-d-s. I would personally say, maybe. depends on the legal standpoint.
I don't think so, we generally only take stuff that is ready or quickly progressing to go upstream. Plus there are licensing issues as well as patent ones. If its useful for servers then maybe hardened-dev-sources would consider it.
I had to apply this patch to connect my ISP using dialup, they have messed with server configuration and enabled that mppe thing :(
Created attachment 47860 [details]
Corrected patch for 2.6.10
Jan 7 21:21:03 security pptpd: CTRL: Starting call (launching pppd, opening GRE)x
Jan 7 21:21:03 security pptpd: CTRL: pty_fd = 5
Jan 7 21:21:03 security pptpd: CTRL: tty_fd = 6
Jan 7 21:21:03 security pptpd: CTRL (PPPD Launcher): Connection speed = 115200
Jan 7 21:21:03 security pptpd: CTRL (PPPD Launcher): local address = 192.168.10.1
Jan 7 21:21:03 security pptpd: CTRL (PPPD Launcher): remote address = 192.168.10.100
Jan 7 21:21:03 security pptpd: CTRL: I wrote 32 bytes to the client.
Jan 7 21:21:03 security pptpd: CTRL: Sent packet to client
Jan 7 21:21:04 security pppd: pppd 2.4.3 started by root, uid 0
Jan 7 21:21:04 security pppd: Using interface ppp1
Jan 7 21:21:04 security pppd: Connect: ppp1 <--> /dev/pts/2
Jan 7 21:21:04 security pptpd: CTRL: Received PPTP Control Message (type: 15)
Jan 7 21:21:04 security pptpd: CTRL: Got a SET LINK INFO packet with standard ACCMs
Jan 7 21:21:04 security pptpd: GRE: Discarding duplicate packet
Jan 7 21:21:06 security pptpd: CTRL: Received PPTP Control Message (type: 15)
Jan 7 21:21:06 security pptpd: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Jan 7 21:21:06 security pppd: MPPE 128-bit stateless compression enabled
Jan 7 21:21:09 security pppd: Cannot determine ethernet address for proxy ARP
Jan 7 21:21:09 security pppd: local IP address 192.168.10.1
Jan 7 21:21:09 security pppd: remote IP address 192.168.10.100
Jan 7 21:21:28 security pptpd: CTRL: Received PPTP Control Message (type: 15)
Jan 7 21:21:28 security pptpd: CTRL: Got a SET LINK INFO packet with standard ACCMs
Works pretty well for me with that patch on 2.6.10-r1 and -r2. The only thing I have changed in the patch to get it applied was:
root@security linux # diff -u linux-2.6.9-mppe-mppc-1.2.patch linux-2.6.10-mppe-mppc-1.2.patch
--- linux-2.6.9-mppe-mppc-1.2.patch 2005-01-07 21:28:02.287156056 +0500
+++ linux-2.6.10-mppe-mppc-1.2.patch 2005-01-07 17:51:54.000000000 +0500
@@ -52,7 +52,7 @@
* PPP driver, written by Michael Callahan and Al Longyear, and
* subsequently hacked by Paul Mackerras.
-- * ==FILEVERSION 20020217==
+- * ==FILEVERSION 20041108==
+ * ==FILEVERSION 20040509==
root@security linux #
This patch is very necessary. Consider my situation. My internet provider allows me to connect to internet only with the usage of this vpn sollution. I'm sure many users like me have to patch their kernel manually. Just search forum and you'll find many topics about this. So gentoo land needs this vpn.
This vpn sollution consist of two parts. Kernel patch and net-dialup/ppp patch.
The only problem Drake told us is licence. I think the best sollution will be to use mppe-mppc USE flag. This flag is used in net-dialup/ppp and enables ppp part of this vpn sollution. By default this patch will be omited, but if somebody needs it, he will have kernel and ppp patched. Logical I think ;) Also I think this sollution with USE flag partially solves license problems.
Applying patches based on use flags is not a deal we want to get into. I do not think we will include this patch as it is right now, but I'm waiting to get Greg KH's opinion before I close this.
I don't know how to get clean sollution, but I know that here in Moscow/Russia (more than 13 000 000 citizens...) there many HOME LAN's where provider has the only possibility to authorise users on their gateways to internet with this microsoft's VPN. So particulary any user in Moscow, that decide to taste gentoo by defalt stay without internet... Funny Yes?
May be it's possible to create ebuild to patch kernel accordingly, if we have mppe-mppc flag. We need to patch kernel, after it is installed. But I don't know how it is possible with portage?
Legally, in this country, I can not apply this patch to the tree, sorry. We can't put known problematic code in our trees.
And, months later :P :
Might a USE-flag-triggered SRC_URI and fetch-restriction satisfy the legal concerns?
No, because ensuring that the patch is up-to-date and doesn't conflict with
others is going to be a big pain. I could see this solution causing no end
of conflicts and annoyances over time.
Also see comment #11. Applying patches based on use flags would make maintaining the kernel even more difficult, as we'd have to test multiple combinations for patching, compiling, and booting, before every release. This isn't something we want to get into.
*** Bug 92178 has been marked as a duplicate of this bug. ***
Why not provide an ebuild that downloads and patches the kernel for you?
Patent/legal issues, plus the massive maintenance issues involved in adding a new kernel into portage, the fact that the patch licensing is bad, and the fact that the patch doesn't seem to be going anywhere. If you want to write an ebuild, please feel free to attach it here. It will not be added to portage. Sorry.
Lastest patches found here:
Well, when I'm right the MPPE part is now included in the mm-sources and
possibly would be merged into the vanilla kernel (>2.6.13). For me MPPE patching
of gentoo-sources was a hugh problem during the last two years. The polbox patch
didn't apply to several gentoo-sources which leads to switch to vanilla-sources
and back. In my opinion it would be very nice, when gentoo-sources includes MPPE
Here is the URI to the splitted out mm-sources MPPE-Patch (should apply to
(In reply to comment #21)
> Well, when I'm right the MPPE part is now included in the mm-sources and
> possibly would be merged into the vanilla kernel (>2.6.13). For me MPPE patching
> of gentoo-sources was a hugh problem during the last two years. The polbox patch
> didn't apply to several gentoo-sources which leads to switch to vanilla-sources
> and back. In my opinion it would be very nice, when gentoo-sources includes MPPE
Is incorrect. Polbox patch successfully work with gentoo-sources (i'm tested
with 2.6.10 kernel).
Maybe it works with 2.6.10, what I mean were, that there were several
gentoo-sources where I couldn't apply the according current version of this
patch, because of applied gentoo-sources patches. In my opinion it would be
better, when gentoo-source supports MPPE directly or there were a separate
ebuild which create the MPPE module.
I think an automated or included support of MPPE is much better, than patching
source manually on every kernel update.
Therefore it would be nice to have support in gentoo-sources or a module ebuild
which can be used with modules-rebuild...
(In reply to comment #23)
> Maybe it works with 2.6.10, what I mean were, that there were several
> gentoo-sources where I couldn't apply the according current version of this
> patch, because of applied gentoo-sources patches. In my opinion it would be
> better, when gentoo-source supports MPPE directly or there were a separate
> ebuild which create the MPPE module.
Maybe you or me don't understood. Base gentoo-sources patched absolutly normally
(w/o .rej files).
Lastest my kernel sources: sys-kernel/gentoo-sources-2.6.12-r6
It seems so.
Well, my point is, that every time when a new kernel version is available, I
have to download a MPPE patch manually, try to apply it cleanly (which maybe
doesn't work if the patch isn't compatible with the kernel version) and the
build the kernel. So far so good. But it would be better when the kernel was
patched or there is a MPPE ebuild which create the module matching to the
current kernel version.
Including the MPPE patch to the mm-sources shows that there is a need for a MPPE
ready kernel. Maybe it would be merged to vanilla sources, but until then it
would be nice to have a MPPE ready kernel...
(In reply to comment #19)
> Patent/legal issues, plus the massive maintenance issues involved in adding a
new kernel into portage, the fact that the patch licensing is bad, and the fact
that the patch doesn't seem to be going anywhere. If you want to write an
ebuild, please feel free to attach it here. It will not be added to portage. Sorry.
If is not problem for now (mm-sources already have MPPE patch) ... Try to
Created attachment 65511 [details]
fresh patch for 2.6.12-r6 for now
There's no way we're including the patch in comment #27 - its too messy.
The other patch referenced here is much cleaner and more acceptable, but the
usual policy still applies: Get it accepted upstream first, then we'll consider
either patching it into our current releases or just waiting for the next
vanilla release to include it.
The good news is that inclusion in -mm is a giant step in this direction. You
should test it out, and even if it works fine, send a mail to Andrew Morton, the
network maintainer (Dave Miller), and the patch author, telling them how well it
works, how much demand there is for it, and that you'd like to see it included
Note that after 2.6.13 is released, they only have 2 weeks to send it in for
2.6.14, so give them plenty of time :)
I've made an eclass called parent-kernel that I think might be useful to the people in this bug: it makes it extremely easy to make a custom-patched kernel based on a Gentoo kernel ebuild - e.g. hardened-sources + this MPPE/MPPC patch. The main benefits over modifying the ebuild manually is that the patch(es) is/are included in the package and it automatically tracks with new versions of the parent package as they stabilize, etc.
Please feel free to get it at http://www.nerone.org/mike/projects/parent-kernel.eclass/ and give it a try. I've put a specific example ebuild for MPPE/MPPC support on that page as well. YMMV, etc., but I haven't had any trouble testing with various patch combinations and such.
I took a quick look at your work:
You can do it much simpler just by using the UNIPATCH_LIST variable. See usermode-sources for an example.
It perhaps isn't as featureful since it doesn't support fetching over http, or descriptions, but it does the job. It also handles extracting tarballs and stuff.
Also bug #120357 includes a patch being considered which allows you to customise UNIPATCH_LIST on the command line.
Finally mppe-mppc stuff is included in 2.6.15.
The eclass does use UNIPATCH_LIST, it just provides a nice interface to it, greatly simplifies the custom ebuild, and allows it to automatically evolve with the parent (instead of requiring you to rewrite your ebuild every time the parent changes).
Didn't realize MPPE is included in 2.6.15, as it was just an example from my PoV. Thanks for looking at it, though. :) Anyway, I guess further discussion of this little tool is OT here - I just wanted it to be available to users here.