Koozali.org: home of the SME Server
Legacy Forums => Experienced User Forum => Topic started by: guestHH on March 06, 2002, 08:19:21 PM
-
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
-
I've noticed it with a clean install of 5.1.2 (ie. I'm suffering with it right now).
Regards,
Luke
-
Oh ok Luke,
MITEL can you inform us of any 'stange' behaviour??
Thanks Luke.
Regards,
guestHH
-
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
-
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
-
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
-
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
-
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
-
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?
-
Nope. No external DNS is configured during my setup - and DHCP is determined by hardware for the ext. IP.
-
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.
-
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?
-
/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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 ;-)
-
Would it make sense to add the 'template expand action' to the 'DHCP change IP event files'?
-
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
-
I've reported this to bugs@e-smith; we'll see what they say.
-
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
-
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
-
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
-
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
-
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
-
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 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
-
>
> # 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
-
Hello,
The Charlie solution works like a charm.
Very much thanks ;-))
Greeting Berend,
from The Netherlands
-
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
-
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
-
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?