Re: As my customer says it is an odd problem - is it DST, DNS or what? (long)
- From: bv@xxxxxxx (Bill Vermillion)
- Date: Thu, 15 Mar 2007 22:35:01 GMT
In article <VA.0000154e.00aa9ca2@xxxxxxxxxxxxxxxxxxxxx>,
Brian Keener <bkeener@xxxxxxxxxxxxxxxxxxxxx> wrote:
[much deleted only down to pertinent points - wjv]
This customer also has a process on their 5.0.7 system in their
accounting package where at a customers request they will Email
them a copy of an invoice. 5.0.7 is using sendmail but while we
are sending it out from the SCO machine the actual from and the
reply to email is set to an info@xxxxxxxxxxxx account (which
is an email account they have set up on ther outside world
email system). The SCO machine has no other email function than
standard system mail and then these outbound invoices. This
works well most of the time but occassionally they will get some
bad address or for some reason undelivered returns. I will post
on this in another post with some examples.
The returned mail should have a great deal of info that you can use
to diagnose the problem. Without seeing the error messages you can
tear your hair out trying to figure out the problem. [I go through
this quite often maintaining emails for an ISP and also for a few
outside machines]
Some places will refuse email if they can not resolve the machine's
name given in the mail vs the IP it came from and can reject it or
treat it as a forged address.
While researching this I could find no reason for these sporadic
failures but the customer mentioned a while back they had had
to change to the Bellsouth DNS servers on their windows system
(which is the main connection plus a router and DSL modem) to the
outside world). So in keeping in line we changed the Bellsouth
DNS server IPs in the SCO 5.0.7 /etc/resolv.conf file.
Now to tie this all together. They retrieve several files daily
from the SCO Machine to a Windows machine via and ftp script
using Windows ftp. They did this last on Thursday afternoon of
last week. I made the change for the DNS IPs in /etc/resolv.conf
on Thrusday Night and they changed the /etc/TIMEZONE and rebooted
early Friday Morning. The IT type on site is the only one with an
ethernet connection (besides on demand inbound VPN connections
through a windows machine) and all others are Serial through
a Digi. Since these two events the FTP process has failed to
function and telnet attempts to get a login are taking an
unusually long time. I have connected via VPN and have noticed
the long times from point of attach (Tiny Term) to a login prompt
and attempting to use his ftp script or manually connect via
windows ftp have failed. The best I have achieved is by using
Cygwin FTP and it takes a long time but does connect and if I use
sftp it connects quit quickly. It also seems using ssh to connect
vs telnet is quicker as well although not as noticable as the
sftp vs ftp.
It depends on the FTP package but many will totally refuse
connections if they can not resolve the name/IP combination from
the incoming IP address. I used to see this problem when I was
on an IP from an ISP that would give me IP addresses anywhere in
two differernt /24 blocks. The cure to make things go fast
was to add all the IP/name combinations to the /etc/hosts. And I
had this problem connecting to machines at the ISP I maintain so I
put those IP/name combinations in the /etc/hosts there too, and
connections went from as long as 2 minutes to almost instantly.
I suspect you have DNS problems. Will the machines resolve
correctly on both side from the DNS you are using. If not try
adding things to /etc/hosts. Messy but it works. I beleive it
is lmhosts in MS [at least it used to be].
Since then in an attempt to diagnose on the SCO machine I put the
original two DNS servers back in the /etc/resolv.conf file but
that has not helped.
It's the machine you are connecting to that needs to be able to
resolve the name/address combination from the incoming IP it sees.
Pings on the four different BellSouth DNS servers we had
showed the response time from the first two was much almost
instantaneous vs the two they had me change to which is why we
tried all 4 but with the originals listed first. Last night I
removed the two new ones leaving just the originals and advised
client a reboot might again be in order.
Pings are usually only good for checking connectivity - unless some
un-informed but well-meaning admin has blocked all ICMP messages -
which I see far too often.
And you really don't need to reboot. Just restart the TCP
services. It saves a lot of time and keeps customers happy as
their machines don't go down.
I see no reason that either of these above should affect the
login or the ftp procedure but I am at a loss to come up with any
other explanation. I thought at one point maybe the TZ expansion
was causing an issue when the environment was being established
for login but.... wouldn't something like that affect the serial
connections as well as the network.
Any thoughts - anyone seen anything like this. Thanks to all in
advance.
Again - both machines must be able to resolve and I suspect that if
you check on the target machine it won't resolve the SCO machine -
or vice-versa if the connection is going the other way.
Bill
--
Bill Vermillion - bv @ wjv . com
.
- Follow-Ups:
- Re: As my customer says it is an odd problem - is it DST, DNS or what? (long)
- From: Brian Keener
- Re: As my customer says it is an odd problem - is it DST, DNS or what? (long)
- From: Brian Keener
- Re: As my customer says it is an odd problem - is it DST, DNS or what? (long)
- References:
- As my customer says it is an odd problem - is it DST, DNS or what? (long)
- From: Brian Keener
- As my customer says it is an odd problem - is it DST, DNS or what? (long)
- Prev by Date: Re: cannot access terminal control database
- Next by Date: File System Manager Question on OS 6.0
- Previous by thread: As my customer says it is an odd problem - is it DST, DNS or what? (long)
- Next by thread: Re: As my customer says it is an odd problem - is it DST, DNS or what? (long)
- Index(es):
Relevant Pages
|
