|
Is there any way to see what's happening between PATHWORKS (LMMCP? or
KNBDAEMON?) and the PWIP driver/interface?
We sometimes get stuck with stuff like:
Client gets network busy error. You look at server side with nbshow
knbstatus and see client listed. Can you look at anything else on
server?
All clients get LIC0055: license error and USE0053: network name not
found. The error is returned immediately (no long timeout). Yet SHOW
ASTAT <server> is returning server's nb name list over IP (all
clients/server in same subnet). From server you can see port 139 is in
listen state (Wollongong's IP stack). From client, log file from doing
DBGLICLM <server> shows correct Ethernet address of server, but then
fails with an error of 18 (Ncb?). From server $ TELNET <server> 139
returns connect failed; connection refused. What else can I look at on
server side to see if the connection between the server's IP stack and
PATHWORKS (on the server) are bound correctly. (The 2 knbdaemon logs
this customer had were completely empty).
Paul
|
| Paul
When you get a connect request from the client - via PWIP, then the
KNB module inside streams invokes the KNBdaemon to assist is
establishing the session. The only way to trace this is via a
debug image of streamsos and the ctrl tool to extract the debug
data.
Now when you do a NBSHOW KNBstatus and see the client listed in
the session list (or use SDA PWRK TRANSPORT extentions) and
the state is correct, then it means that the connection is
successfully established.
I would presume that you get a network busy error when a transport
connection times out. On Netbeui this is relatively small, like
a few hundred milli-sec's. On TCP its a little longer, and then,
the retransmission mechanism should take over. Another possibility
is when the clients ethernet driver is trying to put data on the
line but can't because of the colissions. At that moment I would
also expect a network busy error. The last possibility is a netbios
timer that protects a complete data transfer (using UDP or multiple
TCP packets - like NETBIOS$TIMEOUT) that could cause this to happen.
My approach would be to make an IRIS trace (IRIS PC near the client)
and measure the exact time from the request to the next
request/response. If you don't see anything on IRIS then think about
cleint buffers, collisions, etc...
Adrie
|
| > All clients get LIC0055: license error
"License server "<name>" did not respond within the timeout period."
> From client, log file from doing DBGLICLM <server> shows correct Ethernet
> address of server, but then fails with an error of 18 (Ncb?).
NetBIOS error 0x18: Session Ended Abnormally
"The most probable cause is that a send-type NCB timed out
because no receive command was available in the remote node."
|