Topic: ssh login and FTP very slow

[guestHH]

Hi all,

With version 5.2.1 is notice the following:

- Extreme long waiting time for password prompt with ssh login(Putty)
- Extreme long waiting time when trying to ftp to an ibay (share@myserver.net)

Now I have to say I've implemented some php applications but I don't think this has anything to do with ssh and ftp.

I also noticed that a fresh install of 5.1.2 does not suffer from the above symptoms, but an upgraded system (4.x -> 5.1.2) does.

Does anybody else have these 'problems'?
MITEL is there something we should know ?

Thanks anyway.
Regards,

guestHH

[Luke Drumm]

I've noticed it with a clean install of 5.1.2 (ie. I'm suffering with it right now).
Regards,
Luke

[guestHH]

Oh ok Luke,

MITEL can you inform us of any 'stange' behaviour??

Thanks Luke.

Regards,
guestHH

[Luke Drumm]

Upon looking through the logs, I noticed the following:

sshd[3651]: Could not reverse map address 192.168.191.67

Could this be the cause of the problems?
Regards,
Luke

[Luke Drumm]

Upon looking through the logs, I noticed the following:

sshd[3651]: Could not reverse map address 192.168.191.67

Could this be the cause of the problems?
Regards,
Luke

[Luke Drumm]

In addition to this, when I do an nslookup for 192.168.191.67 (one of the workstations) I notice its attempting to resolve the IP address outside the network.

The subnet mask for the internal netwrok looks okay when I run IfConfig.

Route reveals the following:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
255.255.255.255 *               255.255.255.255 UH    0      0        0 eth0
192.168.191.0   *               255.255.255.0   U     0      0        0 eth0
[ISP SUPPLIED STUFF].0   *               255.255.240.0   U     0      0        0 eth1
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         [ISP SUPPLIED STUFF] 0.0.0.0         UG    0      0        0 eth1

Does anyhting look dodgey here?
Regards,
Luke

[guestHH]

Hi Luke,

Same here:

Mar  7 19:43:51 star-support sshd[11362]: Could not reverse map address 192.168.1.75.


AND nslookup 192.168.1.75 take the lookup outside of my local network.

My routing table:
eth0      Link encap:Ethernet  HWaddr 00:10:A7:0A:38:F6
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1474996 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1581489 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:10 Base address:0xbc00

eth1      Link encap:Ethernet  HWaddr 00:10:A7:0A:36:5F
          inet addr:[ISP SUPPLIED]  Bcast:[ISP SUPPLIED]  Mask:255.255.252.0
          UP BROADCAST NOTRAILERS RUNNING  MTU:1500  Metric:1
          RX packets:8120173 errors:4 dropped:0 overruns:0 frame:0
          TX packets:855917 errors:0 dropped:0 overruns:0 carrier:0
          collisions:23894 txqueuelen:100
          Interrupt:10 Base address:0xc000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:3924  Metric:1
          RX packets:414576 errors:0 dropped:0 overruns:0 frame:0
          TX packets:414576 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0

So what does this mean???? Are we looking at a routing problem, resolve problem, dns problem...

Regards,
guestHH

[Ari]

And joy of joys...
even after the bloody reload... *grumble grumble* my problem is back too.
Slow FTP... slow SSH using putty...

but I find this very interesting:
[root@tbfcserv01 /root]# nslookup 192.168.1.1
Server:  ns1nr.wp.shawcable.net
Address:  24.66.94.195

*** ns1nr.wp.shawcable.net can't find 192.168.1.1: No response from server

192.168.1.1 is the internal IP of my server. Neat huh?

eth0      Link encap:Ethernet  HWaddr 00:50:BF:17:68:1A
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          EtherTalk Phase 2 addr:65280/112
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8842 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9381 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:11 Base address:0xa800

eth1      Link encap:Ethernet  HWaddr 00:50:BA:A7:68:46
          inet addr:24.85.12.224  Bcast:24.85.15.255  Mask:255.255.252.0
          UP BROADCAST NOTRAILERS RUNNING  MTU:1500  Metric:1
          RX packets:778 errors:0 dropped:0 overruns:0 frame:0
          TX packets:734 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:5 Base address:0xb000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          EtherTalk Phase 2 addr:0/0
          UP LOOPBACK RUNNING  MTU:3924  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0


So WTF is going on here?
Why is the server trying to resolve the internal IP address externally?

(and yes, I have a DHCP assigned external IP address)

Ari

[Dan Brown]

Sounds like all of you may be specifying external DNS servers during the server config--is that right?  If so, what happens if you remove that entry?

[Ari]

Nope. No external DNS is configured during my setup - and DHCP is determined by hardware for the ext. IP.

[Ari]

In fact... here's my server config:

Ethernet settings
  Ethernet driver 1    : rtl8139
  Ethernet driver 2    : ne2k-pci

External network settings
  Operation mode       : server and gateway - dedicated
  DHCP client          : enabled (send ethernet address as client id)
  Dynamic DNS          : do not use dynamic DNS service

Local network settings
  Local IP address     : 192.168.1.1
  Local subnet mask    : 255.255.255.0
  DHCP server          : enabled, using host numbers from 192.168.1.65  to 192.168.1.250

Miscellaneous settings
  Primary domain name  : trollbane.com
  System name          : tbfcserv01
  External proxy       : no
  Status reports       : off
  Console mode         : login

Contact details can be configured by entering a contact e-mail address.


There ya go.

[Dan Brown]

Well, for some reason, it's trying to resolve hostnames via an external DNS server, which it shouldn't ever be doing if you haven't specified one.  What's in /etc/resolv.conf?

[Ari]

/etc/resolve.conf contains the following:

domain wp.shawcable.net
nameserver 24.66.94.195
nameserver 24.66.94.212
search wp.shawcable.net


and there in lies the problem.

I never told the server to use my ISP to resolve DNS. It did it of its own volition after the IP change through DHCP earlier today.

So...
easily correctable BUT for how long?

Why is this happening is the better question, I think.

Ari

[Ari]

And as soon as I changed the resolv.conf back to:

domain www.trollbane.com
nameserver 192.168.1.1

everything works fine again.

Interesting.

[Dan Brown]

My guess is that it's related to using DHCP.  DHCP, after all, does include methods for setting DNS parameters.  Don't know how to avoid it, though; probably some sort of change to the resolv.conf templates.

[Ari]

Dan Brown wrote:
>
> My guess is that it's related to using DHCP.  DHCP, after
> all, does include methods for setting DNS parameters.  Don't
> know how to avoid it, though; probably some sort of change to
> the resolv.conf templates.

Perhaps, but...
shouldn't a reboot of the server correct that problem then? I mean the SME template system should kick in and reset the resolv.conf file to what it was originally supposed to be... but it doesn't.

I dunno. I'm just glad it was finally figured out.

[Dan Brown]

Curiouser and curiouser...  The e-smith templates for resolv.conf just point it to 127.0.0.1.  So, it looks like the dhcp client is somehow re-writing resolv.conf.  No, a reboot of the server won't rebuild the config files from templates.

[Terry Brummell]

Mine was the same way, DNS settings were for the ISP, not the local server.  Changed it to my domain and server IP and all resolves nice and quick again.  What is the fix, and has anyone sent this of the N.S.S.G.?

Dan Brown wrote:
>
> Curiouser and curiouser...  The e-smith templates for
> resolv.conf just point it to 127.0.0.1.  So, it looks like
> the dhcp client is somehow re-writing resolv.conf.  No, a
> reboot of the server won't rebuild the config files from
> templates.

[Dan Brown]

The fix, for the time being, seems to be to be to re-expand the /etc/resolv.conf file after obtaining an address via DHCP.

[Berend]

Hallo All


Here the same thing. Every time you boot resolv.conf is rebuild with the
dhcpc settings and youre ocal setting is lost.

And the only thing that works is to expand-template /etc/resolv.conf

Hopely there will be a fix around soon

[Luke Drumm]

Would it make sense to add the 'template expand action' to the 'DHCP change IP event files'?

[guestHH]

uuuhhh, it's me ....

THANKS ARI and DAN B. for jumping in here!

It's working for me allright now again. And I'm also eager to hear a solution so that the resolv.conf is adapted to the correct settings every time my ISP finds it nessecsary to update by ext. IP. He isn't  gonne call me...

Anyway a BIG thanks to ARI for keeping me updated and jumping in, and as for DAN B. Hey! where would we be without your comments....

Thanks to both of you so far,

guestHH

[Dan Brown]

I've reported this to bugs@e-smith; we'll see what they say.

[Charlie Brady]

Dan Brown wrote:
>
> I've reported this to bugs@e-smith; we'll see what they say.

Ari also reported it not long before you did.

They'll get back to you in the morning, I'm sure.

In the mean time, running this command should fix the problem:

/usr/bin/perl -i.old -pe \
   's/DHCPCDARGS="-d/DHCPCDARGS="-R -d/' \
   /etc/sysconfig/network-scripts/ifup

Charlie

[guestHH]

Hi all,

Opened this thread, closing it....

See: http://forums.contribs.org/index.php?topic=13085.msg49364#msg49364

and await solutions...

Thanks once again to Ari and Dan B.

Regards,
guestHH

[guestHH]

ps.

I also suffered from a VERY LONG login time on my local LAN. With LOGIn i mean boot-up a client pc (WIn-XP with reg addaptons) and very unstable network connectios e.g. mapped volumes, services (Hylafax takes a very long time to authenicate....)

Will let you know what my resulta are AFTER i slept...

Regards,
guestHH

[Ari]

Just one final thought..

It may not necessarily be the SME server.

Apparently, some ISP's are pushing out DNS with their DHCP leases now... like mine (I think).

So if someone can think up some crafty way to override this whenever a new DHCP lease is pushed, that would be really cool.

Email me at ari@novikoff.net if ya have an idea.

Cheers!
Ari

[Charlie Brady]

Ari wrote:

> It may not necessarily be the SME server.
>
> Apparently, some ISP's are pushing out DNS with their DHCP
> leases now... like mine (I think).

That's perfectly normal.

> So if someone can think up some crafty way to override this
> whenever a new DHCP lease is pushed, that would be really cool.

See my earlier message, which contains instructions on patching the ifup script so that dhcpcd is started with the -R option, which tells it not to change /etc/resolv.conf. What I left out of the earlier instructions is that you need to do to restart dhcpcd with the new arguments.

# Bring down the external interface
/sbin/ifdown eth1
# Make sure that dhcpcd has exited
killall dhcpcd # Replace /etc/resolv.conf with the correct one
/sbin/e-smith/expand-template /etc/resolv.conf
# Restart the external interface
/sbin/ifup eth1

Replace eth1 with eth0 if your system is configured with "swapped"  ethernet interfaces.

Regards

Charlie

[Charlie Brady]

guestHH wrote:

> Opened this thread, closing it....

Please remember in future to report any suspected bugs to bugs@e-smith.com. We do not and cannot promise to monitor these bulletin boards.

Regards

Charlie

[Charlie Brady]

Charlie Brady wrote:

> In the mean time, running this command should fix the problem:
>
> /usr/bin/perl -i.old -pe \
>    's/DHCPCDARGS="-d/DHCPCDARGS="-R -d/' \
>    /etc/sysconfig/network-scripts/ifup

Allow me to correct myself (again).  Perform this command sequence:

# drop the external link - note therefore that you can perform the
# fix remotely using this procedure
/sbin/ifdown eth1
# Replace /etc/resolv.conf with the correct contents
/sbin/e-smith/expand-template /etc/resolv.conf
# Patch the ifup script to use the correct arguments to dhcpcd
/usr/bin/perl -i.old -pe \
    's/DHCPCDARGS="-d/DHCPCDARGS="-R -d/' \
    /sbin/ifup
# Now bring the external interface back up
/sbin/ifup eth1

Regards

Charlie

[Ari]

>
> # drop the external link - note therefore that you can
> perform the
> # fix remotely using this procedure
> /sbin/ifdown eth1
> # Replace /etc/resolv.conf with the correct contents
> /sbin/e-smith/expand-template /etc/resolv.conf
> # Patch the ifup script to use the correct arguments to dhcpcd
> /usr/bin/perl -i.old -pe \
>     's/DHCPCDARGS="-d/DHCPCDARGS="-R -d/' \
>     /sbin/ifup
> # Now bring the external interface back up
> /sbin/ifup eth1

A million and one thank you's Charlie! I truly appreciate your help (and everyone else that contributed) in resolving this issue.

Cheers!
Ari

[Berend]

Hello,

The Charlie solution works like a charm.

Very much thanks )

Greeting Berend,
from The Netherlands

[Kevin Manderson]

Thanks,

Now I have a fix for when I take my laptop so I can lecture at uni. I always had the resolv.conf overwritten when it booted (dhcp address from the uni) - now I won't :-}

Regards
kevin

[sander]

something strange: I haven't had time tu apply any updates to my 5.1.2 .
Mostly because the blades function doesn't work( An error occurred while fetching the list of available blades).

so the funny part is that ftp and ssh login was very slow. I repeat it WAS.
The server asks for my username and password quickly. Did the server update itself or what happened? Noone can apply any updates but me, and i haven't updated the system yet.

Thanks for any help
sander

[Brando]

Using this:
---
# drop the external link - note therefore that you can perform the
# fix remotely using this procedure
/sbin/ifdown eth1
# Replace /etc/resolv.conf with the correct contents
/sbin/e-smith/expand-template /etc/resolv.conf
# Patch the ifup script to use the correct arguments to dhcpcd
/usr/bin/perl -i.old -pe \
's/DHCPCDARGS="-d/DHCPCDARGS="-R -d/' \
/sbin/ifup
# Now bring the external interface back up
/sbin/ifup eth1
---

I'm still not able to resolve address from the net "unreachable host".   Say I try to ping www.msn.com - [unreachable host]

As well, From outside (from the net) I am not able to ping the box.

Would this be a DNS problem?
If I ping the box outside I am getting:
ICMP Host Unreachable from gateway 209.115.223.169
Which would be a DHCP server and not the DNS servers.

Any suggestions?