Created attachment 349165 [details] Patch to /usr/share/logwatch/scripts/services/iptables Description of problem: 802.1q VLAN subinterfaces have names like eth0.1, eth0.2, eth7.285, etc. The current version drops the subinterface number. The attached patch adds the ability to keep the subinterface info. Version-Release number of selected component (if applicable): logwatch-7.3.6-42.fc11.noarch How reproducible: Always Steps to Reproduce: 1. Set up a physical interface to be an 802.1q trunk 2. Define some VLAN subinterfaces on the trunk interface 3. Set up netfilter/iptables to log packets on the subinterfaces 4. Run the logwatch iptables service report Actual results: All the subinterface traffic is aggregated into the the trunk interface (see below) Expected results: Subinterface traffic info is broken out (see below) Additional info: I'm also submitting this patch upstream. (Live from my machine) example without the patch: --------------------- iptables firewall Begin ------------------------ Listed by source hosts: Accepted 6 packets on interface eth0 From 192.168.1.3 - 3 packets to icmp(8) From 192.168.3.3 - 3 packets to icmp(8) Listed by source hosts: Dropped 14 packets on interface eth0 From 192.168.3.3 - 14 packets to udp(53) ---------------------- iptables firewall End ------------------------- (Live from my machine) example with the patch: --------------------- iptables firewall Begin ------------------------ Listed by source hosts: Accepted 3 packets on interface eth0.2 From 192.168.1.3 - 3 packets to icmp(8) Listed by source hosts: Accepted 3 packets on interface eth0.4 From 192.168.3.3 - 3 packets to icmp(8) Listed by source hosts: Dropped 14 packets on interface eth0.4 From 192.168.3.3 - 14 packets to udp(53) ---------------------- iptables firewall End -------------------------
I just sent your patch to upstream: http://www2.list.logwatch.org:81/pipermail/logwatch-devel/2009-June/002102.html
(In reply to comment #1) > I just sent your patch to upstream: > > http://www2.list.logwatch.org:81/pipermail/logwatch-devel/2009-June/002102.html Well, then they're sure to get it. I sent it upstream to logwatch-patches ...
Re: Status change on 2 Dec How has the bug been modified? There's nothing in updates-testing or even in Koji. Am I missing something?
Allen, I am sorry for confusing you, I applied your patch to my CVS but I haven't commited it to Fedora CVS or built it yet, as adding other patches is a work in progress. I plan to finish the update this week. I hope that is acceptable for you.
logwatch-7.3.6-46.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/logwatch-7.3.6-46.fc11
logwatch-7.3.6-49.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/logwatch-7.3.6-49.fc12
Update has been prepared. Thank you for the patch.
logwatch-7.3.6-46.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update logwatch'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-13395
logwatch-7.3.6-49.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
logwatch-7.3.6-46.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.