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.
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
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
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
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
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>
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
Could you try the patch from kern/134557? -- Mikolaj Golub
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
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
^Triage: I'm sorry that this PR did not get addressed in a timely fashion. By now, the version that it was created against is long out of support. Please re-open if it is still a problem on a supported version.