problems while moving from ttcp/ip to tcp/ip

QNX Newsgroups (Archives) qdn.public.ddk.network
1

Hi,

I’m building intermediate driver which is located below ip.
I have built, debug and made a working driver on the ttcp/ip.
believing that ttcp/ip is a subset of tcp/ip , I thought that to move my
driver to the tcp/ip will be straightforward.
But, as everything in life is not simple, it does not work on tcp/ip.

uname -a is:
QNX6.1.0 2001/06/25-15:31:48 x86pc x86

Scenario 1:

  • I’m killing the io-net process.
  • loading io-net with ttcp/ip
  • mouting my driver to io-net
  • pinging a machine.
  • monitoring the packets.

the ping succeeds and I can see in the monitor that packets are coming back
and forward to/from the QNX machine


Scenario 2:

  • I’m killing the io-net process.
  • loading io-net with tcp/ip
  • mouting my driver to io-net
  • pinging a machine.
  • monitoring the packets.

the ping does not succeeds and I can’t see in the monitor that packets are
coming back and forward to/from the QNX machine.
looking at my logs I can see that rx_down finished successfully it course,
and that’s it. nothing happens from this point.
Retries of other pings are not effecting anything, the network is not
working.

  1. any idea why is there a difference between the 2 stacks ?
  2. any idea where to look from the bug?

Thanks

Benzy Gabay
R&D
Everbee Wireless
mailto:bgabay@everbeewireless.com

2

Benzy Gabay <bgabay@everbee.com> wrote:

Hi,

I’m building intermediate driver which is located below ip.
I have built, debug and made a working driver on the ttcp/ip.
believing that ttcp/ip is a subset of tcp/ip , I thought that to move my
driver to the tcp/ip will be straightforward.
But, as everything in life is not simple, it does not work on tcp/ip.

uname -a is:
QNX6.1.0 2001/06/25-15:31:48 x86pc x86

Scenario 1:

  • I’m killing the io-net process.
  • loading io-net with ttcp/ip
  • mouting my driver to io-net
  • pinging a machine.
  • monitoring the packets.

the ping succeeds and I can see in the monitor that packets are coming back
and forward to/from the QNX machine



Scenario 2:

  • I’m killing the io-net process.
  • loading io-net with tcp/ip
  • mouting my driver to io-net

Since tcpip don’t accept “if=enX::>” option, you have
to do:

ifconfig enX

-xtang

  • pinging a machine.
  • monitoring the packets.

the ping does not succeeds and I can’t see in the monitor that packets are
coming back and forward to/from the QNX machine.
looking at my logs I can see that rx_down finished successfully it course,
and that’s it. nothing happens from this point.
Retries of other pings are not effecting anything, the network is not
working.

  1. any idea why is there a difference between the 2 stacks ?
  2. any idea where to look from the bug?

Thanks

Benzy Gabay
R&D
Everbee Wireless
mailto:> bgabay@everbeewireless.com

3

xtang,

sorry, I’ve forgot to mention it , I did it and the tcp/ip scenario.

–

Benzy Gabay
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:9pa9jd$4tj$1@nntp.qnx.com…

Benzy Gabay <> bgabay@everbee.com> > wrote:
Hi,

I’m building intermediate driver which is located below ip.
I have built, debug and made a working driver on the ttcp/ip.
believing that ttcp/ip is a subset of tcp/ip , I thought that to move my
driver to the tcp/ip will be straightforward.
But, as everything in life is not simple, it does not work on tcp/ip.

uname -a is:
QNX6.1.0 2001/06/25-15:31:48 x86pc x86

Scenario 1:

  • I’m killing the io-net process.
  • loading io-net with ttcp/ip
  • mouting my driver to io-net
  • pinging a machine.
  • monitoring the packets.

the ping succeeds and I can see in the monitor that packets are coming
back
and forward to/from the QNX machine


Scenario 2:

  • I’m killing the io-net process.
  • loading io-net with tcp/ip
  • mouting my driver to io-net

Since tcpip don’t accept “if=enX::>” option, you have
to do:

ifconfig enX <mask

-xtang

  • pinging a machine.
  • monitoring the packets.

the ping does not succeeds and I can’t see in the monitor that packets
are
coming back and forward to/from the QNX machine.
looking at my logs I can see that rx_down finished successfully it
course,
and that’s it. nothing happens from this point.
Retries of other pings are not effecting anything, the network is not
working.

  1. any idea why is there a difference between the 2 stacks ?
  2. any idea where to look from the bug?

Thanks

Benzy Gabay
R&D
Everbee Wireless
mailto:> bgabay@everbeewireless.com

4

Hi,

Regarding my problem,

After deeper investigation I’ve found that there is a difference in
npkt->num_complete in ttcp and tcp.
On down packet (after doing a simple ping, with no extra parameters, from
the qnx machine)
in tcp npkt->num_complete = 3
in ttcp npkt->num_complete = 2

it was tested 5 times, for every tcp / ttcp and the results were the same.

  1. any idea why there is a difference?
  2. does it has any relation to my problem?
    –

Benzy Gabay
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:9pa9jd$4tj$1@nntp.qnx.com…

Benzy Gabay <> bgabay@everbee.com> > wrote:
Hi,

I’m building intermediate driver which is located below ip.
I have built, debug and made a working driver on the ttcp/ip.
believing that ttcp/ip is a subset of tcp/ip , I thought that to move my
driver to the tcp/ip will be straightforward.
But, as everything in life is not simple, it does not work on tcp/ip.

uname -a is:
QNX6.1.0 2001/06/25-15:31:48 x86pc x86

Scenario 1:

  • I’m killing the io-net process.
  • loading io-net with ttcp/ip
  • mouting my driver to io-net
  • pinging a machine.
  • monitoring the packets.

the ping succeeds and I can see in the monitor that packets are coming
back
and forward to/from the QNX machine


Scenario 2:

  • I’m killing the io-net process.
  • loading io-net with tcp/ip
  • mouting my driver to io-net

Since tcpip don’t accept “if=enX::>” option, you have
to do:

ifconfig enX <mask

-xtang

  • pinging a machine.
  • monitoring the packets.

the ping does not succeeds and I can’t see in the monitor that packets
are
coming back and forward to/from the QNX machine.
looking at my logs I can see that rx_down finished successfully it
course,
and that’s it. nothing happens from this point.
Retries of other pings are not effecting anything, the network is not
working.

  1. any idea why is there a difference between the 2 stacks ?
  2. any idea where to look from the bug?

Thanks

Benzy Gabay
R&D
Everbee Wireless
mailto:> bgabay@everbeewireless.com

5

This shouldn’t cause what you’re seeing here. The stack
just allocates the packet this way. What does your filter
do to the packet? Does the packet get out? Does a reply come
back?

-seanb

Benzy Gabay <bgabay@everbee.com> wrote:
: Hi,

: Regarding my problem,

: After deeper investigation I’ve found that there is a difference in
: npkt->num_complete in ttcp and tcp.
: On down packet (after doing a simple ping, with no extra parameters, from
: the qnx machine)
: in tcp npkt->num_complete = 3
: in ttcp npkt->num_complete = 2

: it was tested 5 times, for every tcp / ttcp and the results were the same.

: 1) any idea why there is a difference?
: 2) does it has any relation to my problem?
: –
: ----------------------------------------------
: Benzy Gabay
: “Xiaodan Tang” <xtang@qnx.com> wrote in message
: news:9pa9jd$4tj$1@nntp.qnx.com…
:> Benzy Gabay <bgabay@everbee.com> wrote:
:> > Hi,
:>
:> > I’m building intermediate driver which is located below ip.
:> > I have built, debug and made a working driver on the ttcp/ip.
:> > believing that ttcp/ip is a subset of tcp/ip , I thought that to move my
:> > driver to the tcp/ip will be straightforward.
:> > But, as everything in life is not simple, it does not work on tcp/ip.
:>
:> > uname -a is:
:> > QNX6.1.0 2001/06/25-15:31:48 x86pc x86
:>
:> > Scenario 1:
:> > - I’m killing the io-net process.
:> > - loading io-net with ttcp/ip
:> > - mouting my driver to io-net
:> > - pinging a machine.
:> > - monitoring the packets.
:>
:> > the ping succeeds and I can see in the monitor that packets are coming
: back
:> > and forward to/from the QNX machine
:>
:>
:> > Scenario 2:
:> > - I’m killing the io-net process.
:> > - loading io-net with tcp/ip
:> > - mouting my driver to io-net
:>
:> Since tcpip don’t accept “if=enX::>” option, you have
:> to do:
:>
:> ifconfig enX
:>
:> -xtang
:>
:> > - pinging a machine.
:> > - monitoring the packets.
:>
:> > the ping does not succeeds and I can’t see in the monitor that packets
: are
:> > coming back and forward to/from the QNX machine.
:> > looking at my logs I can see that rx_down finished successfully it
: course,
:> > and that’s it. nothing happens from this point.
:> > Retries of other pings are not effecting anything, the network is not
:> > working.
:>
:> > 1) any idea why is there a difference between the 2 stacks ?
:> > 2) any idea where to look from the bug?
:>
:> > Thanks
:> > –
:> > ----------------------------------------------
:> > Benzy Gabay
:> > R&D
:> > Everbee Wireless
:> > mailto:bgabay@everbeewireless.com
:>
:>

6

Sean,

My filter is allocating new packet, copying the original npkt, returning
tx_done to the originator, doing no modification to the original packet (at
this point) and send it down/up to the next module.
Well only first packet is getting out. I can also see it in a sniffer and a
icmp reply is getting back, but nothing happens.
from the moment that the packet has left the qnx machine is looks like the
machine is waiting for something, coz the ping command is stacked and only
ctrl-c after 5 min will release it from its conditions. (there are also
times that the whole qnx machine crashes because of it…)

–

Benzy Gabay
“Sean Boudreau” <seanb@qnx.com> wrote in message
news:9pcrqk$mpu$1@nntp.qnx.com…

This shouldn’t cause what you’re seeing here. The stack
just allocates the packet this way. What does your filter
do to the packet? Does the packet get out? Does a reply come
back?

-seanb

Benzy Gabay <> bgabay@everbee.com> > wrote:
: Hi,

: Regarding my problem,

: After deeper investigation I’ve found that there is a difference in
: npkt->num_complete in ttcp and tcp.
: On down packet (after doing a simple ping, with no extra parameters,
from
: the qnx machine)
: in tcp npkt->num_complete = 3
: in ttcp npkt->num_complete = 2

: it was tested 5 times, for every tcp / ttcp and the results were the
same.

: 1) any idea why there is a difference?
: 2) does it has any relation to my problem?
: –
: ----------------------------------------------
: Benzy Gabay
: “Xiaodan Tang” <> xtang@qnx.com> > wrote in message
: news:9pa9jd$4tj$> 1@nntp.qnx.com> …
:> Benzy Gabay <> bgabay@everbee.com> > wrote:
:> > Hi,
:
:> > I’m building intermediate driver which is located below ip.
:> > I have built, debug and made a working driver on the ttcp/ip.
:> > believing that ttcp/ip is a subset of tcp/ip , I thought that to move
my
:> > driver to the tcp/ip will be straightforward.
:> > But, as everything in life is not simple, it does not work on tcp/ip.
:
:> > uname -a is:
:> > QNX6.1.0 2001/06/25-15:31:48 x86pc x86
:
:> > Scenario 1:
:> > - I’m killing the io-net process.
:> > - loading io-net with ttcp/ip
:> > - mouting my driver to io-net
:> > - pinging a machine.
:> > - monitoring the packets.
:
:> > the ping succeeds and I can see in the monitor that packets are
coming
: back
:> > and forward to/from the QNX machine
:
:
:> > Scenario 2:
:> > - I’m killing the io-net process.
:> > - loading io-net with tcp/ip
:> > - mouting my driver to io-net
:
:> Since tcpip don’t accept “if=enX::>” option, you have
:> to do:
:
:> ifconfig enX -xtang
:
:> > - pinging a machine.
:> > - monitoring the packets.
:
:> > the ping does not succeeds and I can’t see in the monitor that
packets
: are
:> > coming back and forward to/from the QNX machine.
:> > looking at my logs I can see that rx_down finished successfully it
: course,
:> > and that’s it. nothing happens from this point.
:> > Retries of other pings are not effecting anything, the network is not
:> > working.
:
:> > 1) any idea why is there a difference between the 2 stacks ?
:> > 2) any idea where to look from the bug?
:
:> > Thanks
:> > –
:> > ----------------------------------------------
:> > Benzy Gabay
:> > R&D
:> > Everbee Wireless
:> > mailto:> bgabay@everbeewireless.com
:
:

7

How many filters do you have mounted in (either ip<->ip or en<->en or
otherwise). Can’t think of anything off hand. Guess will have to see
some code.

-seanb

Benzy Gabay <bgabay@everbee.com> wrote:
: Sean,

: My filter is allocating new packet, copying the original npkt, returning
: tx_done to the originator, doing no modification to the original packet (at
: this point) and send it down/up to the next module.
: Well only first packet is getting out. I can also see it in a sniffer and a
: icmp reply is getting back, but nothing happens.
: from the moment that the packet has left the qnx machine is looks like the
: machine is waiting for something, coz the ping command is stacked and only
: ctrl-c after 5 min will release it from its conditions. (there are also
: times that the whole qnx machine crashes because of it…)

: –
: ----------------------------------------------
: Benzy Gabay
: “Sean Boudreau” <seanb@qnx.com> wrote in message
: news:9pcrqk$mpu$1@nntp.qnx.com…
:>
:> This shouldn’t cause what you’re seeing here. The stack
:> just allocates the packet this way. What does your filter
:> do to the packet? Does the packet get out? Does a reply come
:> back?
:>
:> -seanb
:>
:> Benzy Gabay <bgabay@everbee.com> wrote:
:> : Hi,
:>
:> : Regarding my problem,
:>
:> : After deeper investigation I’ve found that there is a difference in
:> : npkt->num_complete in ttcp and tcp.
:> : On down packet (after doing a simple ping, with no extra parameters,
: from
:> : the qnx machine)
:> : in tcp npkt->num_complete = 3
:> : in ttcp npkt->num_complete = 2
:>
:> : it was tested 5 times, for every tcp / ttcp and the results were the
: same.
:>
:> : 1) any idea why there is a difference?
:> : 2) does it has any relation to my problem?
:> : –
:> : ----------------------------------------------
:> : Benzy Gabay
:> : “Xiaodan Tang” <xtang@qnx.com> wrote in message
:> : news:9pa9jd$4tj$1@nntp.qnx.com…
:> :> Benzy Gabay <bgabay@everbee.com> wrote:
:> :> > Hi,
:> :>
:> :> > I’m building intermediate driver which is located below ip.
:> :> > I have built, debug and made a working driver on the ttcp/ip.
:> :> > believing that ttcp/ip is a subset of tcp/ip , I thought that to move
: my
:> :> > driver to the tcp/ip will be straightforward.
:> :> > But, as everything in life is not simple, it does not work on tcp/ip.
:> :>
:> :> > uname -a is:
:> :> > QNX6.1.0 2001/06/25-15:31:48 x86pc x86
:> :>
:> :> > Scenario 1:
:> :> > - I’m killing the io-net process.
:> :> > - loading io-net with ttcp/ip
:> :> > - mouting my driver to io-net
:> :> > - pinging a machine.
:> :> > - monitoring the packets.
:> :>
:> :> > the ping succeeds and I can see in the monitor that packets are
: coming
:> : back
:> :> > and forward to/from the QNX machine
:> :>
:> :>
:> :> > Scenario 2:
:> :> > - I’m killing the io-net process.
:> :> > - loading io-net with tcp/ip
:> :> > - mouting my driver to io-net
:> :>
:> :> Since tcpip don’t accept “if=enX::>” option, you have
:> :> to do:
:> :>
:> :> ifconfig enX
:> :>
:> :> -xtang
:> :>
:> :> > - pinging a machine.
:> :> > - monitoring the packets.
:> :>
:> :> > the ping does not succeeds and I can’t see in the monitor that
: packets
:> : are
:> :> > coming back and forward to/from the QNX machine.
:> :> > looking at my logs I can see that rx_down finished successfully it
:> : course,
:> :> > and that’s it. nothing happens from this point.
:> :> > Retries of other pings are not effecting anything, the network is not
:> :> > working.
:> :>
:> :> > 1) any idea why is there a difference between the 2 stacks ?
:> :> > 2) any idea where to look from the bug?
:> :>
:> :> > Thanks
:> :> > –
:> :> > ----------------------------------------------
:> :> > Benzy Gabay
:> :> > R&D
:> :> > Everbee Wireless
:> :> > mailto:bgabay@everbeewireless.com
:> :>
:> :>
:>
:>

8
  1. How many filters, what is the filter (en-en, ip-ip) ?
    There is only one filter.
    I’m loading the io-net net by the following command line:
    io-net -d el900 -p tcpip
    ifconfig en0 192.168.100.10
    mount -Tio-net /x86/lib/dll/devn-MyDriver.so

Now, as I try to do a ping, I can see on the screen it tries and nothing is
been replied, also the qnx system sometimes crashes.

  1. Filter is been loaded as:
    …
    _REG_FILTER_BELOW | REG_INIT_ONCE | _REG_DEREG_ALL,
    “ip”,
    “ip”
    …

    \
  2. Since they saw packet going out, ICMP Reply coming in, does their
    filter got the “ICMP REPLY” packet (filter’s rx_up() get called)?

I can see on the network monitor the icmp reply, but the rx_up is not been
called, the system freeze after the packet has left the qnx box.

The scenario:
I do a ping from the qnx machine , after I’ve loaded the above.(answer1)
tx_down is been called.
I copy the packet I’ve received in my driver.
I do tx_done to the original packet.
I do tx_down to the copied packet.
I receive tx_done
I free the packet.
I return the function tx_done with success code.
system freeze.


\

Benzy Gabay
“Sean Boudreau” <seanb@qnx.com> wrote in message
news:9pf2uc$5sq$1@nntp.qnx.com…

How many filters do you have mounted in (either ip<->ip or en<->en or
otherwise). Can’t think of anything off hand. Guess will have to see
some code.

-seanb

Benzy Gabay <> bgabay@everbee.com> > wrote:
: Sean,

: My filter is allocating new packet, copying the original npkt, returning
: tx_done to the originator, doing no modification to the original packet
(at
: this point) and send it down/up to the next module.
: Well only first packet is getting out. I can also see it in a sniffer
and a
: icmp reply is getting back, but nothing happens.
: from the moment that the packet has left the qnx machine is looks like
the
: machine is waiting for something, coz the ping command is stacked and
only
: ctrl-c after 5 min will release it from its conditions. (there are also
: times that the whole qnx machine crashes because of it…)

: –
: ----------------------------------------------
: Benzy Gabay
: “Sean Boudreau” <> seanb@qnx.com> > wrote in message
: news:9pcrqk$mpu$> 1@nntp.qnx.com> …
:
:> This shouldn’t cause what you’re seeing here. The stack
:> just allocates the packet this way. What does your filter
:> do to the packet? Does the packet get out? Does a reply come
:> back?
:
:> -seanb
:
:> Benzy Gabay <> bgabay@everbee.com> > wrote:
:> : Hi,
:
:> : Regarding my problem,
:
:> : After deeper investigation I’ve found that there is a difference in
:> : npkt->num_complete in ttcp and tcp.
:> : On down packet (after doing a simple ping, with no extra parameters,
: from
:> : the qnx machine)
:> : in tcp npkt->num_complete = 3
:> : in ttcp npkt->num_complete = 2
:
:> : it was tested 5 times, for every tcp / ttcp and the results were the
: same.
:
:> : 1) any idea why there is a difference?
:> : 2) does it has any relation to my problem?
:> : –
:> : ----------------------------------------------
:> : Benzy Gabay
:> : “Xiaodan Tang” <> xtang@qnx.com> > wrote in message
:> : news:9pa9jd$4tj$> 1@nntp.qnx.com> …
:> :> Benzy Gabay <> bgabay@everbee.com> > wrote:
:> :> > Hi,
:> :
:> :> > I’m building intermediate driver which is located below ip.
:> :> > I have built, debug and made a working driver on the ttcp/ip.
:> :> > believing that ttcp/ip is a subset of tcp/ip , I thought that to
move
: my
:> :> > driver to the tcp/ip will be straightforward.
:> :> > But, as everything in life is not simple, it does not work on
tcp/ip.
:> :
:> :> > uname -a is:
:> :> > QNX6.1.0 2001/06/25-15:31:48 x86pc x86
:> :
:> :> > Scenario 1:
:> :> > - I’m killing the io-net process.
:> :> > - loading io-net with ttcp/ip
:> :> > - mouting my driver to io-net
:> :> > - pinging a machine.
:> :> > - monitoring the packets.
:> :
:> :> > the ping succeeds and I can see in the monitor that packets are
: coming
:> : back
:> :> > and forward to/from the QNX machine
:> :
:> :
:> :> > Scenario 2:
:> :> > - I’m killing the io-net process.
:> :> > - loading io-net with tcp/ip
:> :> > - mouting my driver to io-net
:> :
:> :> Since tcpip don’t accept “if=enX::>” option, you have
:> :> to do:
:> :
:> :> ifconfig enX :
:> :> -xtang
:> :
:> :> > - pinging a machine.
:> :> > - monitoring the packets.
:> :
:> :> > the ping does not succeeds and I can’t see in the monitor that
: packets
:> : are
:> :> > coming back and forward to/from the QNX machine.
:> :> > looking at my logs I can see that rx_down finished successfully it
:> : course,
:> :> > and that’s it. nothing happens from this point.
:> :> > Retries of other pings are not effecting anything, the network is
not
:> :> > working.
:> :
:> :> > 1) any idea why is there a difference between the 2 stacks ?
:> :> > 2) any idea where to look from the bug?
:> :
:> :> > Thanks
:> :> > –
:> :> > ----------------------------------------------
:> :> > Benzy Gabay
:> :> > R&D
:> :> > Everbee Wireless
:> :> > mailto:> bgabay@everbeewireless.com
:> :
:> :
:
: