Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
On Mon, 16 Sep 2019 14:44:57 +, Petr Machata wrote: > So you want to change the current TLV? I guess that's reasonable, since > it is essentially an internal API. Whatever, just have a way to extend this in the future, while allowing the tools compiled today to still work after the extension. Jiri ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
> -Original Message- > From: Petr Machata [mailto:pe...@mellanox.com] > Sent: Monday, September 16, 2019 2:56 AM > To: Keller, Jacob E > Cc: Jiri Benc ; linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying > TLV_PORT_PROPERTIES_NP > > > Keller, Jacob E writes: > > Right, but part of namespacing is that processes inside the namespace > > should generally not know they are, and not be aware of anything > > outside the namespace... > > I'm not sure I agree the process inside the namespace should be > disallowed from knowing it is. I'm not really well versed in network > namespaces, but looking at what "ip netns id" is doing under the hood it > looks like the kernel has interfaces to just tell you (RTM_GETNSID). > > Thanks, > Petr Fair enough, I wasn't sure exactly what was hidden or not. Thanks, Jake ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
Jiri Benc writes: > On Mon, 16 Sep 2019 09:56:29 +, Petr Machata wrote: >> Inside the namespace you can do "ip netns id" to get the namespace that >> you are in. > > Beware that this netnsid is only valid in the net name space that the > 'ip' command ran in. It is not a global identifier and it is not valid > in another net name space. > > In other words, ptp4l can't return a netnsid valid in the pmc net > name space (without doing gross and unreliable hacks). I was actually thinking about /var/run/netns being mounted elsewhere or some such, which would prevent "ip netns id" from working. The symbolic names seem to be accessible from other namespaces just fine --"ip netns exec foo ip netns exec bar bash" works-- but renaming /var/run breaks it. I'm probably just missing something, I haven't worked with network namespaces much. >> ptp4l already has a public API to obtain the device name: the VLA >> itself. There just isn't an easy way to invoke that interface. So we >> don't have to concern ourselves with whether to hide the interface name >> itself, that ship has sailed. > > If the API is so hard that it's not in use in practice, it makes a > difference. Yeah, conceded, random admins probably wouldn't do this. >> About the namespace--as an unprivileged process you can't just ask about >> netns ids of random processes. So whether to allow ptp4l to give up this >> information is a good question, because that might go against the >> intentions of the admin of the machine. > > It also does not work, see above :-) Agreed. >> I'm not sure I agree the process inside the namespace should be >> disallowed from knowing it is. I'm not really well versed in network >> namespaces, but looking at what "ip netns id" is doing under the hood it >> looks like the kernel has interfaces to just tell you (RTM_GETNSID). > > Since every process is in a net name space (and exactly one net name > space), it already knows by definition that it is in a name space :-) > > Whether referencing into other net name spaces makes sense or not, > depends on the use. I'd argue that a daemon (such as ptp4l) should not > mess with name spaces, as it needs the administrator to be able to run > it in whatever net name space they chooses. But it can certainly query > it if it is needed for proper interoperability. > >> Maybe just documenting the issue is all that can be done. > > Could be. I don't have other ideas than this. I also think that having an easy to use way to access the interface outweighs the risks. ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
Jiri Benc writes: > On Mon, 16 Sep 2019 14:04:00 +, Petr Machata wrote: >> I was actually thinking about /var/run/netns being mounted elsewhere or >> some such, which would prevent "ip netns id" from working. The symbolic >> names seem to be accessible from other namespaces just fine --"ip netns >> exec foo ip netns exec bar bash" works-- but renaming /var/run breaks >> it. > > /var/run/netns is a convention introduced by iproute2 and respected by > many, but sadly not all, other net management systems. There is no > concept of netns names in the kernel. > > And it is a completely different thing than netnsids. The netns mounts > allow you to get a file descriptor referencing the target net name > space unambiguously. Such fd can be used for many operations, most > importantly to switch yourself into that net name space (see setns(2)). > You can obtain the fd by other means, too, for example by > opening /proc//ns/net. > > netnsid is a different integer. It is valid only in the net name space > it was created in and references a target net name space. It can be > used only in netlink operations. It is completely managed by the kernel > and does not require the netns to be mounted nor /proc to be mounted. Thanks for clearing this up for me. I saw the netnsid thing in the man but didn't know what it was for. >> I don't have other ideas than this. I also think that having an easy to >> use way to access the interface outweighs the risks. > > I think proper documentation might help. Add a warning that this > doesn't work across net name spaces and ensure that the API is flexible > enough to allow a new field to be added in the future without breaking > backwards compatibility if we ever need to start communicating also a > netns identifier. So you want to change the current TLV? I guess that's reasonable, since it is essentially an internal API. ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
On Mon, 16 Sep 2019 14:04:00 +, Petr Machata wrote: > I was actually thinking about /var/run/netns being mounted elsewhere or > some such, which would prevent "ip netns id" from working. The symbolic > names seem to be accessible from other namespaces just fine --"ip netns > exec foo ip netns exec bar bash" works-- but renaming /var/run breaks > it. /var/run/netns is a convention introduced by iproute2 and respected by many, but sadly not all, other net management systems. There is no concept of netns names in the kernel. And it is a completely different thing than netnsids. The netns mounts allow you to get a file descriptor referencing the target net name space unambiguously. Such fd can be used for many operations, most importantly to switch yourself into that net name space (see setns(2)). You can obtain the fd by other means, too, for example by opening /proc//ns/net. netnsid is a different integer. It is valid only in the net name space it was created in and references a target net name space. It can be used only in netlink operations. It is completely managed by the kernel and does not require the netns to be mounted nor /proc to be mounted. > I don't have other ideas than this. I also think that having an easy to > use way to access the interface outweighs the risks. I think proper documentation might help. Add a warning that this doesn't work across net name spaces and ensure that the API is flexible enough to allow a new field to be added in the future without breaking backwards compatibility if we ever need to start communicating also a netns identifier. Jiri ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
On Mon, 16 Sep 2019 09:56:29 +, Petr Machata wrote: > Inside the namespace you can do "ip netns id" to get the namespace that > you are in. Beware that this netnsid is only valid in the net name space that the 'ip' command ran in. It is not a global identifier and it is not valid in another net name space. In other words, ptp4l can't return a netnsid valid in the pmc net name space (without doing gross and unreliable hacks). > > Hmm. It's plausible the pmc instance wouldn't even know about the > > device, but ptp4l itself doesn't know whether to hide that info or > > not. Other way around could be that ptp4l is inside a namespace while > > pmc is not, but again it's not obvious. Every process is in exactly one net name space. There are no processes that are not in a net name space. There is a root net name space that is a bit special in some situations but it basically boils down to that it cannot be deleted. From a point of view of a process, there's nothing different about it. A net name space is a net name space. > ptp4l already has a public API to obtain the device name: the VLA > itself. There just isn't an easy way to invoke that interface. So we > don't have to concern ourselves with whether to hide the interface name > itself, that ship has sailed. If the API is so hard that it's not in use in practice, it makes a difference. > About the namespace--as an unprivileged process you can't just ask about > netns ids of random processes. So whether to allow ptp4l to give up this > information is a good question, because that might go against the > intentions of the admin of the machine. It also does not work, see above :-) > Maybe just documenting the issue is all that can be done. Could be. > I'm not sure I agree the process inside the namespace should be > disallowed from knowing it is. I'm not really well versed in network > namespaces, but looking at what "ip netns id" is doing under the hood it > looks like the kernel has interfaces to just tell you (RTM_GETNSID). Since every process is in a net name space (and exactly one net name space), it already knows by definition that it is in a name space :-) Whether referencing into other net name spaces makes sense or not, depends on the use. I'd argue that a daemon (such as ptp4l) should not mess with name spaces, as it needs the administrator to be able to run it in whatever net name space they chooses. But it can certainly query it if it is needed for proper interoperability. Jiri ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
Keller, Jacob E writes: >> From: Petr Machata [mailto:pe...@mellanox.com] >> Sent: Friday, September 13, 2019 7:58 AM >> To: Jiri Benc >> Cc: linuxptp-devel@lists.sourceforge.net >> Subject: Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying >> TLV_PORT_PROPERTIES_NP >> >> Jiri Benc writes: >> >> > pmc is different. It's not tied to the service start time, it's used by >> > administrators and by various scripts from varying environment. While >> > you can reasonably expect that ptp4l and phc2sys will be run in the >> > same name space, it's not necessarily the case for pmc. >> >> Hmm, and as an end user I can't do `ip netns identify $(pidof ptp4l)` >> even if I know about this issue. >> >> Maybe ptp4l could include the namespace name in the VLA response. Are >> the messages considered a stable API? >> > > Is the namespacing information supposed to be kept secure from > processes inside the namespacing? I would want to prevent any sort of > leak of namespace info in that case. ptp4l won't be able to tell the > request came from within a namespace either. Inside the namespace you can do "ip netns id" to get the namespace that you are in. > Hmm. It's plausible the pmc instance wouldn't even know about the > device, but ptp4l itself doesn't know whether to hide that info or > not. Other way around could be that ptp4l is inside a namespace while > pmc is not, but again it's not obvious. ptp4l already has a public API to obtain the device name: the VLA itself. There just isn't an easy way to invoke that interface. So we don't have to concern ourselves with whether to hide the interface name itself, that ship has sailed. About the namespace--as an unprivileged process you can't just ask about netns ids of random processes. So whether to allow ptp4l to give up this information is a good question, because that might go against the intentions of the admin of the machine. Maybe just documenting the issue is all that can be done. > I'm not sure what the best practice here is. Yeah, I didn't even think about this until Jiri brought it up. >> Alternatively I might mention the issue in the man page. >> >> Not being able to tell which of the PTP port identifiers represents >> which actual interface is something of a problem if you have more than >> about two of them. > > Right, but part of namespacing is that processes inside the namespace > should generally not know they are, and not be aware of anything > outside the namespace... I'm not sure I agree the process inside the namespace should be disallowed from knowing it is. I'm not really well versed in network namespaces, but looking at what "ip netns id" is doing under the hood it looks like the kernel has interfaces to just tell you (RTM_GETNSID). Thanks, Petr ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
> -Original Message- > From: Petr Machata [mailto:pe...@mellanox.com] > Sent: Friday, September 13, 2019 7:58 AM > To: Jiri Benc > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying > TLV_PORT_PROPERTIES_NP > > > Jiri Benc writes: > > > pmc is different. It's not tied to the service start time, it's used by > > administrators and by various scripts from varying environment. While > > you can reasonably expect that ptp4l and phc2sys will be run in the > > same name space, it's not necessarily the case for pmc. > > Hmm, and as an end user I can't do `ip netns identify $(pidof ptp4l)` > even if I know about this issue. > > Maybe ptp4l could include the namespace name in the VLA response. Are > the messages considered a stable API? > Is the namespacing information supposed to be kept secure from processes inside the namespacing? I would want to prevent any sort of leak of namespace info in that case. ptp4l won't be able to tell the request came from within a namespace either. Hmm. It's plausible the pmc instance wouldn't even know about the device, but ptp4l itself doesn't know whether to hide that info or not. Other way around could be that ptp4l is inside a namespace while pmc is not, but again it's not obvious. I'm not sure what the best practice here is. > Alternatively I might mention the issue in the man page. > > Not being able to tell which of the PTP port identifiers represents > which actual interface is something of a problem if you have more than > about two of them. Right, but part of namespacing is that processes inside the namespace should generally not know they are, and not be aware of anything outside the namespace... Hmm. > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
Jiri Benc writes: > pmc is different. It's not tied to the service start time, it's used by > administrators and by various scripts from varying environment. While > you can reasonably expect that ptp4l and phc2sys will be run in the > same name space, it's not necessarily the case for pmc. Hmm, and as an end user I can't do `ip netns identify $(pidof ptp4l)` even if I know about this issue. Maybe ptp4l could include the namespace name in the VLA response. Are the messages considered a stable API? Alternatively I might mention the issue in the man page. Not being able to tell which of the PTP port identifiers represents which actual interface is something of a problem if you have more than about two of them. ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
On Fri, 13 Sep 2019 09:32:37 +, Petr Machata wrote: > I would guess the same problem applies when phc2sys uses the interface. > Why is it not an issue there? It is an issue, too, of course, but it's mostly theoretical. It won't happen in practice - usually, phc2sys will be started together with ptp4l from the same environment. pmc is different. It's not tied to the service start time, it's used by administrators and by various scripts from varying environment. While you can reasonably expect that ptp4l and phc2sys will be run in the same name space, it's not necessarily the case for pmc. Jiri ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
Jiri Benc writes: > On Thu, 12 Sep 2019 11:06:30 +, Petr Machata wrote: >> +text2str(>interface)); > > How does this work when net name spaces are in use? There's no guarantee > that pmc is run in the same net name space where ptp4l is running. The > returned interface name may correspond to a completely different > interface in the pmc net name space. I would guess the same problem applies when phc2sys uses the interface. Why is it not an issue there? ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
On Thu, 12 Sep 2019 11:06:30 +, Petr Machata wrote: > + text2str(>interface)); How does this work when net name spaces are in use? There's no guarantee that pmc is run in the same net name space where ptp4l is running. The returned interface name may correspond to a completely different interface in the pmc net name space. Jiri ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH 2/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
TLV_PORT_PROPERTIES_NP messages serve for querying of port properties, such
as timestamp type and, prominently, netdevice name associated with the
port. pmc however does not support this query, which makes it difficult to
access this information e.g. from scripts. Add this support to pmc.
Signed-off-by: Mykola Zhuravel
Signed-off-by: Petr Machata
---
pmc.8| 2 ++
pmc.c| 16
pmc_common.c | 1 +
3 files changed, 19 insertions(+)
diff --git a/pmc.8 b/pmc.8
index acf2d90..e0ab5ac 100644
--- a/pmc.8
+++ b/pmc.8
@@ -193,6 +193,8 @@ The MAC address to which PTP management messages should be
sent. Relevant only w
.TP
.B PORT_DATA_SET_NP
.TP
+.B PORT_PROPERTIES_NP
+.TP
.B PORT_STATS_NP
.TP
.B PRIORITY1
diff --git a/pmc.c b/pmc.c
index 868fc2a..4e6043b 100644
--- a/pmc.c
+++ b/pmc.c
@@ -69,6 +69,7 @@ static void pmc_show(struct ptp_message *msg, FILE *fp)
struct tlv_extra *extra;
struct portDS *p;
struct port_ds_np *pnp;
+ struct port_properties_np *ppn;
struct port_stats_np *pcp;
if (msg_type(msg) != MANAGEMENT) {
@@ -323,6 +324,21 @@ static void pmc_show(struct ptp_message *msg, FILE *fp)
pnp->neighborPropDelayThresh,
pnp->asCapable ? 1 : 0);
break;
+ case TLV_PORT_PROPERTIES_NP:
+ ppn = (struct port_properties_np *) mgt->data;
+ if (ppn->port_state > PS_SLAVE) {
+ ppn->port_state = 0;
+ }
+ fprintf(fp, "PORT_PROPERTIES_NP "
+ IFMT "portIdentity%s"
+ IFMT "portState %s"
+ IFMT "timestamping%s"
+ IFMT "interface %s",
+ pid2str(>portIdentity),
+ ps_str[ppn->port_state],
+ ts_str(ppn->timestamping),
+ text2str(>interface));
+ break;
case TLV_PORT_STATS_NP:
pcp = (struct port_stats_np *) mgt->data;
fprintf(fp, "PORT_STATS_NP "
diff --git a/pmc_common.c b/pmc_common.c
index 592cc93..46aac30 100644
--- a/pmc_common.c
+++ b/pmc_common.c
@@ -121,6 +121,7 @@ struct management_id idtab[] = {
{ "LOG_MIN_PDELAY_REQ_INTERVAL", TLV_LOG_MIN_PDELAY_REQ_INTERVAL,
do_get_action },
{ "PORT_DATA_SET_NP", TLV_PORT_DATA_SET_NP, do_set_action },
{ "PORT_STATS_NP", TLV_PORT_STATS_NP, do_get_action },
+ { "PORT_PROPERTIES_NP", TLV_PORT_PROPERTIES_NP, do_get_action },
};
static void do_get_action(struct pmc *pmc, int action, int index, char *str)
--
2.20.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
