patch
reverts changes introduced by those redundant patches.
Signed-off-by: Alexander Zubkov
---
ip/iproute.c | 65 ++--
lib/utils.c | 13
2 files changed, 46 insertions(+), 32 deletions(-)
diff --git a/ip/iproute.c b/ip
ephen Hemminger" :
> On Tue, 27 Mar 2018 18:29:31 +0200
> Alexander Zubkov wrote:
>
>> Hi Stephen,
>>
>> Looks like the new patch was applied after the revert of original patch and
>> fix patch for 4.15 branch. Which is not correct and I did not test it. This
&
to do things right in master
branch
27.03.2018, 18:01, "Stephen Hemminger" :
> On Wed, 14 Mar 2018 21:26:40 +0100
> Alexander Zubkov wrote:
>
>> Hello,
>>
>> For example, it can be fixed in such way (patch is below):
>> - split handling of default
This version of patch is for master now.
18.03.2018, 17:50, "Alexander Zubkov" :
> Debian maintainer found that basic command:
> # ip route flush all
> No longer worked as expected which breaks user scripts and
> expectations. It no longer flushed all IPv4 routes.
&g
"all"/"any" always matches anything in exact, root and match
modes.
Reported-by: Luca Boccassi
Signed-off-by: Alexander Zubkov
---
lib/utils.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/lib/utils.c b/lib/utils.c
index 37973
answer for some more time, I'll
consider that fix as suitable and send it as a proper patch to the list. That
will not require reverse patch too.
16.03.2018, 21:37, "Stephen Hemminger" :
> On Tue, 13 Mar 2018 21:19:45 +0100
> Alexander Zubkov wrote:
>
>> Debian maint
D;
bitlen = plen;
} else {
if (dst->bitlen == -2)
bitlen = 0;
- else
- flags = 0;
}
dst->flags |= flags;
On 14.03.2018 09:59, Alexander Zubkov wrote:
Hello,
There was a
unspecified family or change filtering logic.
I have added Serhey Popovych in the recepients, so he can give some ideas on
what his aim is and help choose better solution.
13.03.2018, 21:12, "Alexander Zubkov" :
> Hi,
>
> I just realized that you need patch for v4.15.0, which is easier
"all"/"any" was altered too, because they
were the same branch of the code. As those parameters mean different,
they need to be treated differently in code too. This patch reflects
the difference.
Reported-by: Luca Boccassi
Signed-off-by: Alexander Zubkov
---
lib/utils.c | 3 ++-
Hi,
I just realized that you need patch for v4.15.0, which is easier to do.
I'll send it as separate message now. I will make patch for the master
branch, but later.
On 13.03.2018 13:02, Luca Boccassi wrote:
On Tue, 2018-03-13 at 12:05 +0100, Alexander Zubkov wrote:
Hello again,
Th
hink if "ip route ls [all|any]" shows all routes and "ip route
ls default" shows only default, everybody will be happy with that?
13.03.2018, 09:46, "Alexander Zubkov" :
> Hello.
>
> May be the better way would be to change how "all"/"any"
Hello.
May be the better way would be to change how "all"/"any" argument behaves? My
original concern was about "default" only. I agree too, that "all" or "any"
should work for all routes. But not for the default.
12.03.2018, 22:37, "Luca Boccassi" :
> On Mon, 2018-03-12 at 14:03 -0700, Stephen
Nov 2017 14:12:48 +0100
> Alexander Zubkov wrote:
>
>> Hello,
>>
>> I have found odd behaviour when using "ip route list" (and other bound
>> commands) with prefix "default".
>>
>> When family not specified, its value is completely ignored
Metric is one of the "unique key" fields of the route in Linux. But
still one can not use its value in filter while running ip list.
Because of this writing checks in scripts for example is incovenient.
Signed-off-by: Alexander Zubkov
---
ip/iproute.c | 21 -
1 fi
same all-zeroes value like no prefix specified at all. Thus
following code blindly ignores the fact, that prefix was actually
specified.
This patch adds the flag PREFIXLEN_SPECIFIED to the default route too.
And then checks its value when filtering routes.
Signed-off-by: Alexander
Hello everybody,
I will be glad to hear a piece of feedback on this proposal.
On Sat, Nov 18, 2017 at 5:56 PM, Alexander Zubkov wrote:
> I also opened earlier a ticket in bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=197899
> And Stephen Hemminger had couple of comments ther
Hello everybody,
Excuse me for probably being impatient. But may I have some feedback
on my proposal?
On Sat, Nov 18, 2017 at 11:11 AM, Alexander Zubkov wrote:
> I think this version will be better. It uses metric mask (like for
> some other options) instead of simple yes/no flag.
>
be other opinions.
On Sat, Nov 18, 2017 at 2:12 PM, Alexander Zubkov wrote:
> Hello,
>
> I have found odd behaviour when using "ip route list" (and other bound
> commands) with prefix "default".
>
> When family not specified, its value is completely ignor
Hello,
I have found odd behaviour when using "ip route list" (and other bound
commands) with prefix "default".
When family not specified, its value is completely ignored and "ip
route list default" shows all inet4 prefixes. Same do "ip route list
exact default" and "ip route list match default".
I think this version will be better. It uses metric mask (like for
some other options) instead of simple yes/no flag.
On Sat, Nov 18, 2017 at 2:44 AM, Alexander Zubkov wrote:
> Hello again,
>
> Things turned out to be not so hard. Please take a look at the attached patch.
> I'm
Nov 17, 2017 at 1:40 AM, Alexander Zubkov wrote:
> Hello all,
>
> Currently routes in the Linux routing table have these "key" fields:
> prefix, tos, table, metric (as I know). I.e. we cannot have two
> different routes with the same set of this fields. And "ip route l
t as I see it parses arguments and fills some
structures. And then my tries to understand failed.
I opened the bug: https://bugzilla.kernel.org/show_bug.cgi?id=197897,
but I was pointed out that this mailing list is a better place for
this question.
--
Alexander Zubkov
22 matches
Mail list logo
