[SOLVED] RRD-graphs not capturing interface traffic

[stoffix]

As the subject says, the RRD-graphs is not showing proper interface traffic.
It may be some configuration mistake from my side, if so, i would like to
know the proper way to configure my network.

My router has 5 interfaces, set up as 1 wan, and 4 lan.
I only have one lan network, so the four lan ports is configured
as bridge1, which is set as the lan interface.

when transferring data from "opt1" to "opt2" I would expect this
to show up in the rrd-graphs for the interface, but the rrd-graphs for
i.e. "opt1" is empty, apart from some 0.8kbit noise.

the rrd-graphs for "lan" shows both "opt1", and "opt2" traffic (send/recieve).

Is it something wrong with the rrd-graphs, or in my configuration?

[wallabybob]

I SUSPECT data for the RRD graphs comes out of the packet filter. You may have disabled the packet filter on bridge member interfaces (via a tunable, a common recommendation).

[stoffix]

You were right!
I re-enabled the packet filter on the bridge members, and thought (hoped) everything was fine,
and initially, it seemed to be.

Then our network printer stopped working :(
After some searhing, I made a new rule to each member interface of the bridge. (my lan)
(Source=lan subnet; rest = any) allow (kind of copy 'n paste from google)

Have I done something stupid now, or is this the "proper" way to do this?

I also noted this message in the system logs while changing the system tunable back and forth:
php: /system_advanced_sysctl.php: The command '/sbin/sysctl vfs.forcesync="0"' returned exit code '1', the output was 'sysctl: oid 'vfs.forcesync' is read only'

Should this be posted somewhere else?

[wallabybob]

@stoffix:

Then our network printer stopped working :(
After some searhing, I made a new rule to each member interface of the bridge. (my lan)
(Source=lan subnet; rest = any) allow (kind of copy 'n paste from google)

The printer works now?

@stoffix:

Have I done something stupid now, or is this the "proper" way to do this?

Since you moved packet filtering from the bridge interface to member interfaces (none of which is LAN) the default filtering on the bridge member interfaces would likely be "block everything". Hence to get equivalent behaviour you would need to copy your LAN interface rules to all your bridge member interfaces. The "proper" action is to set the firewall rules to what you really want.

@stoffix:

I also noted this message in the system logs while changing the system tunable back and forth:
php: /system_advanced_sysctl.php: The command '/sbin/sysctl vfs.forcesync="0"' returned exit code '1', the output was 'sysctl: oid 'vfs.forcesync' is read only'

Some sysctls can be changed only at boot time. I suspect this is one of those. This sort of thing can make the system log a bit ugly but I don't think there is an easy fix except perhaps don't set any sysctls to their present value.

[stoffix]

@wallabybob:

The printer works now?

Yes, It works now, I forgot to say it does.

@wallabybob:

@stoffix:

Have I done something stupid now, or is this the "proper" way to do this?

Since you moved packet filtering from the bridge interface to member interfaces (none of which is LAN) the default filtering on the bridge member interfaces would likely be "block everything". Hence to get equivalent behaviour you would need to copy your LAN interface rules to all your bridge member interfaces. The "proper" action is to set the firewall rules to what you really want.

After eyeballing the new rules, I see that this is just what I have done (for ipv4, I don't use ipv6).

@wallabybob:

@stoffix:

I also noted this message in the system logs while changing the system tunable back and forth:
php: /system_advanced_sysctl.php: The command '/sbin/sysctl vfs.forcesync="0"' returned exit code '1', the output was 'sysctl: oid 'vfs.forcesync' is read only'

Some sysctls can be changed only at boot time. I suspect this is one of those. This sort of thing can make the system log a bit ugly but I don't think there is an easy fix except perhaps don't set any sysctls to their present value.

Ok, that kind of explains it. I didn't change that sysctl, but I guess all sysctls gets updated when I apply changes, even just to one sysctl.