Previous Thread
Next Thread
Print Thread
ASHLPR #1486 12 Nov 09 11:44 AM
Joined: Nov 2006
Posts: 2,192
S
Stephen Funkhouser Online Content OP
Member
OP Online Content
Member
S
Joined: Nov 2006
Posts: 2,192
ASHLPR doesn't work when the server specified in ashlpr.ini is a NetBios name. It only works with an IP Address.

Should it work with a NetBios name?


Stephen Funkhouser
Diversified Data Solutions
Re: ASHLPR #1487 12 Nov 09 01:47 PM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
It uses TCPX to make the connection, and TCPX uses the standard C networking function gethostbyname() to process the hostname.

Apparently gethostbyname() is not able to convert your NetBios name to its IP, but offhand it's not clear why, although presumably it has to do with the failure of whatever service is providing the conversion. (I'm guessing that is a dynamic conversion, else you could just plug in the fixed IP?)

To rule out the possibility that ASHLPR is simply mangling the NetBios name in the process of inputting if from the ASHLPR.INI file, turn on the XCALL and SOCKS traces and confirm that the entire NetBios name is in fact being passed in the TCPX call. Perhaps some other error status information output by the trace may provide additional clues.

Re: ASHLPR #1488 12 Nov 09 03:05 PM
Joined: Nov 2006
Posts: 2,192
S
Stephen Funkhouser Online Content OP
Member
OP Online Content
Member
S
Joined: Nov 2006
Posts: 2,192
I turned on the XCALL and SOCKS traces and "SET DEBUG ON", but it doesn't show much.

Code
Connect status = 0
PreProcess: Opening #59010, TSKAAA.tmp
PreProcess: new size is 535
Returning with #59001 open
Sending file [/vm/miame/dsk2/160013/test.bas] size=[535]
Connect status = 0
PreProcess: Opening #59010, TSKAAA.tmp
PreProcess: new size is 535
Returning with #59001 open
Sending file [/vm/miame/dsk2/160013/test.bas] size=[535]
Connect status = 0
PreProcess: Opening #59010, TSKAAA.tmp
PreProcess: new size is 535
Returning with #59001 open
Sending file [/vm/miame/dsk2/160013/test.bas] size=[535]
Connect status = 0
PreProcess: Opening #59010, TSKAAA.tmp
PreProcess: new size is 535
Returning with #59001 open
Sending file [/vm/miame/dsk2/160013/test.bas] size=[535]
Connect status = 0
PreProcess: Opening #59010, TSKAAA.tmp
PreProcess: new size is 535
Returning with #59001 open
Sending file [/vm/miame/dsk2/160013/test.bas] size=[535]


Stephen Funkhouser
Diversified Data Solutions
Re: ASHLPR #1489 12 Nov 09 03:18 PM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
You're looking at the ASHLPR.LOG. The XCALL and SOCKS traces would appear in the ashlog.log.

Re: ASHLPR #1490 12 Nov 09 03:30 PM
Joined: Nov 2006
Posts: 2,192
S
Stephen Funkhouser Online Content OP
Member
OP Online Content
Member
S
Joined: Nov 2006
Posts: 2,192
Okay, I've emailed you a copy of my ashlog.log file.


Stephen Funkhouser
Diversified Data Solutions
Re: ASHLPR #1491 12 Nov 09 04:47 PM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
Apparently there is no problem with the way the NetBios name is being passed to TCPX, but the sock=-2 code indicates that the gethostbyname() function failed to return a name:

xcall TCPX,F[9],F[-1],X4096,F[31515],F[1],B4[2000],S40[stephen-laptop]
tcpx: op=9, flags=1, sock=31515, timer=2000, sockary=0
tcpx rtn: status=0, sock=-2

According to the gethostbyname() man page:

Quote

The domain name queries carried out by gethostbyname() and gethostbyaddr() use a combination of any or all of the name server named(8), a broken out line from /etc/hosts, and the Network Information Service (NIS or YP), depending upon the contents of the order line in /etc/host.conf. The default action is to query named(8), followed by /etc/hosts.
You can try using the Linux dig command to try to debug the name resolution process.

Unfortunately, TCPX doesn't give you very much additional information about the error, although it's not clear there is much more to give, besides "name not found".

However, if your ASHLPD server is actually on the same machine that you are telnetting from, which is how it appears from your ashlog.log entry, then you can use an alternate form of the SERVER= specification in the ASHLPR.INI:

SERVER=TELNET
or
SERVER=TELNET:

It will translate "TELNET" to your own client IP address, which not only allows the IP to be determined at connection time, but also allows several people to share a single ASHLPR.INI but each with their own ASHLPD print server.

Re: ASHLPR #1492 17 Nov 09 08:21 AM
Joined: Nov 2006
Posts: 2,192
S
Stephen Funkhouser Online Content OP
Member
OP Online Content
Member
S
Joined: Nov 2006
Posts: 2,192
Now that I have this resolved I thought I'd share why I was having a problem.

The problem is that we have 5 different Linux servers, and haven't done a good job of keeping their /etc/hosts files up to date. The reason for this is that we use one of the servers for DHCP, and so you can't update the hosts file if you don't know what it needs to contain. So, this falls in to the realm of something I didn't know I didn't know.

To solve this I turned to our DNS server, and allowing the DHCP server to update the zone file for the LAN (I was previously unaware that this was possible). This way when a client requests an IP address their hostname (NetBios Name) is added to the zone file, so they end up with a Fully qualified DNS A record which you can use nslookup (or dig) to query by name, and reverse lookup by IP.

So, in the above I can now dig stephen-laptop.kkvet.com and it returns the proper IP address. And, I can ping stephen-laptop and it pings the proper IP.

I will say that this isn't a trivial setup, but I think it will be worthwhile.


Stephen Funkhouser
Diversified Data Solutions
Re: ASHLPR #1493 17 Nov 09 11:06 AM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
I knew it would be something like that. (Just couldn't put it into words) :rolleyes:

Thanks for the follow-up.


Moderated by  Jack McGregor, Ty Griffin 

Powered by UBB.threads™ PHP Forum Software 7.7.3