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.family = AF_TIPC;

    tams_srv_addr.addrtype = TIPC_ADDR_NAMESEQ;

    tams_srv_addr.addr.nameseq.type  = TIPC_TOP_SRV;

    tams_srv_addr.addr.nameseq.lower = TAMS_TIPC_LISTEN_PORT; <<88

     tams_srv_addr.addr.nameseq.upper = TAMS_TIPC_LISTEN_PORT;

     tams_srv_addr.scope = 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 -ntType       Lower      Upper      Port 
Identity              Publication Scope0          16781313   16781313   
<1.1.1:0>                  16781313    cluster1          1          1          
<1.1.1:2399481494>         2399481495  node1          88         88         
<1.1.1:2536304640>         2536304641  cluster15003      5          5          
<1.1.1:3973838764>         3973838765  cluster[Switch_1_RP_0:/]$ uname -aLinux 
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 & regardsMahesh kumar.L







    On Monday, 15 July, 2019, 12:36:09 pm GMT-7, Jon Maloy 
<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>
> Sent: 15-Jul-19 11:49
> To: tipc-discussion@lists.sourceforge.net; Ying Xue
> <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> 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
> > 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
  
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Reply via email to