Sylvain Rochet | 26 Apr 20:40 2015

[PATCH 0/2] ppp: mppe: fixes MPPE desync on links which don't guarantee packet ordering

I am currently having an issue with PPP over L2TP (UDP) and MPPE in
stateless mode (default mode), UDP does not guarantee packet ordering so
we might get out of order packet. MPPE needs to be continuously synched
so we should drop late UDP packet.

I added a printk on the number of time we rekeyed in MPPE decompressor,
this is what we currently have if we receive a slightly out of order UDP
packet:

[1731001.049206] mppe_decompress[1]: ccount 1559
[1731001.049216] mppe_decompress[1]: rekeyed 1 times

[1731001.049228] mppe_decompress[1]: ccount 1560
[1731001.049232] mppe_decompress[1]: rekeyed 1 times

[1731001.050170] mppe_decompress[1]: ccount 1562
[1731001.050182] mppe_decompress[1]: rekeyed 2 times

[1731001.050191] mppe_decompress[1]: ccount 1561
[1731001.062576] mppe_decompress[1]: rekeyed 4095 times
                                             ^^^^
This is obviously wrong, we missed packet 1561 and we already rekeyed 2
times for 1562 we previously received, we can't recover the decryption
key we need for 1561, we should drop it instead of rekeying 4095 times.

This patch series drop any packet with are not within the 4096/2 forward
window.

Sylvain Rochet (2):
  ppp: mppe: sanity error path rework
(Continue reading)

Mrs. Zhang Xiao | 10 Apr 09:24 2015
Picon

Re.

Dear,

I seek for your sincerity and trust in a deal which involved a total sum of 60,000,000.00 United states
dollars. I need to know you and know your location. This really matter to the success of this deal.If
interested respond to me for more details. 

Yours Sincerely.
Mrs. Zhang Xiao (Accounts book Keeper)
Angang Steel Company Limited
396 Nan Zhong Hua Lu, Tie Dong District Anshan, Liaoning 114021, China.

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ck | 27 Mar 22:42 2015
Picon

PADO answer incoming wrong VLAN since new linecard

Hi There!
I've been running pppd for years with my PPPoE connection. That was 
working perfectly fine until yesterday.
I am not able to connect via PPPoE anymore, because after I am sending 
an PADI, the received PADO is incoming on a wrong VLAN.

That happend, after the linecard outside has been changed by my ISP. It 
was an Infineon 11.5.3, when it was working and stopped working, after 
it has been changed to a Broadcom 164.34.

Basically, my setup is, that I've to connect via vlan7. I am sending my 
requests on that specific vlan7. But now, after that, I am getting the 
PADO on vlan8, which now causes the problem, that pppd thinks, that 
there is no answer to the PADI request.

That also seems not to be a distribution problem. I am using Gentoo, but 
I've tried also Ubuntu and OpenSUSE. All distributions showed the same 
error. I've tried pppd 2.4.5, 2.4.6 and 2.4.7.

BUT!
If I am using a BSD-Distribution (like pfSense) or an external hardware 
router (like Fritz!Box), those are perfectly working fine. Those systems 
can connect via PPPoE, the PADO answer is getting there on the correct 
VLAN back (7).

So, what is going? Why does Linux PPP seems to have problems, where 
other systems do not have a problem?
Can anybody help? After my tests, I am just thinking, that there is some 
sort if a bug.. I mean, if was working for years fine and now stopped?

(Continue reading)

pepa6.es@ono.com | 12 Mar 12:49 2015

(unknown)

Proposal,

Respond to my personal email;  mrs.zhangxiao1962 <at> outlook.
com 

Yours Sincerely.
Mrs. Zhang Xiao (Accounts book Keeper)
Angang 
Steel Company Limited
396 Nan Zhong Hua Lu, Tie Dong District Anshan, 
Liaoning 114021, China.

--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Simon Farnsworth | 1 Mar 11:54 2015
Picon

[PATCH net-next v2] pppoe: Use workqueue to die properly when a PADT is received

When a PADT frame is received, the socket may not be in a good state to
close down the PPP interface. The current implementation handles this by
simply blocking all further PPP traffic, and hoping that the lack of traffic
will trigger the user to investigate.

Use schedule_work to get to a process context from which we clear down the
PPP interface, in a fashion analogous to hangup on a TTY-based PPP
interface. This causes pppd to disconnect immediately, and allows tools to
take immediate corrective action.

Note that pppd's rp_pppoe.so plugin has code in it to disable the session
when it disconnects; however, as a consequence of this patch, the session is
already disabled before rp_pppoe.so is asked to disable the session. The
result is a harmless error message:

Failed to disconnect PPPoE socket: 114 Operation already in progress

This message is safe to ignore, as long as the error is 114 Operation
already in progress; in that specific case, it means that the PPPoE session
has already been disabled before pppd tried to disable it.

Signed-off-by: Simon Farnsworth <simon <at> farnz.org.uk>
Tested-by: Dan Williams <dcbw <at> redhat.com>
Tested-by: Christoph Schulz <develop <at> kristov.de>
---

Changes from v1:

 * Amend commit message to tell people about the harmless error from pppd

(Continue reading)

Alan | 19 Feb 22:39 2015
Picon

[PATCH] ppp_synctty: remove unneeded NULL check

Fix a random whine found by coverity. Had it been NULL it would have
showered us with oopses long before.

Signed-off-by: Alan Cox <alan <at> linux.intel.com>
---
 drivers/net/ppp/ppp_synctty.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ppp/ppp_synctty.c b/drivers/net/ppp/ppp_synctty.c
index 925d3e2..b5592b8 100644
--- a/drivers/net/ppp/ppp_synctty.c
+++ b/drivers/net/ppp/ppp_synctty.c
 <at>  <at>  -549,7 +549,7  <at>  <at>  ppp_sync_txmunge(struct syncppp *ap, struct sk_buff *skb)

 	ap->last_xmit = jiffies;

-	if (skb && ap->flags & SC_LOG_OUTPKT)
+	if (ap->flags & SC_LOG_OUTPKT)
 		ppp_print_buffer ("send buffer", skb->data, skb->len);

 	return skb;

--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Anljaken . | 10 Feb 13:02 2015
Picon

Default Route Problem with pppd

Hi,

I have a default route problem with a dialup xDSL ppp interface. Even
if i give defaultroute option to pppd service, default route is not
added. I do not have another default route. Running on debug mode, i
can not see any problem at logs.

PPP Version : ppp-2.4.4-2.el5
OS : Centos5
Linux kernel : 3.4.103-2
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Easy Finance | 31 Jan 13:57 2015
Picon

Apply

Good & Bad Credit Loan With No Credit Check. Email us amount needed & duration.

===================================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lee Essen | 26 Jan 17:29 2015
Picon

multiple pppd instances -- resolv.conf challenges and suggested improvement

Hi,

I’ve hit a bit of a challenge with the way that pppd creates the resolv.conf file.

Basically if you want to get dns servers from the other side you need ‘usepeerdns’ set.

If you set ‘usepeerdns’ then pppd will create resolve.conf (/etc/ppp/resolv.conf as standard,
although changed in many dists)

The challenge is that if you have two pppd’s running, both getting DNS entries, then there is no way to
specify a different file (so that you can be clever later) and the given file will be overwritten by the most
recent connection. Also, with buiildroot builds the path is set to /etc/resolv.conf which causes even
more of a problem since you can’t ‘usepeerdns’ without making your system use the provided resolvers.

It does feel wrong that just about every other aspect of pppd supports isolated multiple connections, but
the resolv.conf file is a single path that will get overwritten by the last connection, and then, of
course, if that connection drops the file is then incorrect!

Could I suggest a ‘noresolv’ config option that simply suppresses the creation of the resolve.conf
file?  It’s a very simple patch, has no compatibility issues with existing configuration and makes it
possible to use ppp-up scripts to do the heavy lifting with no conflicting resolv.conf creations. This
would also allow buildroot users to avoid the “forced use of peer dns”.

(The other option would be to have a configurable path for resolv.conf)

Cheers,

Lee.

diff -Naur pppd-orig/pppd/ipcp.c pppd-2.4.7/pppd/ipcp.c
(Continue reading)

Matt Dooner | 23 Jan 12:56 2015
Picon

pppd hangup only when traffic sent over connection

Hello,

I'm experiencing an issue where pppd hangs up, but only when traffic
is sent over the connection. The connection is stable if it is idle,
but soon after any traffic is sent over the connection pppd hangs up.
For example, 15-30 pings or a few lines into a telnet session kills
the connection. I suspect this is the result of a lack of support for
a Link Quality Report (which is Confreq'd by the target).

As you can see in the debug about below if-down is started after the
"rcvd [LCP ConfReq id=0xf0 <mru 400> <quality lqr 00 00 01 2c> <magic
0xc0a80ea5> <pcomp> <accomp>]". This ConfReq occured after 17
successful pings over the link, and the link went down after the
ConfReq. Is this expected behaviour?

Thanks in advance,
Matt

using channel 14
Using interface ppp0
Connect: ppp0 <--> /dev/ttyO1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9ad4ff1a> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0xd5 <mru 400> <quality lqr 00 00 01 2c> <magic
0xc0a80ea5> <pcomp> <accomp>]
sent [LCP ConfRej id=0xd5 <quality lqr 00 00 01 2c>]
rcvd [LCP ConfRej id=0x1 <asyncmap 0x0>]
sent [LCP ConfReq id=0x2 <magic 0x9ad4ff1a> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0xd6 <mru 400> <magic 0xc0a80ea5> <pcomp> <accomp>]
sent [LCP ConfAck id=0xd6 <mru 400> <magic 0xc0a80ea5> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <magic 0x9ad4ff1a> <pcomp> <accomp>]
(Continue reading)

"Antonio Viñal" | 16 Jan 21:56 2015
Picon

Please respond!!!

Please respond!!!
Hello friend!

I would like to contact you personally for an important proposal that
could of interest to you.
I send this email only to know if this email address is functional.
I have something very important to discuss with you. Contact me for
details by:  Email: fernrodyup12 <at> aol.jp with your direct contacts.

Kind regards.
Antonio Viñal.

--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane