* [PATCH iproute2] ip monitor: Fixed printing timestamp few times
@ 2014-11-30 23:14 Vadim Kochan
2014-12-03 17:13 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: Vadim Kochan @ 2014-11-30 23:14 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
Another fix when timestamp is printed few times
before the event message.
Fixed by skipping the message types which are not supported.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
ip/ipmonitor.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index 4cc75f4..5c3ed18 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -42,6 +42,15 @@ static int accept_msg(const struct sockaddr_nl *who,
{
FILE *fp = (FILE*)arg;
+ if (n->nlmsg_type == RTM_NEWQDISC ||
+ n->nlmsg_type == RTM_DELQDISC ||
+ n->nlmsg_type == RTM_NEWTCLASS ||
+ n->nlmsg_type == RTM_DELTCLASS ||
+ n->nlmsg_type == RTM_NEWTFILTER ||
+ n->nlmsg_type == RTM_DELTFILTER ||
+ n->nlmsg_type == RTM_NEWNDUSEROPT)
+ return 0;
+
if (n->nlmsg_type == RTM_NEWROUTE || n->nlmsg_type == RTM_DELROUTE) {
struct rtmsg *r = NLMSG_DATA(n);
int len = n->nlmsg_len - NLMSG_LENGTH(sizeof(*r));
@@ -134,14 +143,6 @@ static int accept_msg(const struct sockaddr_nl *who,
fprintf(fp, "Timestamp: %s %lu us\n", tstr, usecs);
return 0;
}
- if (n->nlmsg_type == RTM_NEWQDISC ||
- n->nlmsg_type == RTM_DELQDISC ||
- n->nlmsg_type == RTM_NEWTCLASS ||
- n->nlmsg_type == RTM_DELTCLASS ||
- n->nlmsg_type == RTM_NEWTFILTER ||
- n->nlmsg_type == RTM_DELTFILTER ||
- n->nlmsg_type == RTM_NEWNDUSEROPT)
- return 0;
if (n->nlmsg_type != NLMSG_ERROR && n->nlmsg_type != NLMSG_NOOP &&
n->nlmsg_type != NLMSG_DONE) {
fprintf(fp, "Unknown message: type=0x%08x(%d) flags=0x%08x(%d)"
--
2.1.3
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
2014-12-03 17:13 ` Stephen Hemminger
@ 2014-12-03 17:11 ` vadim4j
2014-12-03 17:47 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: vadim4j @ 2014-12-03 17:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
On Wed, Dec 03, 2014 at 09:13:38AM -0800, Stephen Hemminger wrote:
> I don't see how you could get into accept_msg and cause this.
>
> The filtering should already be done by kernel for most things.
> The code already filters TC messages in kernel. Other types
> should be done as well.
I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
So in this case the message will be skipped with printed timestamp.
> Ps: this code is crying to be a switch statement.
I agree.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
2014-11-30 23:14 [PATCH iproute2] ip monitor: Fixed printing timestamp few times Vadim Kochan
@ 2014-12-03 17:13 ` Stephen Hemminger
2014-12-03 17:11 ` vadim4j
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2014-12-03 17:13 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
On Mon, 1 Dec 2014 01:14:22 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> Another fix when timestamp is printed few times
> before the event message.
>
> Fixed by skipping the message types which are not supported.
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
I don't see how you could get into accept_msg and cause this.
The filtering should already be done by kernel for most things.
The code already filters TC messages in kernel. Other types
should be done as well.
Ps: this code is crying to be a switch statement.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
2014-12-03 17:47 ` Stephen Hemminger
@ 2014-12-03 17:41 ` vadim4j
2014-12-04 21:43 ` Vadim Kochan
0 siblings, 1 reply; 6+ messages in thread
From: vadim4j @ 2014-12-03 17:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
On Wed, Dec 03, 2014 at 09:47:31AM -0800, Stephen Hemminger wrote:
> On Wed, 3 Dec 2014 19:11:26 +0200
> vadim4j@gmail.com wrote:
>
> > I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
> > So in this case the message will be skipped with printed timestamp.
>
> Can that be decoded? it might be useful.
Sorry, you mean how it can be reproduced by clean scenario?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
2014-12-03 17:11 ` vadim4j
@ 2014-12-03 17:47 ` Stephen Hemminger
2014-12-03 17:41 ` vadim4j
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2014-12-03 17:47 UTC (permalink / raw)
To: vadim4j; +Cc: netdev
On Wed, 3 Dec 2014 19:11:26 +0200
vadim4j@gmail.com wrote:
> I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
> So in this case the message will be skipped with printed timestamp.
Can that be decoded? it might be useful.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
2014-12-03 17:41 ` vadim4j
@ 2014-12-04 21:43 ` Vadim Kochan
0 siblings, 0 replies; 6+ messages in thread
From: Vadim Kochan @ 2014-12-04 21:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
Hi Stephen,
Seems that problem is that by default ipmonitor subscribes to the all
RTNL groups except RTMGRP_TC:
groups = ~RTMGRP_TC;
And I assume that other netlink messages can also cause such
Timestamping w/o event message ...
So I think there should be another way than ~RTMGR_TC, and this big IF
in accept_msg can be removed.
Regards,
Vadim
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-12-04 21:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-30 23:14 [PATCH iproute2] ip monitor: Fixed printing timestamp few times Vadim Kochan
2014-12-03 17:13 ` Stephen Hemminger
2014-12-03 17:11 ` vadim4j
2014-12-03 17:47 ` Stephen Hemminger
2014-12-03 17:41 ` vadim4j
2014-12-04 21:43 ` Vadim Kochan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).