From: <r.b...@co...> - 2007-01-12 20:39:20
|
Hi, I'm using coLinux 0.7.1pre with only Slirp as network in the configuratio= n: eth0=3Dslirp,,tcp:10022:22/tcp:15901:5901 Linux is Gentoo, the 2005.1 image from Sourceforge, working fine includin= g all network operations to the outside. My problem is that I cannot connect from Windows, I've tried ssh and vncv= iewer. Details: - colinux-slirp-net-daemon is working fine, I can see it listening to bot= h ports and spawning (or forking) a process when I try to connect. - sshd in Linux is working fine, it is listening, and I can connect from = Linux to 127.0.0.1 and also to 192.168.0.40 which are the local addresses of th= e network. - I can connect to anything (tested http, ssh, rsync) from Linux to outsi= de (outside being Windows (192.168.10.2 both netmasks are /24), or the Inter= net). - I cannot connect from outside to Linux (tested from Windows and from an= other computer via mapping the port at the gateway). The initial connection is= made, for instance ssh -> colinux-slirp-net-daemon port 10022, a process is spa= wned on a new port and ssh changes to that port, then nothing... until ssh closes= the connection and the slirp daemon answers to that close (I used snoop under= Solaris to see the traffic). The result with VNC is similar, just the po= rts change. - there is no firewall at Windows' side, and none I could find at Gentoo = Linux side. I installed syslog-ng in Linux and there are no messages about the= failed connection, sshd never sees the try. Did I miss something in the configuration? Is anybody using the Gentoo image with slirp port mapping? One solution I= 'm willing to try is installing Gentoo 2006.1 to another root filesystem. Any ideas/help will be appreciated. --=20 Ren=E9 Berber |
From: <r.b...@co...> - 2007-01-13 01:59:19
|
Just a couple further details: - The problem is not tcp-wrappers related (I know how that works with ssh= d); - Testing with the Fedora Core 5 image the connection is made to Linux, i= t has other problems (with PAM auth) but not the network. So, it is a Gentoo image problem. --=20 Ren=E9 Berber |
From: Henry N. <Henry.Ne@Arcor.de> - 2007-01-15 20:16:11
|
Ren=E9 Berber wrote: > Hi, >=20 > I'm using coLinux 0.7.1pre with only Slirp as network in the configurat= ion: >=20 > eth0=3Dslirp,,tcp:10022:22/tcp:15901:5901 >=20 > Linux is Gentoo, the 2005.1 image from Sourceforge, working fine includ= ing all > network operations to the outside. >=20 > My problem is that I cannot connect from Windows, I've tried ssh and vn= cviewer. >=20 > Details: >=20 > - colinux-slirp-net-daemon is working fine, I can see it listening to b= oth ports > and spawning (or forking) a process when I try to connect. >=20 > - sshd in Linux is working fine, it is listening, and I can connect fro= m Linux > to 127.0.0.1 and also to 192.168.0.40 which are the local addresses of = the network. >=20 > - I can connect to anything (tested http, ssh, rsync) from Linux to out= side > (outside being Windows (192.168.10.2 both netmasks are /24), or the Int= ernet). >=20 > - I cannot connect from outside to Linux (tested from Windows and from = another > computer via mapping the port at the gateway). The initial connection = is made, > for instance ssh -> colinux-slirp-net-daemon port 10022, a process is s= pawned on > a new port and ssh changes to that port, then nothing... until ssh clos= es the > connection and the slirp daemon answers to that close (I used snoop und= er > Solaris to see the traffic). The result with VNC is similar, just the = ports change. >=20 > - there is no firewall at Windows' side, and none I could find at Gento= o Linux > side. I installed syslog-ng in Linux and there are no messages about t= he failed > connection, sshd never sees the try. >=20 > Did I miss something in the configuration? >=20 > Is anybody using the Gentoo image with slirp port mapping? One solution= I'm > willing to try is installing Gentoo 2006.1 to another root filesystem. >=20 > Any ideas/help will be appreciated. You know that, inside coLinux sshd is listen on 10.0.2.15 network!=20 Check it with "netstat -an". Sshd should listen on all networks=20 (0.0.0.0:22) or on your slirp network (10.0.2.15:22). Slirp only works=20 with ipaddress 10.0.2.15, with only the netmask 255.255.255.0, check it.=20 Check the broadcast 10.0.2.255 Try "ssh 10.0.2.15" inside coLinux. SSHD locks in the DNS or /etc/hosts for the windows side address=20 10.0.2.2, this was a very long timeout for me. I wrote this lines into=20 my /etc/hosts, and than sshd runs very fine (SuSE 9.0): 10.0.2.2 slirp-router 10.0.2.3 slirp-dns 10.0.2.15 slirp-client 10.0.2.2 is your default route. Right? Check the /etc/resolv.conf Terminate the sshd daemon and run it in foreground with verbose messages=20 "sshd -D -d" 192.168.0.* I'm afraid, is your TAP driver rigth? If you have tap and=20 slirp configured: Shutting down the tap by "ifconfig ethX" and try only=20 the slirp. After slirp is running, enable tap again. Tap is typical a=20 network only betwen windows and linux (not outgoing). Have you a file /etc/host.allow|deny? Is there configured right? (I'm=20 not shure with this for sshd) On windows side: Check, that your ethernet card (192.168.10.2 I think) is listen on port=20 10022 "netstat.exe -an", or 0.0.0.0 for all networks. Try SSH connection with putty from Windows to "localhost" port 10022. --=20 Henry Nestler |
From: <r.b...@co...> - 2007-01-15 23:43:31
|
Henry Nestler wrote: [snip] > You know that, inside coLinux sshd is listen on 10.0.2.15 network!=20 > Check it with "netstat -an". Sshd should listen on all networks=20 > (0.0.0.0:22) or on your slirp network (10.0.2.15:22). Slirp only works= =20 > with ipaddress 10.0.2.15, with only the netmask 255.255.255.0, check it= =2E=20 sshd is listening on 0.0.0.0:22 (by default it also listens on the ipv6 a= ddress but I disabled it to see if it helped). The Linux eth0 address is not the one you mention, it is 192.168.0.40 and= it receives that address from a DHCP server which I guess is the slirp-daemo= n since I have only one DHCP server and that one did not give that address. I don't use that network, but I see in the comments of Gentoo's network configuration that is seems to be the default Gentoo network. > Check the broadcast 10.0.2.255 Yes, broadcast is 10.0.2.255, so networking is set all wrong > Try "ssh 10.0.2.15" inside coLinux. ssh connected to my sshd running in Windows. > SSHD [locks]looks in the DNS or /etc/hosts for the windows side address= =20 > 10.0.2.2, this was a very long timeout for me. I wrote this lines into= =20 > my /etc/hosts, and than sshd runs very fine (SuSE 9.0): > 10.0.2.2 slirp-router > 10.0.2.3 slirp-dns > 10.0.2.15 slirp-client >=20 > 10.0.2.2 is your default route. Right? Check the /etc/resolv.conf Yes, 10.0.2.2 is the default route, and 'slirp-dns' is the DNS server. > Terminate the sshd daemon and run it in foreground with verbose message= s=20 > "sshd -D -d" >=20 > 192.168.0.* I'm afraid, is your TAP driver rigth? I disabled TAP, I'm not using it. > If you have tap and=20 > slirp configured: Shutting down the tap by "ifconfig ethX" and try only= =20 > the slirp. After slirp is running, enable tap again. Tap is typical a= =20 > network only betwen windows and linux (not outgoing). >=20 > Have you a file /etc/host.allow|deny? Is there configured right? (I'm = > not shure with this for sshd) Yes, I know very well how sshd works with those files (I'm using DenyHost= s and fail2ban on some servers). > On windows side: > Check, that your ethernet card (192.168.10.2 I think) is listen on port= =20 > 10022 "netstat.exe -an", or 0.0.0.0 for all networks. Yes, slirp-daemon is listening on the ports I configured. > Try SSH connection with putty from Windows to "localhost" port 10022. The result is what I reported before. The problem, as you pointed out in your first comment, is that I have an = IP address that does not belong to the Linux network. I have to find out wh= ich DHCP server gave that address or from where it comes from. A quick solut= ion is to set a fixed IP address using 10.0.2.15 . Thanks for your reply, it was very helpful. --=20 Ren=E9 Berber |
From: <r.b...@co...> - 2007-01-16 00:38:07
|
After reading `man dhcpcd` the solution was easy. As Henry pointed out, I was getting the wrong IP address from the DHCP se= rver (slirp-daemon in this case). The reason is that dhcpdcd asks the server = to reuse the last address the "computer" had, slirp-daemon accepted that add= ress wich was 192.168.0.40 (I probably used it as fixed address at some time).= The solution is to delete dhcpdcd's cache (for reference: /var/lib/dhcpc/dhcpcd-eth0.cache), tested with `dhcpdcd -T` and saw, in t= he =2Einfo file same directory, that the new address was OK, rebooted and ev= erything is fine. Thanks Henry, your reply made it easy to fix. --=20 Ren=E9 Berber |
From: Henry N. <Henry.Ne@Arcor.de> - 2007-01-16 08:33:32
|
Hey Ren=E9, Ren=E9 Berber wrote: > After reading `man dhcpcd` the solution was easy. >=20 > As Henry pointed out, I was getting the wrong IP address from the DHCP = server > (slirp-daemon in this case). The reason is that dhcpdcd asks the serve= r to > reuse the last address the "computer" had, slirp-daemon accepted that a= ddress > wich was 192.168.0.40 (I probably used it as fixed address at some time= ). >=20 > The solution is to delete dhcpdcd's cache (for reference: > /var/lib/dhcpc/dhcpcd-eth0.cache), tested with `dhcpdcd -T` and saw, in= the > .info file same directory, that the new address was OK, rebooted and ev= erything > is fine. >=20 > Thanks Henry, your reply made it easy to fix. think, you found a very old unsolved problem with dhcpcd and slirp. Have I understand rigth: Slirp ACKed the older address 192.x.x.x? --=20 Henry Nestler |
From: <r.b...@co...> - 2007-01-16 16:48:41
|
Henry Nestler wrote: > Hey Ren=E9, >=20 > Ren=E9 Berber wrote: >> After reading `man dhcpcd` the solution was easy. >> >> As Henry pointed out, I was getting the wrong IP address from the DHCP= server >> (slirp-daemon in this case). The reason is that dhcpdcd asks the serv= er to >> reuse the last address the "computer" had, slirp-daemon accepted that = address >> wich was 192.168.0.40 (I probably used it as fixed address at some tim= e). >> >> The solution is to delete dhcpdcd's cache (for reference: >> /var/lib/dhcpc/dhcpcd-eth0.cache), tested with `dhcpdcd -T` and saw, i= n the >> .info file same directory, that the new address was OK, rebooted and e= verything >> is fine. >> >> Thanks Henry, your reply made it easy to fix. >=20 > think, you found a very old unsolved problem with dhcpcd and slirp. > Have I understand rigth: Slirp ACKed the older address 192.x.x.x? Yes, it did. --=20 Ren=E9 Berber |