Modify

Opened 12 years ago

Closed 9 years ago

Last modified 4 years ago

#571 closed defect (wontfix)

Reboots on pptp-traffic

Reported by: pittipatti@… Owned by:
Priority: high Milestone: Barrier Breaker 14.07
Component: base system Version:
Keywords: pptp reboot Cc:

Description

When using a pptp-vpn-connection on a client behind the router (rc5), the router reboots after a few minutes. Without this pptp-connection it runs stable.

To get pptp working I loaded "ip_conntrack_pptp" on the router.

As client I tried linux pptp-client and window xp. Both result in this fault.

I can see the same behaviour on an Asus WL500G-Deluxe and on a Linksys wrt54-gs 1.1.

Attachments (0)

Change History (24)

comment:1 Changed 12 years ago by nbd

Would it be possible for you to attach a serial console to one of the routers to monitor what's happening? I can't reproduce the bug...

comment:2 Changed 12 years ago by pittipatti@…

I'm now trying to get a serial-cable for one of my routers.

I Found this in my log just before the router rebooted last time. Maybe it helps!?

Jun 25 11:23:59 routus kernel: ip_conntrack_pptp: error during exp_gre

comment:3 Changed 12 years ago by florian

  • Owner changed from developers to florian
  • Status changed from new to assigned

comment:4 Changed 12 years ago by anonymous

Please install this package: http://downloads.openwrt.org/people/nbd/tmp/kmod-ipt-nat-pptp_2.4.30-brcm-3_mipsel.ipk and then reboot and test again

comment:5 Changed 11 years ago by florian

  • Milestone changed from 0.9/rc6 to Kamikaze

Looks like too complicated to fix yet.

comment:6 Changed 11 years ago by nbd

  • Resolution set to fixed
  • Status changed from assigned to closed

Should be fixed by now. Please test http://downloads.openwrt.org/people/nbd/whiterussian/ and reopen if it's not working...

comment:7 Changed 11 years ago by mat@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

This also happens on kamikaze 7.06,

  • trying to connect form a client behind the wrt to a pptp on the internet causes the router to reset, almost always as soon as the client tries to make a connection
  • happens regardless of QoS being on or off (I've heard anecdotally that QoS screws with PPTP passthrough)
  • happens regardless of whether or not ip_conntrack_pptp and ip_nat_pptp are loaded.
  • DOES NOT happen when ip_nat_proto_gre is not loaded (mind you, the pptp connection doesn't get nailed up either, but at least it's a minimal set of modules)
  • Nothing shows up in the logs before reboot.
  • Will bring a level shifter home this week to see what comes over the serial port

comment:8 Changed 11 years ago by mat@…

Attached are two kernel panic dumps obtained in two separate cases as follows:

  • Fresh reboot of openwrt (stock 7.06 with kmod-ipt-nathelper-extra installed, among others)
  • The following modules loaded:
    Module                  Size  Used by    Tainted: P  
    sch_red                 3216  4 
    sch_sfq                 3912  4 
    sch_hfsc               15960  2 
    cls_fw                  2888  8 
    wlcompat               15520  0 (unused)
    ip_nat_pptp             2412  0 (unused)
    ip_conntrack_pptp       2940  1 
    ip_nat_rtsp             5488  0 (unused)
    ip_conntrack_rtsp       4816  1 
    ip_nat_h323             2248  0 (unused)
    ip_conntrack_h323       2320  1 
    ip_nat_proto_gre        1552  0 (unused)
    ip_conntrack_proto_gre     2256  0 [ip_nat_pptp ip_conntrack_pptp]
    ip_nat_ftp              2960  0 (unused)
    ip_conntrack_ftp        4272  1 
    ipt_unclean             6832  0 (unused)
    ipt_TTL                  944  0 (unused)
    ipt_ttl                  496  0 (unused)
    ipt_TOS                  976  0 (unused)
    ipt_time                1544  0 (unused)
    ipt_tos                  304  0 (unused)
    ipt_tcpmss               656  0 (unused)
    ipt_mac                  544  0 (unused)
    ipt_length               336  0 (unused)
    ipt_ECN                 1616  0 (unused)
    ipt_ecn                  656  0 (unused)
    ipt_DSCP                 960  0 (unused)
    ipt_dscp                 304  0 (unused)
    ipt_CLASSIFY             704  0 (unused)
    imq                     2384  1 
    ipt_IMQ                  672  0 (unused)
    ipt_layer7             10752  0 (unused)
    ipt_ipp2p               7320  0 (unused)
    ipt_string              3240  0 (unused)
    ipt_recent              8208  0 (unused)
    ipt_quota                528  0 (unused)
    ipt_pkttype              288  0 (unused)
    ipt_owner               1280  0 (unused)
    ipt_LOG                 3792  0 (unused)
    ipt_connbytes           1168  0 (unused)
    ipt_condition           1360  0 (unused)
    ipt_helper               560  0 (unused)
    ipt_conntrack           1104  0 (unused)
    ipt_CONNMARK             816  0 (unused)
    ipt_connmark             352  0 (unused)
    ppp_async               7884  0 (unused)
    ppp_generic            22300  0 [ppp_async]
    slhc                    6064  0 [ppp_generic]
    wl                    630776  0 (unused)
    switch-robo             4540  0 (unused)
    switch-core             4864  0 [switch-robo]
    diag                   22960  0 (unused)
    

Both reboots take place as soon as a PPTP connection from behind the router tries to disconnect from the remote server (client OS X 10.4.10, not entirely sure about the server). No other output leads up to these crashes.

Panic 1:

Unable to handle kernel paging request at virtual address 00000016, epc == 8011dadc, ra == 8011daa4
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 1000fc00 00000014 00000000 80edb850 00000000 00000000 1000fc01
$8 : 00000078 00000000 00000000 80180000 000f8df3 00000000 80974668 00000000
$16: 80edb7e0 80edb82c 00000014 00000000 00000014 801a0000 00000000 00000000
$24: 00000000 801389f0                   8016e000 8016fad0 00000010 8011daa4
Hi : 00000000
Lo : 00000065
epc   : 8011dadc    Tainted: P 
Status: 1000fc03
Cause : 00000008
PrId  : 00029008
Process swapper (pid: 0, stackpage=8016e000)
Stack:    00000001 00000001 00000000 1000fc01 80d15b80 80edb3e0 80edb3e0
 00000014 80d15ab8 80edb360 c01ce20c c01ce1c0 00000000 00000001 00004a8a
 00000000 00000000 7679a8c0 80edb410 00000014 c01ce378 801a6c00 80974000
 80974060 00000000 00000000 00000000 801389f0 00000000 802c3800 8016e000
 8016fb70 00000010 800d7620 1000fc03 00000000 00000000 80e28860 00001000
 c01dd6a8 ...
Call Trace:   [<c01ce20c>] [<c01ce1c0>] [<c01ce378>] [<801389f0>] [<800d7620>]
 [<c01dd6a8>] [<80134e58>] [<c01dd564>] [<c01dd4bc>] [<8011c800>] [<800d7620>]
 [<800d766c>] [<800cc888>] [<800e73d4>] [<800e73d4>] [<800e74b0>] [<800e74b0>]
 [<8011f404>] [<800e73d4>] [<800e73d4>] [<800d5b08>] [<800d5ac0>] [<8011f404>]
 [<8014e8b0>] [<8011daa4>] [<800e73d4>] [<8011ed30>] [<800e3ff4>] [<8011e43c>]
 [<800e59a0>] [<800e5a30>] [<800d5b08>] [<800e3ff4>] [<800d5624>] [<801307e8>]
 [<800e3ff4>] [<800e3ff4>] [<800d5ac0>] [<800c7b34>] [<c012e2d0>] ...

Code: 00661821  ac820000  ac830004 <96470002> 24020068  0045400b  02084021  30e600ff  8d040000 
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
 <0>Rebooting in 3 seconds..Please stand by while rebooting the system...

Panic 2:

Unable to handle kernel paging request at virtual address 00000016, epc == 8011dadc, ra == 8011daa4
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 1000fc00 00000013 00000000 80e033b0 00000000 00000000 1000fc01
$8 : 00000078 00000000 00000000 80180000 000f8589 00000000 80cac668 00000000
$16: 80e03340 80e0338c 00000014 00000000 00000014 801a0000 00000000 00000000
$24: 00000000 801389f0                   8016e000 8016fad0 00000010 8011daa4
Hi : 00000000
Lo : 00000001
epc   : 8011dadc    Tainted: P 
Status: 1000fc03
Cause : 00000008
PrId  : 00029008
Process swapper (pid: 0, stackpage=8016e000)
Stack:    00000001 00000001 1559bcce 1559bcce 80d15a80 80e03b40 80e03b40
 00000014 80d15eb8 80e03ac0 c01ce20c c01ce1c0 00000000 802aea60 00000000
 00000001 00000000 7679a8c0 80e03b70 00000014 c01ce378 8022f600 80e07780
 801a6c00 801a0000 00000000 00000002 00000000 00000000 801389f0 801a0000
 800cc888 8016e000 8016fb78 00000010 800d766c 1000fc03 00000000 00000000
 00000001 ...
Call Trace:   [<c01ce20c>] [<c01ce1c0>] [<c01ce378>] [<801389f0>] [<800cc888>]
 [<800d766c>] [<80134e74>] [<c01dd564>] [<c01dd4bc>] [<8011c800>] [<800d7620>]
 [<800d766c>] [<800cc888>] [<800e73d4>] [<800e73d4>] [<800e74b0>] [<800e74b0>]
 [<8011f404>] [<800e73d4>] [<800e73d4>] [<800d5b08>] [<800d5ac0>] [<8011f404>]
 [<8014e8b0>] [<8011daa4>] [<800e73d4>] [<8011ed30>] [<800e3ff4>] [<8011e43c>]
 [<800e59a0>] [<800e5a30>] [<800d5b08>] [<800e3ff4>] [<800d5624>] [<801307e8>]
 [<800e3ff4>] [<800e3ff4>] [<800d5ac0>] [<800e3ff4>] [<800e47ec>] ...

Code: 00661821  ac820000  ac830004 <96470002> 24020068  0045400b  02084021  30e600ff  8d040000 
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
 <0>Rebooting in 3 seconds..Please stand by while rebooting the system...

comment:9 Changed 11 years ago by phr3ak

openwrt rebooted when i'm disconnected a vpn connection. kamikaze.

comment:10 Changed 11 years ago by florian

  • Owner florian deleted
  • Status changed from reopened to new

comment:11 Changed 10 years ago by Gusu

Compare 2.4.x and 2.6.x kernel versions of PPTP/GRE NAT helper. Many bugs were fixed since 2.4 including many races, oopses and simple flaws in protocol handling. It would be best to backport the current PPTP helper back to 2.4 but I don't know how much work that would be.

comment:12 Changed 10 years ago by eisvogel aht embinet doht de

I can reproduce this on broadcom 2.4 platform in -trunk. Router will oops and reboot when PPTP NAT session is finished. I will test the following two patches shortly:

http://lists.netfilter.org/pipermail/netfilter-devel/2005-January/018025.html
http://lists.netfilter.org/pipermail/netfilter-cvslog/2005-July/004377.html

Those never made it into 2.4.x kernel.

comment:13 Changed 10 years ago by eisvogel aht embinet doht de

I looked at this yesterday a little bit more: There is a boatload of bugs in this PPTP/GRE NAT helper and it will take a while to fix this mess. There have been commits to the Linux tree as late as 2.6.21 with all sorts of patches for e.g. Oopses and wrong handling of the PPTP protocol.

Curious, because Harald Welte of netfilter.org was sponsored to write this module for Astaro AG which sell commercial firewalls. Either they had a secret 'fixed' version or they shipped their products for years with those bugs. And doesn't Watchguard also use Linux.

comment:14 Changed 10 years ago by eisvogel embinet de

I have some patches that need testing. Anyone still interested in this for 2.4? Please drop me an email notice. I cannot find Openwrt mailing lists to subscribe to e.g. -users -devel or even -svn announce. Am I blind?

comment:16 Changed 10 years ago by netprince (at) vt (dot) edu

I believe this report is for the same problem I was having:

/ticket/1742.html

That probably doesn't help very much though

comment:17 Changed 10 years ago by d dot teurlings (at) inter dot nl dot net

I'm having the same issue running kamikaze 7.09 on a Asus WL500-g Premium. Is there any progress since the last post here?

comment:18 Changed 10 years ago by anonymous

I'm having the same problem with kamikaze 7.09 on a wrt54g.

For some reason it works fine with ddwrt. If i remember correctly ddwrt's kernel is a derivation of the openwrt kernel. There might be a fix somewhere.

comment:19 Changed 10 years ago by anonymous

This problem does not exist on white russian (v0.9). It may be a good idea to fall back on white russian while kamikaze is being fixed.

comment:20 Changed 10 years ago by pptp

Using 7.09 2.4 kernel based openwrt on my wrt54gs v1.1 and it reboots after pptp session disconnect.

If I remember correctly White Russian v0.9 did reboot occasionally before pptp session was started.

comment:21 Changed 10 years ago by jeroen@…

Is this problem already fix this moment.

comment:22 Changed 10 years ago by anonymous

No, it is not, using 2.4 based r10627 and it still crashes after pptp session close.

Same thing happens when I run pptp client inside wrt54gs.

This bug will never be fixed for 2.4 kernels, as /ticket/1742.html this ticket says.

comment:23 Changed 9 years ago by florian

  • Resolution set to wontfix
  • Status changed from new to closed

comment:24 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.