Hi Kumar,
First of all, I would recommend you not to use <1.88.88> as listener address,
since the service types [0,64] are reserved for internal use by TIPC itself.
I am also a little confused about which kernel you are using. Are you now using
4.19.44, and not 4.4.180, or was this just a test?
BTW, since 4.17, the use of “zone” scope is deprecated, and translated
internally to “cluster”. There was never any functional difference between them
anyway.
Regarding your system, a good start would be to issue the following commands,
both on the host and in the container:
$ ip addr
$ tipc bearer list
$ tipc link list
$ tipc nametable show
BR
///jon
From: Mahesh Kumar <lmk...@yahoo.com>
Sent: 15-Jul-19 16:21
To: Ying Xue <ying....@windriver.com>; Jon Maloy <jon.ma...@ericsson.com>
Cc: tipc-discussion@lists.sourceforge.net
Subject: Re: [tipc-discussion] TIPC ; config trouble ; help request
Hi Jon,
Thanks a lot for checking this and providing feedback.
A brief background of the system.
In the host system, upon bootup node address 1.1.1 would be configured.
I added is a listener in 1.88.88.
tams_srv_addr<https://wwwin-opengrok.cisco.com/v1611_throttle/xref/polaris/binos/infra/tam_svcs/server/platform/mcp/src/tams_tipc.c#tams_srv_addr>.family<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=family>
= AF_TIPC<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=AF_TIPC>;
tams_srv_addr<https://wwwin-opengrok.cisco.com/v1611_throttle/xref/polaris/binos/infra/tam_svcs/server/platform/mcp/src/tams_tipc.c#tams_srv_addr>.addrtype<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=addrtype>
=
TIPC_ADDR_NAMESEQ<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=TIPC_ADDR_NAMESEQ>;
tams_srv_addr<https://wwwin-opengrok.cisco.com/v1611_throttle/xref/polaris/binos/infra/tam_svcs/server/platform/mcp/src/tams_tipc.c#tams_srv_addr>.addr<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=addr>.nameseq<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=nameseq>.type<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=type>
=
TIPC_TOP_SRV<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=TIPC_TOP_SRV>;
tams_srv_addr<https://wwwin-opengrok.cisco.com/v1611_throttle/xref/polaris/binos/infra/tam_svcs/server/platform/mcp/src/tams_tipc.c#tams_srv_addr>.addr<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=addr>.nameseq<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=nameseq>.lower<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=lower>
=
TAMS_TIPC_LISTEN_PORT<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=TAMS_TIPC_LISTEN_PORT>;
<<88
tams_srv_addr<https://wwwin-opengrok.cisco.com/v1611_throttle/xref/polaris/binos/infra/tam_svcs/server/platform/mcp/src/tams_tipc.c#tams_srv_addr>.addr<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=addr>.nameseq<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=nameseq>.upper<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=upper>
=
TAMS_TIPC_LISTEN_PORT<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=TAMS_TIPC_LISTEN_PORT>;
tams_srv_addr<https://wwwin-opengrok.cisco.com/v1611_throttle/xref/polaris/binos/infra/tam_svcs/server/platform/mcp/src/tams_tipc.c#tams_srv_addr>.scope<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=scope>
=
TIPC_ZONE_SCOPE<https://wwwin-opengrok.cisco.com/v1611_throttle/s?defs=TIPC_ZONE_SCOPE>;
Now from a container, I am trying to access the host service (88);
by setting its container's node address as 1.1.100 using "tipc node set addr
1.1.100".
This used to work fine, but it bails out with 4.4.180 kernel.
Another change I noticed by changing my kernel to 4.19.44 is that all of the
listeners are in cluster scope now instead of zone scope.
I didn't had a chance to check the results from container with the new kernel.
>>from host >>>tipc-config -nt
Type Lower Upper Port Identity Publication Scope
0 16781313 16781313 <1.1.1:0> 16781313 cluster
1 1 1 <1.1.1:2399481494> 2399481495 node
1 88 88 <1.1.1:2536304640> 2536304641 cluster
15003 5 5 <1.1.1:3973838764> 3973838765 cluster
[Switch_1_RP_0:/]$ uname -a
Linux Switch_1_RP_0 4.19.44 #1 SMP Wed May 22 13:50:02 PDT 2019 x86_64 x86_64
x86_64 GNU/Linux
Please let me know; which outputs should I need to share from the 'host' and
'container' side.
thanks & regards
Mahesh kumar.L
On Monday, 15 July, 2019, 12:36:09 pm GMT-7, Jon Maloy
<jon.ma...@ericsson.com<mailto:jon.ma...@ericsson.com>> wrote:
Hi Kumar,
Your binding table listing reveals that your node already has an address
<1.1.1>, which explains why your address setting fails.
You should check if you have any script that sets the address by default at
module loading, or maybe you just set it manually and then forgot...
Furthermore, its seems you have published a service <1,88,88> which means you
are illegally using the reserved service type <1>.
The latter isn't your fault, but due to a bug in TIPC that wrongly allows users
to publish such service types, in the function tipc_bind().
I discovered this ug a couple of months ago, but haven't fixed it yet, and I am
not quite sure how to do it without breaking any BPI.
This may cause you surprises, but I cannot see why it would cause the bearer
enabling to fail.
If this problem persists, you should post some more system info about your
interfaces, which tipc links you have etc.
BR
///jon
> -----Original Message-----
> From: Mahesh Kumar via tipc-discussion <tipc-
> discuss...@lists.sourceforge.net<mailto:discuss...@lists.sourceforge.net>>
> Sent: 15-Jul-19 11:49
> To:
> tipc-discussion@lists.sourceforge.net<mailto:tipc-discussion@lists.sourceforge.net>;
> Ying Xue
> <ying....@windriver.com<mailto:ying....@windriver.com>>
> Subject: Re: [tipc-discussion] TIPC ; config trouble ; help request
>
> Hi Ying,
> Thank you very much for letting me know.Do we suspect any related ioctl()
> patches?. could you please point me to link where we can review the TIPC
> patches that went in the kernel.?.
> Much appreciate the help.
> thanks & regardsMahesh kumar.L
> On Monday, 15 July, 2019, 02:56:32 am GMT-7, Ying Xue
> <ying....@windriver.com<mailto:ying....@windriver.com>> wrote:
>
> On 7/13/19 11:58 AM, Mahesh Kumar via tipc-discussion wrote:
> > Tipc Team,
> >
> > Greetings!.
> > I have been using TIPC for about a year without any issueHowever the
> > TIPC tool is bailing out when I tried to set address, bearer
> >
> >
> > / # tipc node set addr 1.1.100
> >
> > error: Operation not permitted
> >
> > / # tipc bearer enable media eth dev ieobc
> >
> > error: Invalid argument
> >
> > / #
> >
> > I am using the new kernel now;
> > uname -aLinux 2c3f0b001900_1_RP_0 4.4.180 #1 SMP Tue Jun 25
> 15:36:10
> > PDT 2019 x86_64 x86_64 x86_64 GNU/Linux
> > dmesg output ; grep -i TIPC d.txt[ 29.436599] tipc: Activated
> > (version 2.0.0)[ 29.436768] tipc: Started in single node mode
>
> Suspected some TIPC patches integrated through 4.4.180 release introduced
> regression. The most simplest method to identify the issue is to revert some
> TIPC patches to identify which ones caused the regression.
>
> >
> > [2c3f0b001900_1_RP_0:/]
$ tipc-config -nt
Type Lower Upper Port Identity Publication
Scope
0 16781313 16781313 <1.1.1:0> 16781313
zone
1 1 1 <1.1.1:483390874> 483390875
node
1 88 88 <1.1.1:2870943326> 2870943327
zone
15003 5 5 <1.1.1:3556781096> 3556781097 zone
[2c3f0b001900_1_RP_0:/]$
> >
> > please let me know if any issue.
> > thanks & regardsMahesh kumar.L
> >
> >
> > _______________________________________________
> > tipc-discussion mailing list
> > tipc-discussion@lists.sourceforge.net<mailto:tipc-discussion@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/tipc-discussion
> >
>
> _______________________________________________
> tipc-discussion mailing list
> tipc-discussion@lists.sourceforge.net<mailto:tipc-discussion@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/tipc-discussion
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
