Just because you don't like using something does not mean that it isn't
the best solution for the problem. Or at least a better one.
> I'd prefer having a /etc/packet.deny file kinda like login.access, like:
> <+/->:<icmp/udp/tcp/ALL/etc>:<ip address/ALL>:<port/ALL> .
> Something like that, it looks similar to the syntax of ipfwadm, but I feel
> that this method would be 90 times easier then ipfwadm with the 300 diff
> -options and its much easier to access/change the list then ipfwadm. I
> think the program should be run like inetd.conf, where u need to kill -HUP
> <whatever ps> to refresh it.
Why does this need to be implemented in the kernel? There is nothing
inherently useful about that kind of format for IP firewalling rules.
How do you handle masquerading and other forwarding?
If all you want is something like that to define IP firewalling entries,
go write a shell script that parses a file of that shape into ipfwadm
rules. There is _no_ reason for it to live in the kernel.
> I'd just like something similar or better then this implemented in
> an upcoming *stable* kernel version. Send me your comments/suggestions...
As far as can be seen, 2.0.30 and 2.0.31 are _stable_, even if slightly
buggy and lacking some things. What is it about 2.0.30 or .31 that makes
you say that it's unstable? If you've been able to panic it, why not
find out why, so that it _can_ be made more stable, without just saying
"it's unstable" without having any cause to say so?
On a lighter note, I _do_ believe there is some problem in networking
code, although I'm still trying to narrow down the possibilities of where
it may lie. It's a problem between my linux box and a Cisco AGS terminal
server. Before, running 2.0.30 and pppd 2.2.0f, I'd see this interesting
problem of packets not going out through the ppp interface, except when
they were going to the gateway terminal server. I upgraded to pppd-2.3.1
and the problem seemed to go away. Now I upgraded to 2.0.31, and it seems
to come back every so often, and I'm seeing ip <7>MASQ:... errors in
my syslog again. Rutgers claims that they _know_ of a terminal server
problem (misconfiguration) which was causing this problem, but that it
should have been fixed a while ago, and if I'm still seeing the problem,
then it's really bizarre.
I'm still seeing the problem, but what's weird was that I wasn't seeing
it under 2.0.30 + pppd 2.3.1, but I am under .31.
Also: the ppp kernel modules that came with pppd 2.3.1 do _not_ compile
cleanly under 2.0.31! The ppp modules that come standard with 2.0.31
compile fine. As far as I can tell, pppd 2.3.1 is expecting to use its
own ppp modules, and not the standard linux ones (?)! Anyone verify
this? Right now, I'm still using the standard 2.0.31 ppp modules.
The problem with the pppd 2.3.1 modules not compiling seems to be related
to a change in the linux if_ppp.h and if_pppvar.h files, as some
structure definitions seem to be mismatched. Since I don't talk to the
maintainers or either source tree, I have no idea if there was
intentionality there...
Anyhow, either it'll get fixed, or I'll break it real bad, and get it
to compile. =)
-Dossy
-Dossy
--
URL: http://www.panoptic.com/~dossy -< BORK BORK! >- E-MAIL: dossy@panoptic.com
Now I'm who I want to be, where I want to be, doing what I've always said I
would and yet I feel I haven't won at all... (Aug 9, 95: Goodbye, JG.)
"You should change your .sig; not that the world revolves around me." -s. sadie