- User Since
- Jun 4 2014, 7:25 AM (254 w, 3 d)
It seems this is not enough to prevent panics. Simple kernel module to reproduce the panic.
Fri, Apr 19
Tue, Apr 16
Document GRE-in-UDP in gre(4).
Sun, Apr 14
Sat, Apr 13
Wed, Apr 10
Ok. It is more flexible, but produces additional options. I think ipfw(8) is already very complex.
What if we will make "missing"+"flush" behavior as default.
It seems if user wants to create table, it is expected that later this table will be filled. So, if we are creating some table, and it is already exist, we will check that the table has the same configuration and then flush it.
If configuration is different, then we return error. What you think?
IPv6 has the same code.
Tue, Apr 9
I think you can add to the beginning of your ipfw rules script something like this:
ipfw -q flush ipfw -q table all destroy
And then create needed tables and fill them.
Mon, Apr 8
Sat, Apr 6
Wed, Apr 3
Tue, Apr 2
Mon, Apr 1
Mark, do you suppose that this can fix some another strange panics that appear after epochification?
Sat, Mar 30
Note, that automatic loading for cxgbe can do unexpected firmware update when user does first boot.
Fri, Mar 29
Sat, Mar 23
Fri, Mar 22
Mar 21 2019
I think you may find useful ipfw_pmod module too, it adds support for TCP MSS modification, but, yes, it is not related to IPv6. However, ng_tcpmss does not support TCP over IPv6, but ipfw_pmod does :)
Mar 20 2019
Mar 19 2019
Mar 18 2019
Mar 14 2019
Mar 12 2019
Add missing TOK_STATES_CHUNKS token
Mar 11 2019
Mar 10 2019
Mar 7 2019
Mar 4 2019
I have no objection. AFAIR, the main goal of this change was the adding ability to extend number of entries for some tables, that have very little number of partition entries, e.g. 1 or 2.
I think if you revert this change, then you will not able to add new partitions for these tables, even if there are enough space to keep them.
Feb 20 2019
Feb 19 2019