I noticed that there is a potential improvement in the way the
ebtables rules are generated from the UCI file. The thing is,
a restart of the firewall does not flush the ebtables, so, the
ebtables have to flushed by adding the ebtables -t broute -F
command in the firewall.qos (or any other script) to remove the
rules generated by firewall.qos. This also flushes the rule that
directed the lookup of the qos chain. Now, to the rule to lookup
qos chain needs to be manually added which I think is not the best
thing to do. The qosmngr should be independent in this regard, hence,
this improvement.
- Renaming lib1905 to libieee1905
- test: Add functional test and docs
- Remove dependency on mq_ APIs
- ubus: Added higher layer response in broadcast list
- Fix crash in ex400
The runner hardware on both the chips are different due to which
the operation of counter read on dg400prime and eg400 units is
actually a read and reset. As a result cumulative counter values
are not available.
To uniformalise the behaviour of qosmngr across platforms, handling
is added to represent cumulative value of counters.
Test:
Scripts that were earlier failing on dg400prime and passing on panther
in the QoS L3 suite were executed and with this fix scripts pass on both
the platforms. This is a good enough indicator beside the manual tests,
that the issue now stands resolved.
Note: pending scripts can now be closed with this fix.
This feature will prove useful to close idle sessions in automation workflows.
On mips 24kc, this feature adds 16 bytes to busybox executable,
therefore its effect on image size is negligible.
Two params are needed to enable wifimngr debugging.
1. env IOP_LLA_LIBS_DEBUG=3 #for debugging only
2. stderr 1
Second param is added and commented out by default.
Signed-off-by: Bartlomiej Grzeskowiak <bartlomiej.grzeskowiak@iopsys.eu>
The handling of ifup event in case of snooping config was missing.
Note: ifup event is generated only for l3 interface, so, say ethx is
member of br-y which has proto none. In this case if ethx link goes
down and comes up again, IPTV will not work without a mcast reload.
From the look of it this will be the case in old version as well and
at the moment I don't know how this can be handled but considering this
is a remote scenario in my opinion I don't think the risk is too high.
I would continue to look for a solution ofcourse.
