Summary: | IPFire 164 Dev Build - Empty entries in FW log | ||
---|---|---|---|
Product: | IPFire | Reporter: | Alex Neth <Alexander.Neth> |
Component: | --- | Assignee: | Peter Müller <peter.mueller> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | Balancing | ||
Priority: | - Unknown - | CC: | arne.fitzenreiter, Christof.Misch, michael.tremer, peter.mueller, stefan.schantl |
Version: | 2 | ||
Hardware: | all | ||
OS: | All |
Description
Alex Neth
2022-02-17 17:26:52 UTC
Hi, this was accidentally introduced in commit 0e7bfb1343d28069acfbaacb957cd199f8ead099. While fixing this should not be a difficult task in technical term, two aspects prevent me from doing that: 1. Right now, LOG_DROP only logs things without any prefix. But since we don't know the direction of a packet conntrack marked as INVALID, we cannot easily use DROP_{INPUT,OUTPUT,FORWARD}. On the other hand, I don't think it is wise to introduce _another_ log prefix - we have (too ?) many of these already. 2. It would be interesting to see why conntrack decided to flag these packets as INVALID. It is good to get such events _logged_, and I think that might clarify some firewall malfunctions we never figured out before. However, I cannot get rid of the feeling something is off at conntrack. Any opinions, especially to (1)? Thanks, and best regards, Peter Müller (In reply to Peter Müller from comment #1) > 1. Right now, LOG_DROP only logs things without any prefix. But since we > don't know the direction of a packet conntrack marked as INVALID, we cannot > easily use DROP_{INPUT,OUTPUT,FORWARD}. On the other hand, I don't think it > is wise to introduce _another_ log prefix - we have (too ?) many of these > already. Why not? If you want to know why something got dropped, you will have to log it. Certainly, and I think it is good to have these packets logged. But what log prefix should we use? DROP_CONNTRACK? (In reply to Peter Müller from comment #3) > But what log prefix should we use? DROP_CONNTRACK? Why not DROP_INVALID? > Why not DROP_INVALID?
Hm, wouldn't this lead to confusions with DROP_NEWNOTSYN and the BADTCP stuff?
In a way, they can all be considered "invalid"...
(In reply to Peter Müller from comment #5) > > Why not DROP_INVALID? > > Hm, wouldn't this lead to confusions with DROP_NEWNOTSYN and the BADTCP > stuff? > In a way, they can all be considered "invalid"... Yes they would, but I wouldn't have mixed those things together. To be entirely clear you could go with DROP_CTINVALID > To be entirely clear you could go with DROP_CTINVALID I like it. Patch sent: https://patchwork.ipfire.org/project/ipfire/patch/c9cdec8e-bec6-1793-2b8e-7a83e6f7d2d8@ipfire.org/ Nice! That’s what I call efficient :-D Arne asked me to provide a switch to disable logging for such events anyway. It seems as conntrack drops a lot of (at the first glance legitimate) packets, which bloats the logs and makes more serious log events harder to spot. While I don't think logging for this should ever be disabled in production, his argumentation made sense to me. Therefore, I will apply the aforementioned patch to "next", add another one for toggling logging, and will request both patches to be cherry-picked into "master" when I'm done. Done. Arne, kindly cherry-pick these commits from "next": - https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5ca74566b3404539b46c904aaec0ac7e4033657f - https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=8269c8319ccb9e78c8c48a4218396621d5a156e3 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5c1af49c835921232a0312819025fb08dddae4b3 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=926d840faeafe9528532f42aa12a0922188c1959 Hi, I just upgraded to Core Update 164 Development Build: master/3b45d956 My Log gets flooded with DROP_CTINVALID May be because of this change? Not a topic to this bug report... I just wanted to report that the upgrade to this version on XEN HVM client was successfull! (As Peter asked for testing on XEN.) have two findings: grep FATAL update-core-upgrade-164.log modprobe: FATAL: Module nf_log_ipv4 not found in directory /lib/modules/5.15.6-ipfire I think thats not Problem but may be resolved somehow. Console output during boot Creating Squid swap directories... [ OK ] Starting Squid Proxy Server... Unable to continue: /usr/sbin/squid is running [ WARN ] BUT Squid is down! I have this Problem for a long time ... maybe same as https://bugzilla.ipfire.org/show_bug.cgi?id=12623 Sorry for writing the update check outcome to this Bug report too ... |