Question first: Does anyone know why scp won't resolve the dns name wheezy to the ip address 192.168.164.144 while ping does?
Explanation & Details second:
While on OS Mavericks I could scp files from my terminal to my VMWare Fusion Debian instance just fine. I just had to make sure that the ip address and machine name (wheezy) were in both the Debian /etc/hosts file and in the /etc/hosts file of my mac.
However after upgrading to Yosemite I can't scp files to my virtual host using the domain name. I CAN scp files to the virtual machine if I specify the ip address. So this works:
scp test_file.txt dan#192.168.165.144:~/
but this does not:
scp test_file.txt dan#wheezy:~/
This boggles my mind because the host "wheezy" pings just fine:
BASHdan#DanRauxa ~ >>ping wheezy
PING wheezy (192.168.165.144): 56 data bytes
64 bytes from 192.168.165.144: icmp_seq=0 ttl=64 time=0.335 ms
64 bytes from 192.168.165.144: icmp_seq=1 ttl=64 time=0.337 ms
64 bytes from 192.168.165.144: icmp_seq=2 ttl=64 time=0.290 ms
^C
--- wheezy ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.290/0.321/0.337/0.022 ms
and my /etc/hosts file is actually identical on both the Yosemite and Wheezy machine:
127.0.0.1 localhost
192.168.165.1 DanRauxa
192.168.165.144 wheezy
127.0.0.1 drupal-7-31.local
127.0.0.1 drupal8devprep.local
Does anyone know why scp won't resolve the dns name wheezy to the ip address 192.168.164.144 while ping does?
Many thanks.
-d-
Check your ~/.ssh/config to see if there is a wheezy host in there.
Also run the scp in verbose mode:
scp -v test_file.txt dan#wheezy:~/.
Might give you more information on where the failure is happening.
Related
I haven't been able to solve this problem for a few days, I've followed millions of tutorials online but I couldn't find anything about it.
I have an EC2 instance that has as private ip: 172.31.27.40.
I have only one VPC (the default one, with 3 subnets).
This is my SG:
On prem I have ip address (public): 1.2.3.4.
I created a customer-gateway (with on-prem public ip), a virtual-private-gateway (to which I attached the vpc) and the site-to-site connection.
My 2 tunnels are UP , in Static-Routes I added 192.168.0.0/24 (my on prem subnet).
I am using the aws-updown.sh script in the ipsec configuration.
My ipsec config:
conn Tunnel1
auto=start
left=%defaultroute
leftid=1.2.3.4
right=(Outside IP address Tunn1)
type=tunnel
leftauth=psk
rightauth=psk
keyexchange=ikev1
ike=aes128-sha1-modp1024
ikelifetime=8h
esp=aes128-sha1-modp1024
lifetime=1h
keyingtries=%forever
leftsubnet=192.168.0.0/24
rightsubnet=172.31.0.0/16
dpddelay=10s
dpdtimeout=30s
dpdaction=restart
## Please note the following line assumes you only have two tunnels in your Strongswan configuration file. This "mark" value must be unique and may need to be changed based on other entries in your configuration file.
mark=499
## Uncomment the following line to utilize the script from the "Automated Tunnel Healhcheck and Failover" section. Ensure that the integer after "-m" matches the "mark" value above, and <VPC CIDR> is replaced with the CIDR of your VPC
## (e.g. 192.168.1.0/24)
leftupdown="/usr/local/sbin/ipsec-notify.sh -ln Tunnel1 -ll *******/30 -lr ******/30 -m 499 -r 172.31.0.0/16"
This is my route table:
From EC2:
[root#ip-***** ec2-user]# ping 192.168.0.58
PING 192.168.0.58 (192.168.0.58) 56(84) bytes of data.
64 bytes from 192.168.0.58: icmp_seq=1 ttl=64 time=7.82 ms
64 bytes from 192.168.0.58: icmp_seq=2 ttl=64 time=7.84 ms
64 bytes from 192.168.0.58: icmp_seq=3 ttl=64 time=7.76 ms
64 bytes from 192.168.0.58: icmp_seq=4 ttl=64 time=10.8 ms
From On prem:
root#****:/home/utente# ping 172.31.27.40
PING 172.31.27.40 (172.31.27.40) 56(84) bytes of data.
From 169.254.**** icmp_seq=1 Destination Host Unreachable
From 169.254.**** icmp_seq=2 Destination Host Unreachable
From 169.254.**** icmp_seq=3 Destination Host Unreachable
From 169.254.**** icmp_seq=4 Destination Host Unreachable
Can you help me?
I was doing az login from WSL of my windows machine. Then it gives an error:
Please ensure you have network connection. Error detail: HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Max retries exceeded with url: /common/oauth2/token (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f401d135630>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
I hope this is a DNS issue.
So I checked /etc/resolv.conf of WSL:
# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line.
nameserver 192.168.1.1
nameserver fcc0:0:0:ffff::1
nameserver fcc0:0:0:ffff::2
192.168.1.1 is the default gateway.
There are the results of some commands I tried:
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=128 time=0.351 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=128 time=0.888 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=128 time=0.883 ms
$ dig 192.168.1.1
; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> 192.168.1.1
;; global options: +cmd
;; connection timed out; no servers could be reached
$ nslookup 192.168.1.1
;; connection timed out; no servers could be reached
These commands also give an output that indicates an issue.
Ping google.com
dig google.com
All these commands( or its alternatives) work from the Windows command prompt works correctly.
I found a workaround here:
https://askubuntu.com/questions/91543/apt-get-update-fails-to-fetch-files-temporary-failure-resolving-error
It says that I should add the followinng line to /etc/resolv.conf. If I try it like this, it works.
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver fcc0:0:0:ffff::1
nameserver fcc0:0:0:ffff::2
After this, the ping google.com and dig google.com works fine. But I can see that the nameserver it uses to resolve is 8.8.8.8.
If I connect to VPN, it adds our own nameservers to /etc/resolv.conf and after that, there is no problem in resolving the URLs. Once the VPN is disconnected, the issue arises again.
Note:
There were no issues like this before.
Last day we changed our router in order to use a new ISP's connection and after that, the issue occurs.
Other machines in the same network don't have this issue.
Why this occurs and How can I properly fix this issue of WSL?
Why only one machine in our network can ping, but can't dig to the default gateway?
Update:
I can see that there are two entries that are marked as default in routing table:
$ ip route show table all | grep default
none default via 192.168.0.1 dev wifi0 proto unspec metric 0
none default via 192.168.1.1 dev eth6 proto unspec metric 0
Already tried:
Connect the BBB with USB to iMac
Share internet with the board from System Preferences->Sharing
ssh to the board and then try to udhcp -i usb0
This is what it says:
udhcpc (v1.20.2) started
Gets stuck and I get and error: Write failed: Broken pipe
ssh exits
Any clues?
After some try-and-erroring, here's what worked for me:
1. Watch this video: http://www.youtube.com/watch?v=Cf9hnscbSK8
2. If your BBB was shipped after November 2013, instead of screen /dev/tty.usb*B 115200 use screen /dev/tty.usb* 115200 and actually you need to go to the /dev directory and check which of the tty.usbXXX is available for your BBB and screen it. In my case it was tty.usb131 for example
3. You continue the steps just like in the video until opkg update which would be the thing you need to do over the internet
And that it's all about it.
Your SSH session is getting stuck because you're connected to usb0 and the udhcpc command changed the IP address for it! At this point there's nothing listening on the other end of your ssh session, so your local computer's ssh client eventually fails with the broken pipe error and exits.
An obvious workaround is to connect via tty.usbserial instead of ssh to the IP address. You'd think the usb port's assigned IP shouldn't be changing though. Read on to understand what's happening.
Most people using a BBB for the first time attach them directly to their Internet connected computer using the supplied USB cable. It's exactly what the BBBs designers intended for you to do, and they've done a fantastic job with the BBBs startup web page.
That host computer shares it connection differently though depending on whether it's Windows, OS X or Linux, and how you do it varies depending on the version of the OS you're running.
Derek Molloy (Exploring BeagleBone) and Jason Kridner (Youtube OS X Beaglebone video) provide some fairly detailed instructions to use host based Internet sharing with your BBB. The Linux and Windows instructions are still good, but they need to update the OS X info for Yosemite - Apple switched their NAT and firewall software to pf from ipfw and natd. If you try running udhcpc like Jason did in his vid it doesn't work the same way as his did.
So back to your BBB SSH problem with OS X Yosemite. Here's how to see what's going on: Connect to the BBB using a serial/FTDI cable, then check the ip config of usb0 for the beaglebone.
beaglebone:~# ifconfig -a usb0
usb0 Link encap:Ethernet HWaddr 0e:be:ff:00:ff:00 inet addr:192.168.7.2
Bcast:192.168.7.3 Mask:255.255.255.252
confirm you can ping the host that's sharing it's Internet connection
beaglebone:~# ping 192.168.7.1
PING 192.168.7.1 (192.168.7.1) 56(84) bytes of data.
64 bytes from 192.168.7.1: icmp_req=1 ttl=64 time=0.681 ms
64 bytes from 192.168.7.1: icmp_req=2 ttl=64 time=0.533 ms
^C
try reaching an Internet IP (google dns)
beaglebone:~# ping 8.8.8.8
connect: Network is unreachable
check routes and confirm there's no default route out, which is why the ping above failed (a USB connected BBB has a 192.168.7.0/30 network setup by default, so it can only reach 192.168.7.0, .1, .2 and .3 addresses).
beaglebone:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.7.0 0.0.0.0 255.255.255.252 U 0 0 0 usb0
so if you run udhcpc it will add the missing route for you. you could also just add the route directly, but you need to setup dns as well, and with OS X Internet sharing it won't work without also changing the BBB's IP address - see links at end of this post)
beaglebone:~# udhcpc -i usb0
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
and here is where udhcpc changes the IP instead of just re-using 192.168.7.2. The new IP is compatible with the IP range used by OS X Internet Sharing, so that may be why the DHCP server is returning it.
Sending select for 192.168.2.34...
Lease of 192.168.2.34 obtained, lease time 85536
udhcpc then throws an error because there's no default route to delete
/etc/udhcpc/default.script: Resetting default routes
SIOCDELRT: No such process
udhcpc then adds the default route - note carefully it's an OS X Internet Sharing 192.168.2 address, not the original 192.168.7.
/etc/udhcpc/default.script: Adding DNS 192.168.2.1
everything worked, so you can see the new route and successfully ping an external IP now
beaglebone:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 usb0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 usb0
beaglebone:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=53 time=4.08 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=53 time=3.59 ms
^C
There are a couple of blog posts that show how to set this up permanently:
Sharing OS X Internet Connection over USB to BeagleBone Black
and
Changing usb0 IP address on the BeagleBone Black
I've tried to configure cluster following through Glassfish clustering tutorials (1, 2), but I'm still having troubles with creating instance in cluster on remote host.
I think it will be better if I give you output with inserted commands, it'll probably explain more:
adam#adam-desktop:~/Pulpit/glassfish-3.1.1/bin$ ./asadmin
Use "exit" to exit and "help" for online help.
asadmin> setup-ssh adam-laptop
Successfully connected to adam#adam-laptop using keyfile /home/adam/.ssh/id_rsa
SSH public key authentication is already configured for adam#adam-laptop
Command setup-ssh executed successfully.
asadmin> install-node --installdir /home/adam/Pulpit/glassfish3 adam-laptop
Created installation zip /home/adam/Pulpit/glassfish-3.1.1/bin/glassfish8196347853130742869.zip
Successfully connected to adam#adam-laptop using keyfile /home/adam/.ssh/id_rsa
Copying /home/adam/Pulpit/glassfish-3.1.1/bin/glassfish8196347853130742869.zip (82498155 bytes) to adam-laptop:/home/adam/Pulpit/glassfish3
Installing glassfish8196347853130742869.zip into adam-laptop:/home/adam/Pulpit/glassfish3
Removing adam-laptop:/home/adam/Pulpit/glassfish3/glassfish8196347853130742869.zip
Fixing file permissions of all files under adam-laptop:/home/adam/Pulpit/glassfish3/bin
Command install-node executed successfully.
asadmin> start-domain domain1
Waiting for domain1 to start ........................
Successfully started the domain : domain1
domain Location: /home/adam/Pulpit/glassfish-3.1.1/glassfish/domains/domain1
Log File: /home/adam/Pulpit/glassfish-3.1.1/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
asadmin> enable-secure-admin
Command enable-secure-admin executed successfully.
asadmin> restart-domain domain1
Successfully restarted the domain
Command restart-domain executed successfully.
asadmin> create-cluster c1
Command create-cluster executed successfully.
asadmin> create-node-ssh --nodehost adam-laptop --installdir /home/adam/Pulpit/glassfish3 adam-laptop
Command create-node-ssh executed successfully.
asadmin> create-instance --node adam-laptop --cluster c1 i1
Successfully created instance i1 in the DAS configuration, but failed to create the instance files on node adam-laptop (adam-laptop).
Command failed on node adam-laptop (adam-laptop): Could not contact the DAS running at adam-desktop:4848. This could be because a firewall is blocking the connection back to the DAS or because the DAS host is known by a different name on the instance host adam-laptop. To change the hostname that the DAS uses to identify itself please update the DAS admin HTTP listener address.
Command _create-instance-filesystem failed.
To complete this operation run the following command locally on host adam-laptop from the GlassFish install location /home/adam/Pulpit/glassfish3:
asadmin --host adam-desktop --port 4848 create-local-instance --node adam-laptop i1
asadmin>
UPDATE
I'm putting hosts file contents and ping command output for sure, that exists connection between adam-desktop and adam-laptop:
adam#adam-desktop:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 adam-desktop
192.168.1.101 adam-laptop
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
adam#adam-desktop:~$ cat /etc/hostname
adam-desktop
adam#adam-desktop:~$ ping adam-laptop
PING adam-laptop (192.168.1.101) 56(84) bytes of data.
64 bytes from adam-laptop (192.168.1.101): icmp_req=1 ttl=64 time=0.786 ms
64 bytes from adam-laptop (192.168.1.101): icmp_req=2 ttl=64 time=0.694 ms
64 bytes from adam-laptop (192.168.1.101): icmp_req=3 ttl=64 time=0.687 ms
Any help?
After the domain is started, can you reach http://localhost:4848 or http://adam-desktop:4848 in your browser ?
If not, on linux glassfish requires you to set up the /etc/hosts file correctly and this is where most of my problems like this come from. Also set up the appropriate network config. On Redhat it is /etc/sysconfig/network and on Ubuntu it is /etc/hostname
It seems that error was caused by entry in /etc/hosts file.
127.0.0.1 localhost
127.0.1.1 adam-desktop
192.168.1.101 adam-laptop
after changing to:
127.0.0.1 localhost
127.0.0.1 adam-desktop
192.168.1.101 adam-laptop
it works. I had to make changes on two machines, it means on adam-desktop and adam-laptop.
I'd like to learn and play with tcp/ip libraries for python, java or c++. But I only have one computer. Is it possible to "fake" remote computers to emulate remote hosts, under NAT end everything?
The simplest way is to run both the server and client on the same computer and use the "loopback" IP address: 127.0.0.1 which always connects to the local host. I've done this many times during testing. For example, run a local webserver on port NNN and then in the browser enter http://127.0.0.1:NNN/ In fact, 127.X.Y.Z should always talk to the local machine.
If you are using linux, you can configure dummy interfaces, then bind your client / server to different dummy interfaces.
[mpenning#Bucksnort ~]$ sudo modprobe dummy
[mpenning#Bucksnort ~]$ sudo ip addr add 192.168.12.12/24 dev dummy0
[mpenning#Bucksnort ~]$ ip addr show dummy0
6: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
link/ether b6:6c:65:01:fc:ff brd ff:ff:ff:ff:ff:ff
inet 192.168.12.12/24 scope global dummy0
[mpenning#Bucksnort ~]$ ping 192.168.12.12
PING 192.168.12.12 (192.168.12.12) 56(84) bytes of data.
64 bytes from 192.168.12.12: icmp_seq=1 ttl=64 time=0.085 ms
^C
--- 192.168.12.12 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.085/0.085/0.085/0.000 ms
[mpenning#Bucksnort ~]$ sudo modprobe dummy -o dummy1
[mpenning#Bucksnort ~]$ sudo rmmod dummy
[mpenning#Bucksnort ~]$ ip addr show dummy0
Device "dummy0" does not exist.
[mpenning#Bucksnort ~]$
You should be able to run ipchains on these interfaces just like any other.
You can start out with talking between programs on your own computer.
You can use virtual machine software such as VirtualBox, VMWare, VirtualPC, etc to create what is essentially a second machine within yours and talk to that (though the network topology may be very slightly unusual - something more to learn about)
If you want to talk to something remote, you can rent a small cloud server running linux or windows from the likes of Amazon for pennies an hour and install whatever you want on it.
Use virtual box to install OS in your system. for any networking application, this is best. You dont have to work on two different system and its easy to see whats happening at both ends
Run to server to listen on your network adapter, or localhost. Then issue requests to that same IP and Port. Logically, it will all take place within the network driver(s), but it will still behave the same way if that IP address were addressed to another machine (barring Firewall configurations, etc)