raw network Packet application on QNX 4.25

Hello,

We are developping an application that uses the function “RAW Data Packet”
to talk with Net.

Basically, the application is a bridge between 2 network interfaces and send
all the IP packet (0x0800) from one to the other . With an exception for the
packets with mac-destination to the QNX machine itself, in this case the
packets are released to the QNX tcp/ip stack.

So the application is placed between :
(adapter/driver/)Net
and
Net.fd(/socket, …)

These programs are started in that order.

The application and Net communicate thanks to shared code and shared data
(qnx_segment_arm). Therefor the application registers to the Net manager
when starting.

We are now facing some issues and we would be pleased with any feedback you
would give.
The behaviour of the application is quite chaotic, sometimes, it runs for
weeks, sometimes for days but it has a constant : it always crashes. The
crash is always the same :

  • QNX frozen, hard reboot needed
  • nothing in our log files
    We deeply believe that QNX freezes in the network related area.


    For informations, here below are some strange behaviours observed :
  1. compiling and linking the all application without “-g” make the Net
    manager to stop with SIGSEV
  2. sometimes the network stops working for a while, and can be restarted
    when launching a simple ping
  3. inet services (like telnet) needs sometimes 45 secondes to give the
    prompt back. After that, everything goes well.


    Any remarks, request for info, suggestions would really be more than
    welcome.

thanks in advance.

Michele D

“MicheleD” <michele-d@ibelgique.com> wrote in message
news:b2b1u4$4q9$1@inn.qnx.com

Hello,

We are developping an application that uses the function “RAW Data Packet”
to talk with Net.

Basically, the application is a bridge between 2 network interfaces and
send
all the IP packet (0x0800) from one to the other . With an exception for
the
packets with mac-destination to the QNX machine itself, in this case the
packets are released to the QNX tcp/ip stack.

So the application is placed between :
(adapter/driver/)Net
and
Net.fd(/socket, …)

These programs are started in that order.

The application and Net communicate thanks to shared code and shared data
(qnx_segment_arm). Therefor the application registers to the Net manager
when starting.

We are now facing some issues and we would be pleased with any feedback
you
would give.
The behaviour of the application is quite chaotic, sometimes, it runs for
weeks, sometimes for days but it has a constant : it always crashes. The
crash is always the same :

  • QNX frozen, hard reboot needed
  • nothing in our log files
    We deeply believe that QNX freezes in the network related area.


    For informations, here below are some strange behaviours observed :
  1. compiling and linking the all application without “-g” make the Net
    manager to stop with SIGSEV
  2. sometimes the network stops working for a while, and can be restarted
    when launching a simple ping
  3. inet services (like telnet) needs sometimes 45 secondes to give the
    prompt back. After that, everything goes well.


    Any remarks, request for info, suggestions would really be more than
    welcome.

thanks in advance.

As you understand, usage of Net’s raw interface is hm… a some kind of “qnx4
black magic” :slight_smile: Just due to the fact that this interface employs direct
calls between Net and raw app, uses shared objects which AFAIU arn’t checked
by Net and so on. All was done to keep up the performance. So the first
little bug, and the whole system is crashed. And of course, no one had a
chanse to log anything anywhere. This is explicitely and clear was told in
netraw package documentation.

So… are you sure you’r core code is completely clean, dosn’t have hidden
deadlocks and works as Net expects ? :slight_smile: Debugging such services may be a
very hard task if smth’s broken even a bit…

ps: that’s the same as calling fprintf(stdout, “Interrupt armed !”); inside
an ISR callback. 101% this is the last [and anyway lost] message a system
supposed to produce. Even if the reasons differ a bit.

// wbr