Qnet startup delay

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I seem to have a problem when I reboot a QRTP system and getting the
Qnet connections reset.

I have two QRTP systems on a switched subnet. Both running qnet. They
can see each other’s file system
just fine in /net.

Now if I reboot system2, that pc comes back up and can not see the other
system across qnet. I try

On system2
ls /net/system1
fails with
ls: No route to host (/net/system1)

On system1 the first time i try
ls /net/system2
it fails with
ls: Network dropped connection on reset (/net/system2)

Back on system2 i retry
ls /net/system1
still fails with
ls: No route to host (/net/system1)

Once more on system1
ls /net/system2
it works and I see the directories

Once more on system 2 and it now works also.

Any guess why qnet seems to need to be kicked before it works?

Both systems startup qnet in /etc/system/enum/net with the following
line.
set(IONET_CMD, io-net -pttcpip -pqnet crc=0 resolve=ndp)

I’ve also tried it with the full stack and see the same results.

This makes it hard to have home directories on a central server.

Rich Hemmenway

2

Rich Hemmenway <rhemmenw@ocdus.jnj.com> wrote:

I seem to have a problem when I reboot a QRTP system and getting the
Qnet connections reset.

I have two QRTP systems on a switched subnet. Both running qnet. They
can see each other’s file system
just fine in /net.

Now if I reboot system2, that pc comes back up and can not see the other
system across qnet. I try

On system2
ls /net/system1
fails with
ls: No route to host (/net/system1)

On system1 the first time i try
ls /net/system2
it fails with
ls: Network dropped connection on reset (/net/system2)

Back on system2 i retry
ls /net/system1
still fails with
ls: No route to host (/net/system1)

Once more on system1
ls /net/system2
it works and I see the directories

Once more on system 2 and it now works also.

Any guess why qnet seems to need to be kicked before it works?

Both systems startup qnet in /etc/system/enum/net with the following
line.
set(IONET_CMD, io-net -pttcpip -pqnet crc=0 resolve=ndp)

I hope this is a “typo”, it should be “crc=0,resolve=ndp”, you can’t seperate
them by space.

I’ve also tried it with the full stack and see the same results.

This makes it hard to have home directories on a central server.

I suggest “not to” load QNET in io-net command, but load it in rc.local
file.

mount -Tio-net -o"crc=0,resolve=ndp" npm-qnet.so

There are several reason. At the time the io-net is running, hostname
might still be “localhost”. (It usually get set by netmanager)

Also, QNET attend to broadcast while it come up, but some network driver
startup slowly, which will throw away those packets.

Another way you could try is give the option “broadcast=3” to QNET,
forcing QNET broadcasting periodly (just like annoying Microsoft :slight_smile:

-xtang

3

Xiaodan Tang <xtang@qnx.com> wrote:

: I suggest “not to” load QNET in io-net command, but load it in rc.local
: file.

: mount -Tio-net -o"crc=0,resolve=ndp" npm-qnet.so

mount -Tio-net -o"crc=0,resolve=ndp" /lib/dll/npm-qnet.so

-seanb

4

Why should you provide absolute path for so library?

We can use LD_LIBRARY_PATH — or ?



Sean Boudreau wrote:

Xiaodan Tang <> xtang@qnx.com> > wrote:

: I suggest “not to” load QNET in io-net command, but load it in rc.local
: file.

: mount -Tio-net -o"crc=0,resolve=ndp" npm-qnet.so

mount -Tio-net -o"crc=0,resolve=ndp" /lib/dll/npm-qnet.so

-seanb

5

Stefan Parvu <sparvu@cc.hut.fi> wrote:
: Why should you provide absolute path for so library?

: We can use LD_LIBRARY_PATH — or ?

Unfortunately, not yet. We’re aware of the problem.

-seanb

6

ok this is not so big problem.

In my email I meant mount should use LD_LIBRARY_PATH ofcourse …


Sean Boudreau wrote:

Stefan Parvu <> sparvu@cc.hut.fi> > wrote:
: Why should you provide absolute path for so library?

: We can use LD_LIBRARY_PATH — or ?

Unfortunately, not yet. We’re aware of the problem.

-seanb

7

Thanks,

Putting it in the rc.local file seems to have fixed the problem. The missing “,”
was just a typo.

One new question, the Qnet Tech Sheet online talks about the third method of Qnet
resolving names
with a file to search for the FQNN. Is that file something other then
/etc/hosts, and if so what’s
the file and format.

thanks

Rich Hemmenway

Xiaodan Tang wrote:

Rich Hemmenway <> rhemmenw@ocdus.jnj.com> > wrote:

I seem to have a problem when I reboot a QRTP system and getting the
Qnet connections reset.

I have two QRTP systems on a switched subnet. Both running qnet. They
can see each other’s file system
just fine in /net.

Now if I reboot system2, that pc comes back up and can not see the other
system across qnet. I try

On system2
ls /net/system1
fails with
ls: No route to host (/net/system1)

On system1 the first time i try
ls /net/system2
it fails with
ls: Network dropped connection on reset (/net/system2)

Back on system2 i retry
ls /net/system1
still fails with
ls: No route to host (/net/system1)

Once more on system1
ls /net/system2
it works and I see the directories

Once more on system 2 and it now works also.

Any guess why qnet seems to need to be kicked before it works?

Both systems startup qnet in /etc/system/enum/net with the following
line.
set(IONET_CMD, io-net -pttcpip -pqnet crc=0 resolve=ndp)

I hope this is a “typo”, it should be “crc=0,resolve=ndp”, you can’t seperate
them by space.

I’ve also tried it with the full stack and see the same results.

This makes it hard to have home directories on a central server.

I suggest “not to” load QNET in io-net command, but load it in rc.local
file.

mount -Tio-net -o"crc=0,resolve=ndp" npm-qnet.so

There are several reason. At the time the io-net is running, hostname
might still be “localhost”. (It usually get set by netmanager)

Also, QNET attend to broadcast while it come up, but some network driver
startup slowly, which will throw away those packets.

Another way you could try is give the option “broadcast=3” to QNET,
forcing QNET broadcasting periodly (just like annoying Microsoft > :slight_smile:

-xtang

8

Rich Hemmenway <rhemmenw@ocdus.jnj.com> wrote:

Thanks,

Putting it in the rc.local file seems to have fixed the problem. The missing “,”
was just a typo.

One new question, the Qnet Tech Sheet online talks about the third method of Qnet
resolving names
with a file to search for the FQNN. Is that file something other then
/etc/hosts, and if so what’s
the file and format.

Sorry, that one is not supported yet :frowning:

-xtang

thanks

Rich Hemmenway

Xiaodan Tang wrote:

Rich Hemmenway <> rhemmenw@ocdus.jnj.com> > wrote:

I seem to have a problem when I reboot a QRTP system and getting the
Qnet connections reset.

I have two QRTP systems on a switched subnet. Both running qnet. They
can see each other’s file system
just fine in /net.

Now if I reboot system2, that pc comes back up and can not see the other
system across qnet. I try

On system2
ls /net/system1
fails with
ls: No route to host (/net/system1)

On system1 the first time i try
ls /net/system2
it fails with
ls: Network dropped connection on reset (/net/system2)

Back on system2 i retry
ls /net/system1
still fails with
ls: No route to host (/net/system1)

Once more on system1
ls /net/system2
it works and I see the directories

Once more on system 2 and it now works also.

Any guess why qnet seems to need to be kicked before it works?

Both systems startup qnet in /etc/system/enum/net with the following
line.
set(IONET_CMD, io-net -pttcpip -pqnet crc=0 resolve=ndp)

I hope this is a “typo”, it should be “crc=0,resolve=ndp”, you can’t seperate
them by space.

I’ve also tried it with the full stack and see the same results.

This makes it hard to have home directories on a central server.

I suggest “not to” load QNET in io-net command, but load it in rc.local
file.

mount -Tio-net -o"crc=0,resolve=ndp" npm-qnet.so

There are several reason. At the time the io-net is running, hostname
might still be “localhost”. (It usually get set by netmanager)

Also, QNET attend to broadcast while it come up, but some network driver
startup slowly, which will throw away those packets.

Another way you could try is give the option “broadcast=3” to QNET,
forcing QNET broadcasting periodly (just like annoying Microsoft > :slight_smile:

-xtang