- 23 Feb, 2021 1 commit
-
-
Stefan Schantl authored
This caused to gain the following error when building: Only one of PREFIX or INSTALL_BASE can be given. Not both. Using INSTALLDIRS=vendor is the common way to get the modules installed into the right directories. Fixes #12573. Signed-off-by:
Stefan Schantl <stefan.schantl@ipfire.org> Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
- 25 Jan, 2021 2 commits
-
-
Peter Müller authored
These are nothing to worry about, which is why debug log facility is more suitable here than informational or warning. Signed-off-by:
Peter Müller <peter.mueller@ipfire.org> Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Peter Müller authored
2002::/16 is an anycast prefix for 6to4 scenarios, as specified in RFC 3068. We currently process an announcement from Hurricane Electric for it, and since it is an anycast network, multiple entities across the world announce it as well. Thereof, it does not make sense to include it in the database - as of today, we do not have a country for it, either. Signed-off-by:
Peter Müller <peter.mueller@ipfire.org> Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
- 23 Dec, 2020 1 commit
-
-
Peter Müller authored
Fixes: #12549 Signed-off-by:
Peter Müller <peter.mueller@ipfire.org> Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
- 21 Dec, 2020 1 commit
-
-
Michael Tremer authored
Fixes: #12554 Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
- 02 Dec, 2020 1 commit
-
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
- 01 Dec, 2020 1 commit
-
-
Michael Tremer authored
We used to simply take the first element from the stack after we have split a network. That is wrong because it is not passing through any filters and no further subnet checks. It could have therefore been that the tree was not entirely flat. Reported-by:
Arne Fitzenreiter <arne_f@ipfire.org> Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
- 27 Nov, 2020 5 commits
-
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
This cannot happen and generated a compiler warning Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
- 26 Nov, 2020 4 commits
-
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
The list was otherwise not sorted Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
- 25 Nov, 2020 14 commits
-
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
When we check the result for any overlaps, we can cut this short by walking through both lists from start to end and remember the last network that we checked. The next one will by definition be strictly greater and therefore we do not need to check anything before this any more. Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Everything is encoded in IPv6 anyways... Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
The list was unfortunately halved in size every time an element was taken from it, which was great for performance, but shortened the result substantially. Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
- 24 Nov, 2020 10 commits
-
-
Michael Tremer authored
This is helpful because very often we walk through a list in order and are most interested in the last element. Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
This is now being done immediately instead of creating a new list which is being merged later. Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
When finish splitting networks into many parts, we have a list of subnets with the excluded subnets and merge them together first and put them on the stack again. This is slower than pushing it all onto the stack first and then popping the first element. Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-
Michael Tremer authored
Since the list is always sorted, there is no point in sorting it again... Signed-off-by:
Michael Tremer <michael.tremer@ipfire.org>
-