This is a discussion on Re: weird ipf/modinfo interaction on Solaris within the IPFilter forums, part of the System Security and Security Related category; I'm seeing it with 3.4. Regarding your other question (Do you also see messages from IPFilter on B ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
I'm seeing it with 3.4. Regarding your other question (Do you also see
messages from IPFilter on B about interfaces "detaching" and then "attaching" ?) - I can reproduce the problem simply by running "ipf -y" which would lead me to conclude that the ipfsync() call is indeed the culprit. Erick. --- Darren Reed <darrenr@reed.wattle.id.au> wrote: > In some email I received from Casper.Dik@Sun.COM, sie wrote: > > > > Well, I just witnessed the exact same happening when logged in to home. > > > > I suppose it has something to do with: > > > > int _info(modinfop) > > struct modinfo *modinfop; > > { > > int ipfinst; > > > > ipfinst = mod_info(&modlink1, modinfop); > > #ifdef IPFDEBUG > > if (ipf_debug) > > cmn_err(CE_NOTE, "IP Filter: _info(%x) = %x", > > modinfop, ipfinst); > > #endif > > if (fr_running > 0) > > ipfsync(); > > return ipfinst; > > } > > > > > > Darren can possibly comment on what the code does and what may cause the > > state information to be lost? > > I believe this is a hangover from very early on and can probably > disappear now. What it is trying to do is use the kernel walking > through all of the modules as an indication that a device has > appeared or disappeared. > > If I look at the current IPFilter code, the two lines: > > if (fr_running > 0) > ipfsync(); > > are no longer present. > > Are you seeing this with 3.4 or 4.1 ? > > Darren > |