“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.030215165039.6158B@node1…
I’m not from QSSL support, however I used to use this
interface a lot in the past. My recollection is that
it was a somewhat kludgy interface. Like the disk
interface, you present Net with some code entry points
and deal with buffers.
My guess is that your crash has something to do with you
not keeping up with the buffers. I would take a look
at priorities and possible overruns.
Just a guess however.
There are indeed LOTS of thing that can go wrong when using netraw
interface. A few that comes to mind is
- using too many TX buffer (your application should limit itself to using on
a few buffers (10) per lan)
- compiling with wrong memory model
- Normal bug
- Once register with Net you should not perform any memory allocation
routine such as malloc().
One mention in the original post
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.
How do you acheive this, I don’t see how a netraw application can redirect
pact to TCP/IP stack.
So the application is placed between :
(adapter/driver/)Net
and
Net.fd(/socket, …)
Not really, Net.fd is a network driver so Net/Net.*/netraw application all
sit pretty much at the same level. A netraw application does not sit
between Net and Net.fd.
These programs are started in that order.
What order, your post isn’t really clear about that. Net.fd should be
starte BEFORE your netraw application.
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.
Quite possible since Net is tightly couple with kernel. Plus networking
runs at pretty high priority. Some of the code provided by your application
is called directly by Net, if that code is buggy it can easely freeze the
machine.
I suggest starting a shell on a console a priority 29, then lower Proc32 at
priority 28. If only Net if frozen/eating up CPU you might be able to
access the machine though that high priority shell.
For informations, here below are some strange behaviours observed :
- compiling and linking the all application without “-g” make the Net
manager to stop with SIGSEV
That’s not a very good sign. I would start investigation this issue first.
- sometimes the network stops working for a while, and can be restarted
when launching a simple ping
I wonder how you do that “redirect to the TCP/IP stack” thing?
- inet services (like telnet) needs sometimes 45 secondes to give the
prompt back. After that, everything goes well.
That might be a DNS issue.
Any remarks, request for info, suggestions would really be more than
welcome.
thanks in advance.
Michele D
\
Mitchell Schoenbrun --------- > maschoen@pobox.com