Bug 133572 - [ppp] [hang] incoming PPTP connection hangs the system
Summary: [ppp] [hang] incoming PPTP connection hangs the system
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 7.2-PRERELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-10 18:20 UTC by Dennis Melentyev
Modified: 2017-12-31 22:35 UTC (History)
0 users

See Also:


Attachments
file.txt (12.63 KB, text/plain)
2009-04-10 18:20 UTC, Dennis Melentyev
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Melentyev 2009-04-10 18:20:01 UTC
Upgrading from 7.1-RELEASE to 7.2-PRERELEASE as of Apr 2nd caused to
system hangs on incoming PPTP connection.

No panic, no dumps. Just plain frozen everything (network, console, etc).

I am using MPD4 for incoming PPTP sessions with minimal tweaks.
Two external internet links.
Outgoing sessions are perfect.

For incoming sessions I used to try following PF rules:
pass in quick on $uts_if reply-to ( $uts_if $uts_gw ) inet proto gre from any to $uts_addr keep state
pass in quick on $vpn_if reply-to ( $vpn_if $vpn_gw ) inet proto gre from any to $vpn_addr keep state

This doesn't work at all in 7.1-RELEASE (gre packets always got routed
to default route), but could trigger the problem in 7.2-PRERELEASE.

Kernel config attached

Fix: Workaround - deny incoming PPTP. :(

Patch attached with submission follows:
How-To-Repeat: use two external interfaces, with NAT.
mpd4 set up for incoming clients using PPTP
PF set up to reply packets go back via the same interface (TCP/UDP/ICMP/GRE)
Default route points to one of the interfaces.
Kernel has 
options         ROUTETABLES=4
But this tables are not used in no way.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2009-04-10 22:11:38 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 2 Max Laier 2009-04-10 23:47:55 UTC
Is it possible for you to turn on WITNESS on this machine to obtain possible 
LORs that might be responsible for the hang?  Also, do you have the 
possibility to enable DDB and drop into it from the console (if it is not a 
hard hang but a live lock)?

--
  Max
Comment 3 Dennis Melentyev 2009-04-15 11:27:41 UTC
Hi Max,

It was some hard time for me, sorry for late response.

I did enabled KDB, DDB and WITNESS on the same sources.
Unfortunately there was just plain hangs once some GRE was trying to
get through (netgraph? PF? routing?)
With these options enabled, hangs are much more often than without them.
Once hung, no way to break into debugger, no panics, numlock not
changing lights on keyboard, mouse not responding, hdd silent, network
not available, nothing.

3 different HW platforms were tried (all of them were UP+i386+32bit).
Highest CPU temperature was 52C. No chance to go with 7.2-PRERELEASE.

Had to downgrade to 7.1-RELEASE.

/dennis

2009/4/11 Max Laier <max@love2party.net>:
> Is it possible for you to turn on WITNESS on this machine to obtain possi=
ble
> LORs that might be responsible for the hang? =C2=A0Also, do you have the
> possibility to enable DDB and drop into it from the console (if it is not=
 a
> hard hang but a live lock)?
>
> --
> =C2=A0Max
>



--=20
Dennis Melentyev
Comment 4 Dennis Melentyev 2009-04-16 10:28:46 UTC
Hi Max,

Just read your discussion with Matt and Rembrandt on DragonflyBSD list
on OpenBSD's PF issues.

Although I can't afford to restore the configuration to test the
issue, but I feel, that problem could be connected to IPv6 +
PPTP/GRE/PF/IPv4.
The machine we've tried to connect from was running Vista. AFAIR, it
tries to make some use of IPv6. Can't tell anything on XP or other
clients - never tried that.
OTOH, outgoing PPTP (IPv4) session from MPD4 to some HW VPN router
(sorry, anonymous to me) was just fine.

Hope this helps.

I can't upgrade ATM, but still can supply config files if needed.

/dennis

2009/4/15 Dennis Melentyev <dennis.melentyev@gmail.com>:
> Hi Max,
>
> It was some hard time for me, sorry for late response.
>
> I did enabled KDB, DDB and WITNESS on the same sources.
> Unfortunately there was just plain hangs once some GRE was trying to
> get through (netgraph? PF? routing?)
> With these options enabled, hangs are much more often than without them.
> Once hung, no way to break into debugger, no panics, numlock not
> changing lights on keyboard, mouse not responding, hdd silent, network
> not available, nothing.
>
> 3 different HW platforms were tried (all of them were UP+i386+32bit).
> Highest CPU temperature was 52C. No chance to go with 7.2-PRERELEASE.
>
> Had to downgrade to 7.1-RELEASE.
>
> /dennis
>
> 2009/4/11 Max Laier <max@love2party.net>:
>> Is it possible for you to turn on WITNESS on this machine to obtain poss=
ible
>> LORs that might be responsible for the hang? =C2=A0Also, do you have the
>> possibility to enable DDB and drop into it from the console (if it is no=
t a
>> hard hang but a live lock)?
>>
>> --
>> =C2=A0Max
>>
>
>
>
> --
> Dennis Melentyev
>



--=20
Dennis Melentyev
Comment 5 bohdan200 2009-06-08 10:51:15 UTC
Dennis,
maybe this issue is related to
http://www.freebsd.org/cgi/query-pr.cgi?pr=134557
can you confirm this?

-- 
Bohdan Tymkiv <bohdan200@gmail.com>
Comment 6 Dennis Melentyev 2009-06-09 06:51:39 UTC
Not sure. I had no PPPoE. Only PPTP connections.
One is outgoing VPN to ISP and 10 incoming VPNs for employees.
Also, my configuration used to have two uplinks with extensive use of
policy based routing and forwarding.
daemons: mpd4, pf.

It is possible that I have some kind of loops in routing, it was not
very professional set-up :)

BTW, I have no possibility to reproduce the problem since I've
downgraded system to 7.1.

/dennis

2009/6/8 Bohdan Tymkiv <bohdan200@gmail.com>:
> Dennis,
> maybe this issue is related to
> http://www.freebsd.org/cgi/query-pr.cgi?pr=134557
> can you confirm this?
>
> --
> Bohdan Tymkiv <bohdan200@gmail.com>
>
>



-- 
Dennis Melentyev
Comment 7 Mikolaj Golub 2009-06-30 21:00:00 UTC
Could you try the patch from kern/134557?

-- 
Mikolaj Golub
Comment 8 Dennis Melentyev 2009-07-02 11:30:33 UTC
Hi Mikolaj,

2009/6/30 Mikolaj Golub <to.my.trociny@gmail.com>:
>
> Could you try the patch from kern/134557?

Unfortunately, no. I haven't that setup anymore.

-- 
Dennis Melentyev
Comment 9 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:58 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped