| #
04051aa3 |
| 19-Jun-2022 |
tb <tb@openbsd.org> |
Make expected output match reality again.
|
| #
4b87b60a |
| 19-Jun-2022 |
tb <tb@openbsd.org> |
Fix rttest output after rtsock.c r1.329 that RTF_DONE to routes sent
via sysctl(2)
|
| #
e41b73a8 |
| 12-Feb-2018 |
mpi <mpi@openbsd.org> |
Revert previous, the changed has been backed out and I wasn't running
the last snaphot.
|
| #
7662e8b6 |
| 12-Feb-2018 |
mpi <mpi@openbsd.org> |
Fix most outputs now that lo5 is getting 127.0.0.1 automagically.
|
| #
e56f6a14 |
| 01-Sep-2016 |
bluhm <bluhm@openbsd.org> |
Now the cached route flag appears in "route show". Adapt test.
OK mpi@
|
| #
fdf14b9a |
| 22-Aug-2016 |
mpi <mpi@openbsd.org> |
Sync counters now that ifa_ifwithroute() no longer uses ifa_ifwithnet().
|
| #
93cc7302 |
| 19-Jul-2016 |
mpi <mpi@openbsd.org> |
Update counters & unbreak now that rtrequest(RTM_ADD, ...) caches the
gateway.
|
| #
1797eada |
| 09-Nov-2015 |
mpi <mpi@openbsd.org> |
Match recent rtalloc(9) rewrite.
Gateway routes are now cached the first time they are used and no longer
when they are added. This allows to track down which multipath route is
being selected as n
Match recent rtalloc(9) rewrite.
Gateway routes are now cached the first time they are used and no longer
when they are added. This allows to track down which multipath route is
being selected as next-hop.
show more ...
|
| #
bcdff9df |
| 23-Sep-2015 |
mpi <mpi@openbsd.org> |
Sync with recent rt_use change.
|
| #
3da2c6ff |
| 29-Oct-2014 |
mpi <mpi@openbsd.org> |
Update test outputs to reflect the fact that routes to loopback addresses
are plain local routes.
|
| #
cf51975e |
| 14-May-2014 |
claudio <claudio@openbsd.org> |
Adjust route outputs to the new lo(4) MTU which is now the same on all archs.
Makes this regress work again.
|
| #
f42cad18 |
| 18-Apr-2014 |
claudio <claudio@openbsd.org> |
Introduce some regress tests against our routing table. At least that way
there is a chance that we do not break the network stack even more.
These regress tests already found a few issues.
The frame
Introduce some regress tests against our routing table. At least that way
there is a chance that we do not break the network stack even more.
These regress tests already found a few issues.
The framework is ugly and does not properly recover from failures. Somebody
more skilled can come up with a better solution.
mpi@, blambert@ and sthen@ support this
show more ...
|