dhcpagent + ipfilter := delayed loss of IP functionality?
in [Solaris]
|
From: Jeroen Scheerder on 16 Jan 2010 16:42 Oscar del Rio <delrio(a)mie.utoronto.ca> wrote: > > pass in quick on hme0 proto tcp from any to any port = 993 keep state > > Your (TCP) "keep state" rules are missing the "FLAGS S" option. > It's possible that the state tables are filling up because of this. > > See the IPFilter FAQ: Nice one, thanks. I doubt that's it; wouldn't ipf log something about state table exhaustion? And isn't it strange that it predictably happens a 24h after booting, coinciding with (related to?) a DHCP renewal?
From: Jeroen Scheerder on 16 Jan 2010 16:45 Richard B. Gilbert <rgilbert88(a)comcast.net> wrote: > If you remove IPFILTER for testing purposes do things broken start > working? Thanks, but it's not like that. Nothing's broken, everything works. It's just that things break down after a while. Unless I disable ipfilter altogether. I know it's strange. > If they still don't work you have eliminated IPFILTER as the > "sole cause" of your problems. With ipfilter disabled things stay sane. Why is so far not understood.
From: Richard B. Gilbert on 16 Jan 2010 17:14 Jeroen Scheerder wrote: > Richard B. Gilbert <rgilbert88(a)comcast.net> wrote: > >> If you remove IPFILTER for testing purposes do things broken start >> working? > > Thanks, but it's not like that. Nothing's broken, everything works. > It's just that things break down after a while. Unless I disable > ipfilter altogether. I know it's strange. > >> If they still don't work you have eliminated IPFILTER as the >> "sole cause" of your problems. > > With ipfilter disabled things stay sane. Why is so far not understood. Well, you at least know WHERE your problem is! Something in IPFILTER or your IPFILTER configuration is almost certainly at fault. Some bug in IPFILTER seems most likely! I can't think of anything in the configuration of IPFILTER that would cause your problem. Is the timing consistent? That is, does the problem always start at some specific time of day or does IPFILTER work properly for X hours and Y minutes after restart and then screw up? It might also be related to packet count in or out or even byte count in or out. -- draco vulgaris
From: HankVC on 17 Jan 2010 02:10 In article <z6ednQhHgJC3QczWnZ2dnUVZ_gidnZ2d(a)giganews.com>, Richard B. Gilbert <rgilbert88(a)comcast.net> wrote: > >Do you really NEED ipfilter? My router, by default, will not allow any >incoming packet to pass unless it is a response to outgoing traffic. >It's simple, relatively cheap, and it works! (LinkSys BEFR81) > And tell me how I am going to run a mail server and an apache server that expect unsolicited incoming traffic. And a consumer-grade Linksys router to boot. You're not talking about enterprise systems with this sort of thing. We aren't doing "Windows or Mac" here. Hank
From: Jeroen Scheerder on 17 Jan 2010 05:07
Richard B. Gilbert <rgilbert88(a)comcast.net> wrote: > > With ipfilter disabled things stay sane. Why is so far not understood. > > Well, you at least know WHERE your problem is! Something in IPFILTER or > your IPFILTER configuration is almost certainly at fault. Some bug in > IPFILTER seems most likely! I can't think of anything in the > configuration of IPFILTER that would cause your problem. > > Is the timing consistent? That is, does the problem always start at > some specific time of day or does IPFILTER work properly for X hours and > Y minutes after restart and then screw up? It might also be related > to packet count in or out or even byte count in or out. It seems to be happen in lockstep with DHCP renewal (but not DHCP extensions). I've added a few 'log' statements, added explicit allows for UDP 67 and 68, added 'flags S' to my incoming TCP rules and enabled ipfilter again. The result of this experiment is: loss of functionality after a while. Post-mortem will no doubt show nothing in /var/adm/messages nor /var/log/*, except that the system kept on running until powercycled. |