Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - problems with Qet over IP (QNX632): (16 Items)
   
problems with Qet over IP (QNX632)  
I have problems in using qnet over IP in QNX632
When I start it with command
"mount -Tio-net -o bind=ip npm-qnet.so"
I just get empty directory "/net" without any hosts in it.
When I start MQC after that command .. it just terminates by memory fault ..

In case when I start qnet with command
"mount -Tio-net -o bind=ip npm-qnet-compat.so"
I get "/net" directory with hosts (where I started qnet in the same way). It seems for some time that everything is OK .
.. but .. when start some command on remote host, for example "on -f remote hogs" it sometimes work for 3 times .. 
somitemes it works forever .. but sometimes it doesn't work at all

I've tried the same commands ("on -f remote hogs") with Qnet over Ethernet (by starting it with command "mount -Tio-net 
npm-qnet-compat.so"). But in this case - everything works fine.
I've got the same problems with QNX630
Have any tested Qnet over IP with QNX632? 
Re: problems with Qet over IP (QNX632)  
> I have problems in using qnet over IP in QNX632
> When I start it with command
> "mount -Tio-net -o bind=ip npm-qnet.so"
> I just get empty directory "/net" without any hosts in it.
> When I start MQC after that command .. it just terminates by memory fault ..
> 
> In case when I start qnet with command
> "mount -Tio-net -o bind=ip npm-qnet-compat.so"
> I get "/net" directory with hosts (where I started qnet in the same way). It 
> seems for some time that everything is OK ... but .. when start some command 
> on remote host, for example "on -f remote hogs" it sometimes work for 3 times 
> .. somitemes it works forever .. but sometimes it doesn't work at all
> 
> I've tried the same commands ("on -f remote hogs") with Qnet over Ethernet (by
>  starting it with command "mount -Tio-net npm-qnet-compat.so"). But in this 
> case - everything works fine.
> I've got the same problems with QNX630
> Have any tested Qnet over IP with QNX632? 

When you bind=ip, you really want to switch to DNS resolver.
Try this:

mount -Tio-net -o bind=ip,resolve=dns npm-qnet.so
Re: problems with Qet over IP (QNX632)  
I've tried that - the same result - empty "/net" and mqc doesn't start..
Have you tried it with Qnx632?
I've tried also to slay io-net an start it with
"io-net -dpcnet -ptcpip -pqnet bind=ip,host=qiptest"
In this case I got an empty "/net" too ... but mqc starts fine ...

I've tried also "io-net -dpcnet -ptcpip -pqnet-compat bind=ip,host=qiptest"
In this case "/net" was populated with "qiptest"

So, what's wrong with npm-qnet.so (with bind=ip) ?
Re: problems with Qet over IP (QNX632)  
So, QNet_over_IP is so useless that nobody wants even to test it?
Have anybode tryed to use QNet over IP with QNX632?
Re: problems with Qet over IP (QNX632)  
Did you tried this?

   mount -Tio-net -o bind=ip,resolve=dns npm-qnet.so

And what happened?
Re: problems with Qet over IP (QNX632)  
As i said in my previos post, I've tried it
Result:
1) empty /net directory
2) "ls /dev/io-net" output is "en0 ip0 ip_en qnet_ip"
3) mqc (mc clone) doesn't start.Terminates by memory fault
4) "ping" by name to hosts defined in /etc/hosts works fine

In case when I use npm-qnet-compat.so, qnet works fine .. for some time .. but it's work is unpredictable sometimes
npm-qnet-compat.so works with resolve=dns, resolve=file and with default native resolver

And have you tried it? What happened? 
RE: problems with Qet over IP (QNX632)  
 

> -----Original Message-----
> From: Alexey Chaichuk [mailto:reclchai@mail.ru] 
> Sent: October 18, 2007 8:03 AM
> To: ostech-core_os
> Subject: Re: problems with Qet over IP (QNX632)
> 
> So, QNet_over_IP is so useless that nobody wants even to test it?
> Have anybode tryed to use QNet over IP with QNX632?

Fighting words =;-)  Trying to get some action via re-action?

I assure you I use qnet over IP on 6.3.2, with the same 
function that xtang indicated and it works for me.  Sounds
like a deeper diagnosis is what you need instead of name
calling.

Thomas
Re: RE: problems with Qet over IP (QNX632)  
Hi Alexey,

QNX Standard Support has tried email you several times regarding this issue, but the email kept bouncing. Regardless, 
here is what the rep was trying to send you:

Here's how he was able to get qnet to work over IP. Please note, you'll have better luck with either npm-qnet-compat.so 
or npm-qnet-l4_lite.so

Here are the steps used to get two installs of qnx6.3.2 in VMware:

Assuming pc1 = 192.168.0.1 pc2 = 192.168.0.2 1. Setup hosts file, in
/etc/hosts: 
192.168.0.1 pc1.qnx.com pc1
192.168.0.2 pc2.qnx.com pc2

2. start the driver: 
io-net -dpcnet -ptcpip stacksize=16384 -pqnet-l4_lite bind=ip,resolve=dns

3. Establish contact with peer. The qnet nodes don't show up automatically, you must contact them first: 

from pc1: 
ls /net/pc2
(short wait while resolver does its work, then contents will be available). 

Cheers,
-Brian
Re: RE: problems with Qet over IP (QNX632)  
I'm sorry for my <Fighting words>, but I simply don't know English so well :) I received last letter from qnx support on
 9.10.07, so I thought that you forget about my question :)
But now i received letter from Brian. I just wonder why letter from Joel bounced ..

I can't understand phrases "Please note, you'll have better luck with either npm-qnet-compat.so or npm-qnet-l4_lite.so"
and "it seems npm-qnet.so is on it's way to being deprecated and your probably better off using npm-qnet-compat.so or 
qnet-l4_lite"
As I see in system (/lib/dll), npm-qnet.so is just a simbolic link to npm-qnet-l4_lite.so.

In this hour I've done next steps:
1) made two default installation of QNX632 on VMWare v5.5 each from distributive with name 6.3.2-nto632-200709070203-x86
.iso
2) in network config for first node: 
	address 192.168.0.1
	mask	255.255.255.0
	hostname pc1
	domain	localdomain
3) in /etc/hosts on first node added lines:
	192.168.0.1	pc1.localdomain pc1
	192.168.0.2	pc2.localdomain pc2
4) in network config for second node: 
	address 192.168.0.2
	mask	255.255.255.0
	hostname pc2
	domain	localdomain
5) in /etc/hosts on first node added lines:
	192.168.0.1	pc1.localdomain pc1
	192.168.0.2	pc2.localdomain pc2

6) on first node:
	#slay io-net
	#io-net -dpcnet -ptcpip stacksize=16384 -pqnet-l4_lite bind=ip,resolve=dns
	#netmanager
7) on second node:
	#slay io-net
	#io-net -dpcnet -ptcpip stacksize=16384 -pqnet-l4_lite bind=ip,resolve=dns
	#netmanager

Results:
1) "ls /net/pc1" and "ls /net/pc2" works fine
2) "ping pc1" and "ping pc2" works fine
3) when I tried to start io-net with 
	#io-net -dpcnet -ptcpip -pqnet-l4_lite bind=ip,resolve=dns
I've got the same that I got before, i.e. memory faults and empty /net

So, the main option, imho, is "stacksize=16384" for tcpip
Without this option npm-qnet fails
I've never tried this option before :)
As I found out from help system its default value is 4096 - it's too small for qnet?

Thank you very much!!! :) I'll keep testing this systems with qnet

P.S.
I can't understand one more thing :) Why i got 4 letters in this hour about  "Returned mail: Service unavailable", "
Returned mail: User unknown", "Warning: could not send message for past 4 hours" from address Mailer-Daemon@qnx.com 
concerning community.ott.qnx.com? I sent all my messages from webform .. If community.ott.qnx.com can't send it, why I 
receive this replies? :)
Re: RE: problems with Qet over IP (QNX632)  
> I'm sorry for my <Fighting words>, but I simply don't know English so well :) I received last 
> letter from qnx support on 9.10.07, so I thought that you forget about my 
> question :)
> But now i received letter from Brian. I just wonder why letter from Joel 
> bounced ..
> 
> I can't understand phrases "Please note, you'll have better luck with either 
> npm-qnet-compat.so or npm-qnet-l4_lite.so"
> and "it seems npm-qnet.so is on it's way to being deprecated and your probably
>  better off using npm-qnet-compat.so or qnet-l4_lite"

Sorry for being unclear. What we mean to say is that you should either npm-qnet-compat.so or npm-qnet-l4_lite.so 
directly, instead of the npm-qnet.so.

Yes, it is a symbolic link, but speaking from personal experience, I prefer use the exact name of the dll I'm loading, 
so there is no mistake later.

> Results:
> 1) "ls /net/pc1" and "ls /net/pc2" works fine
> 2) "ping pc1" and "ping pc2" works fine
> 3) when I tried to start io-net with 
> 	#io-net -dpcnet -ptcpip -pqnet-l4_lite bind=ip,resolve=dns
> I've got the same that I got before, i.e. memory faults and empty /net
> 
> So, the main option, imho, is "stacksize=16384" for tcpip
> Without this option npm-qnet fails
> I've never tried this option before :)
> As I found out from help system its default value is 4096 - it's too small for
>  qnet?

Honestly, I'm not sure why this is the case. I will, however, enter a documentation problem report so that it's more 
clear to people who try this in the future.

> Thank you very much!!! :) I'll keep testing this systems with qnet

That's great to hear!


> P.S.
> I can't understand one more thing :) Why i got 4 letters in this hour about  "
> Returned mail: Service unavailable", "Returned mail: User unknown", "Warning: 
> could not send message for past 4 hours" from address Mailer-Daemon@qnx.com 
> concerning community.ott.qnx.com? I sent all my messages from webform .. If 
> community.ott.qnx.com can't send it, why I receive this replies? :)

I'm not sure why this is. I suspect that what happens is collabnet turns the forum posts into emails for people who are 
monitoring this forum. I know I get out of office responses when I respond to posts.

Regardless, I'll see if the community guys can shed some light on this.

Cheers,
-Brian
Re: RE: problems with Qet over IP (QNX632)  
one more test
---
#slay io-net
#io-net -dpcnet -ptcpip -pqnet-l4_lite bind=ip,resolve=dns
#netmanager
tcpip: blown stack handling 0x106. See "stacksize" option
---
Is "stacksize=16384" sufficient for qnet or maybe it's possible that in some conditions io-net will fail with the same 
error as above? 
Have you any exact formula for stacksize value? Maybe it's better to use other tcpip stack (ttcpip, tcpip-v4, tcpip-v6)?

Is it so critical to use exact names for libs (i.e. qnet-l4_lite and tcpip-v4) instead of slinks (i.e. qnet and tcpip)? 
Re: RE: problems with Qet over IP (QNX632)  
Hi!

I found strange issue with Qnet over IP and I think this thing must be shown in documentation or fixed in code.
If in your target FS not present libsocket.so (not libsocket.so.2 but without .2) than Qnet over IP mount npm-qnet_l4.so
 but Qnet doesn't work.

So I had libsocket.so.2 but no libsocket.so in my target FS and all application which uses tcp/ip sockets work fine 
except Qnet over IP. So Qnet need exactly libsocket.so (as for example symbolic link).

I found no any word about this issue in current documentation.

--
AG
RE: RE: problems with Qet over IP (QNX632)  
Hi Andrew:
	Could you post this question in the Networking forum?

http://community.qnx.com/sf/discussion/do/listTopics/projects.networking/dis
cussion.general

	Thanks!
		Robert.	

-----Original Message-----
From: Andrew Golovnia [mailto:andrew_golovnia@ukr.net] 
Sent: Friday, March 14, 2008 8:00 AM
To: ostech-core_os
Subject: Re: RE: problems with Qet over IP (QNX632)

Hi!

I found strange issue with Qnet over IP and I think this thing must be shown
in documentation or fixed in code.
If in your target FS not present libsocket.so (not libsocket.so.2 but
without .2) than Qnet over IP mount npm-qnet_l4.so but Qnet doesn't work.

So I had libsocket.so.2 but no libsocket.so in my target FS and all
application which uses tcp/ip sockets work fine except Qnet over IP. So Qnet
need exactly libsocket.so (as for example symbolic link).

I found no any word about this issue in current documentation.

--
AG

_______________________________________________
OSTech
http://community.qnx.com/sf/go/post5800
Re: RE: RE: problems with Qet over IP (QNX632)  
Wouldn't it be better to move the entire thread to the network forum? :)
Re: RE: RE: problems with Qet over IP (QNX632)  
At the time that this thread was created, the networking project didn't exist :-).  

     I hadn't actually realized that it was part of a longer thread since I usually answer through e-mail rather than 
the web interface...  
Re: RE: RE: problems with Qet over IP (QNX632)  
> At the time that this thread was created, the networking project didn't exist  :-).

Right. That's why this thread was born.
  
> 
>      I hadn't actually realized that it was part of a longer thread since I 
> usually answer through e-mail rather than the web interface...  
Ok, I posted MY initial message in networking forum:
http://community.qnx.com/sf/discussion/do/listPosts/projects.networking/discussion.general.topc2228