Do you know of a memory leak bug on TX channel created by ppp connection? You can google it by keywords "pppd bug soft lockup cpu # 0 stuck for". This message is issued to the console, and nothing can be done with a PC, just reboot.

However, I have long been using this provider (Beeline Russia) and I don't remember that before this problem I had. I found the old kernel 2.6.32.11 and my config and tried to run with them. Now the system does not hang and I can see what happens.

So, I use latest version openl2tp (1.8) and kernel 2.6.32.11 with my config.

You can see that the first connection is created for one minute and passes on the TX 1.4Gb. With constant running ifconfig shows how the traffic is growing at a rate of about 1 GB per second, up to 4GB, reset, and increases again. It then recalls, and everything is fine. In the first minute of any sites do not ping, although the connection is. On the forums write about loopback traffic, but route to pool is present

Do you know of a memory leak bug on TX channel created by ppp connection? You can google it by keywords "pppd bug soft lockup cpu # 0 stuck for". This message is issued to the console, and nothing can be done with a PC, just reboot.

I wasn't aware of this. But googling suggests it might be a ppp problem with the kernel you are using. Have you tried a more recent kernel?

More recent - a 3.0 +? No, haven't triedBut the writing on the forums that have the same problem on Ubuntu 11.04 with kernel 3.xWhat kernel do you advise me to try?

It is usually best to try the newest kernel possible as kernel developers are more likely to be interested in solving the problem. If you can build from source, even better is to try the latest development kernel from git://git.kernel.org/pub/scm/linux/kern ... t-next.git, but only try that if you are already familiar with building your own kernel from source.Is the problem easy to reproduce?

Ok, I'll try the new kernel, when there will be free time. Not sure what will happen quickly apply my configuration to the new kernel.

Quote:

Is the problem easy to reproduce?

For the provider Beeline Russia - yes. There are at least in two cities. How reproduce this problem for you, I don't really understand. I'll check it is possible to connect to the l2tp server from an external IP. If so, I'll give you a login and password for this test.

You can try test login and password **** to server ******. Try "host *****" for more IP address. Service must be started automatically through init.d. If to start daemon manually, it works normal.

Thanks for setting up access to your server.We have reproduced the problem. It is caused by the server configuring a local IP address for its PPP endpoints which is the same address as the public IP of the L2TP server. For example, your L2TP server has IP address 1.2.3.4 and sets the local address of each PPP interface to 1.2.3.4. L2TP clients need to reach your L2TP server at 1.2.3.4, while one of its PPP sessions gets assigned the same address as the server.There is a bug in the Linux driver which seems to result in a transmit routing loop in this situation - a packet that is transmitted through the PPP interface is somehow intercepted by the IP stack (because the IP desination address is also to the L2TP server) and the packet ends up looping in the kernel, increasing in size each time it is transmitted.Please make sure that the PPP interface configured for PPP interfaces is _not_ the same as the server's public IP.Meanwhile, I will ask the Linux kernel developers for the best way to prevent the routing loop to protect against configurations like this.Thanks again for posting about this issue.

How do I configure the ppp interface? Since you have access to this issue, could you help me with this? Here is my configuration

That's the problem - you can't. The IP address is assigned by the L2TP server. When the L2TP server assigns you its public IP address for its PPP sessions, it is actually quite dangerous because clients are able to access the server's IP stack using a public test account!

Orion33 wrote:

Have you tried the latest kernel? There also exists the problem?

Yes.

Orion33 wrote:

PS. Username and password from previous post can be left because it is not my but a public test access by my provider Beeline Russia, from which is available the home page corbina.net only.

Ok.

We are working on changes to the L2TP driver that will detect this unusual setup to avoid the packet loop. It isn't an OpenL2TP-specific problem.

When you connect using your actual subscriber account, do you get an IP address for your PPP interface which is different to that used by the L2TP server? If so, does it work as expected?

When you connect using your actual subscriber account, do you get an IP address for your PPP interface which is different to that used by the L2TP server? If so, does it work as expected?

While I watched it, yes, each time the addresses were different. But the problem is that the pool has a lot of addresses, possibly some other subscriber is allocated the address to which I am trying to connect. This confirms the fact that the problem occurs not always but often.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum