Menu
▾
▴
tipc-discussion
|
From: Yin, H. <hu...@in...> - 2004-06-03 09:49:26
|
Jon, During the test of TIPC, I found some functions of manager.c don't work, for example, TIPC_CREATE_LINK doesn't create a new link, TIPC_SET_LINK_TOLERANCE doesn't reset the link's parameters, and etc. In addition, when I try to send TIPC_BLOCK_LINK event to manager, my machine hang and cannot response any keyboard and mouse event, so I have to reboot my machine, hehe:-) So far I just found these problems! Have a nice day! Best Regards, Nick Yin |
|
From: Yin, H. <hu...@in...> - 2004-06-04 01:27:53
|
Jon, Understand. Thank you! Best Regards, Nick Yin -----Original Message----- From: Jon Maloy [mailto:jon...@er...]=20 Sent: Thursday, June 03, 2004 8:59 PM To: Yin, Hu Cc: tip...@li... Subject: Re: [Tipc-discussion] RE: TIPCv2 test spec! Good. When/if you find the problem just send me the patch(es). In a couple of days I will check in a version where we rely entirely on the management interface (=3Dno more insmod parameters), so this must work. /Jon Yin, Hu wrote: >Jon, > >During the test of TIPC, I found some functions of manager.c don't work, >for example, TIPC_CREATE_LINK doesn't create a new link, >TIPC_SET_LINK_TOLERANCE doesn't reset the link's parameters, and etc. > >In addition, when I try to send TIPC_BLOCK_LINK event to manager, my >machine hang and cannot response any keyboard and mouse event, so I have >to reboot my machine, hehe:-) > >So far I just found these problems! > >Have a nice day! > >Best Regards, > >Nick Yin > =20 > |
|
From: <hek...@ya...> - 2004-06-04 02:19:40
|
Hello, In one experiemnt, the server listens to name instance: 0x10001a21 and the client sends to name sequence: 0x10000000 - 0x13ffffff. It seems it takes forever for the client's sendto() to return. Is this expected behavior ? Thanks! Kevin |
|
From: Jon M. <jon...@er...> - 2004-06-04 12:49:20
|
No, it should not be like that. I hope Ling will look into it ? /jon hek...@ya... wrote: >Hello, > >In one experiemnt, the server listens to name instance: 0x10001a21 >and the client sends to name sequence: 0x10000000 - 0x13ffffff. > >It seems it takes forever for the client's sendto() to return. >Is this expected behavior ? > >Thanks! > >Kevin > > |
|
From: Yin, H. <hu...@in...> - 2004-06-07 07:29:32
|
Jon,
=20
Thanks for your reply. I'm here waiting for your latest TIPC version,
hehe : - )
=20
Have a nice day!
=20
Nick
-----Original Message-----
From: Jon Maloy [mailto:jon...@er...]=20
Sent: Saturday, June 05, 2004 2:38 AM
To: Mark Haverkamp
Cc: Yin, Hu; tipc
Subject: Re: [Tipc-discussion] RE: TIPCv2 test spec!
=20
No, you must have a "management connection" to the node
to be able to do this kind of changes. The idea is that a user land
process on one of the nodes ("zone master") takes command from=20
the beginning and establishes one such connection to all the other=20
nodes, and then holds on this connection as long as it is running.
Each TIPC module only allows one such connection, and will
reject all other setup requests, so as long as we make sure that
the zone master is started on a trusted processor and holds on to
its connection we should be safe.
As an extra precaution I have in the version I am working on now
made this whole remote configurability configurable, so that if shut=20
off TIPC only accepts commands from the local node. This is one of=20
the commands, (along with change of node address and a few more)=20
that go via ioctl() instead of via the management port.=20
What I am working on now is such a client CLM process, but I have had to
concentrate on the basic stuff, such as setting node address and
enabling/
disabling bearers on the local node, so there is no zone master yet.
This=20
will have to wait until later; I will check in what I have as soon as I
have=20
merged with the latest changes and tested with running traffic.
/Jon
Mark Haverkamp wrote:
On Thu, 2004-06-03 at 05:59, Jon Maloy wrote:
=20
Good.
When/if you find the problem just send me the patch(es).
In a couple of days I will check in a version where we
rely entirely on the management interface (=3Dno more
insmod parameters), so this must work.
=20
/Jon
=20
=20
=20
I don't see any protection against anyone doing link configuration
commands via the management interface. Could just anyone reconfigure
links, disable bearers, etc.?
=20
=20
=20
=20
|
|
From: Jon M. <jon...@er...> - 2004-06-03 12:59:47
|
Good. When/if you find the problem just send me the patch(es). In a couple of days I will check in a version where we rely entirely on the management interface (=no more insmod parameters), so this must work. /Jon Yin, Hu wrote: >Jon, > >During the test of TIPC, I found some functions of manager.c don't work, >for example, TIPC_CREATE_LINK doesn't create a new link, >TIPC_SET_LINK_TOLERANCE doesn't reset the link's parameters, and etc. > >In addition, when I try to send TIPC_BLOCK_LINK event to manager, my >machine hang and cannot response any keyboard and mouse event, so I have >to reboot my machine, hehe:-) > >So far I just found these problems! > >Have a nice day! > >Best Regards, > >Nick Yin > > |
|
From: Mark H. <ma...@os...> - 2004-06-04 17:19:57
|
On Thu, 2004-06-03 at 05:59, Jon Maloy wrote: > Good. > When/if you find the problem just send me the patch(es). > In a couple of days I will check in a version where we > rely entirely on the management interface (=no more > insmod parameters), so this must work. > > /Jon > I don't see any protection against anyone doing link configuration commands via the management interface. Could just anyone reconfigure links, disable bearers, etc.? -- Mark Haverkamp <ma...@os...> |
|
From: Jon M. <jon...@er...> - 2004-06-04 18:38:45
|
No, you must have a "management connection" to the node
to be able to do this kind of changes. The idea is that a user land
process on one of the nodes ("zone master") takes command from
the beginning and establishes one such connection to all the other
nodes, and then holds on this connection as long as it is running.
Each TIPC module only allows one such connection, and will
reject all other setup requests, so as long as we make sure that
the zone master is started on a trusted processor and holds on to
its connection we should be safe.
As an extra precaution I have in the version I am working on now
made this whole remote configurability configurable, so that if shut
off TIPC only accepts commands from the local node. This is one of
the commands, (along with change of node address and a few more)
that go via ioctl() instead of via the management port.
What I am working on now is such a client CLM process, but I have had to
concentrate on the basic stuff, such as setting node address and
enabling/
disabling bearers on the local node, so there is no zone master yet.
This
will have to wait until later; I will check in what I have as soon as I
have
merged with the latest changes and tested with running traffic.
/Jon
Mark Haverkamp wrote:
On Thu, 2004-06-03 at 05:59, Jon Maloy wrote:
Good.
When/if you find the problem just send me the patch(es).
In a couple of days I will check in a version where we
rely entirely on the management interface (=no more
insmod parameters), so this must work.
/Jon
I don't see any protection against anyone doing link configuration
commands via the management interface. Could just anyone reconfigure
links, disable bearers, etc.?
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X