I am facing a strange problem on my Ubuntu Karmic system.
When I call getaddrinfo() with AI_PASSIVE and AF_UNSPEC, for an empty host and the UDP 12000 port to get a bindable address, I only get back one IPv4 result (0.0.0.0:12000 for instance).
If I change my call and specify AF_INET6 instead of AF_UNSPEC, then getaddrinfo() returns "Name or service not known".
Shouldn't I get [::]:12000 as a result ?
The same thing happens if I set the host to ::1.
When I call getaddrinfo() without AI_PASSIVE (to get a "connectable" address) for the host "localhost" and the UDP 12000 port, I first get [::1]:12000 then 127.0.0.1:12000.
So apparently, my system is IPv6 ready (I can ping to both IPv4 and IPv6 addresses, as well as DNS resolution). But how is it that I can't get an IPv6 address to bind to with getaddrinfo() ?
Do you guys have any idea about what could be wrong ?
My OS is Ubuntu Karmic, fresh install without any networking tweaking.
Thank you.
P.S: If you have no idea but still want to help me, you can get this sample program or type:
wget http://people.apache.org/~jorton/gai.c
And give me the result of:
$ ./gai -ap null 12000
My result is:
$ ./gai -ap null 12000
getaddrinfo(NULL, "12000", {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG|AI_PASSIVE}) = 0:
family= 2, proto= 6 inet4: addr=0.0.0.0, port=12000
There you can see that I only have one IPv4 result.
This happens on new systems that use eglibc: debian-glibc.
Apparently, there is a bug that requires you to set at least one valid IPv6 address to one of your network interfaces (the loopback doesn't count).
After I did this:
$ sudo ip -6 addr add 2001:660:4701:1001::1 dev eth0
I have:
$ ./gai -ap null 12000
getaddrinfo(NULL, "12000", {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG|AI_PASSIVE}) = 0:
family= 2, proto= 6 inet4: addr=0.0.0.0, port=12000
family=10, proto= 6 inet6: addr=::, port=12000, flowinfo=0
I hope this can help someone.
Related
I posted my solution too. I hope this saves someone else a lot of time.
I have an EC2 instance running Ubuntu 20. DNS resolution never works, or fails a lot.
My file /etc/resolv.conf has
nameserver 127.0.0.53
The file is not a symlink, and I can certainly edit it to use nameserver 8.8.8.8 ,
But the file periodically gets overwritten and the 127.0.0.53 (or something similar) is back.
I just want dns to work!
See my solution below.
Get your nic's name from a config file.
cat /etc/netplan/50-cloud-init.yaml
On my system, amazon sets the nic name to ens5.
As root create new file: /etc/netplan/99-custom-dns.yaml
with the following content.
Replace ens5 with your nic's name.
network:
version: 2
ethernets:
ens5:
nameservers:
addresses: [8.8.8.8]
dhcp4-overrides:
use-dns: false
Reboot
sudo shutdown -r now
Verify. After the reboot you can try pinging something by name
ping yahoo.com
or you can view the output of:
systemd-resolve --status
Done
Here's a link to the Amazon help doc, though it misses the nontrivial detail about your nic's name:
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/
I have a process using https. I found its PID using ps and used the command lsof -Pan -p PID -i to get the port number it is running on.
I need iftop to see the data transfer. The filter I am using now is
iftop -f "port http 57787".
I don't think this is giving me the right output.
Can someone help me the right filter to use with iftop so that I know the traffic going through only this port?
I can see 2 problems here:
1/ Is that a typo? The correct option for filtering is -f (small "f"). -F (capital "F") option is for net/mask.
2/ Though not explicitly stated by iftop documentation, the syntax for filtering seems to be the pcap one from the few examples given (and using ldd I can see that yes, the iftop binary is linked with libpcap). So a filter with http is simply not valid. To see the doc for pcap filtering syntax, have a look at pcap-filter (7) - packet filter syntax man page. In your example, a filter such as "tcp port 57787" would be OK. pcap does not do layer 5 and above protocol dissection such as http (pcap filters are handled by BPF in the kernel, so above layer 4 you're on your own, because that's none of the kernel business).
All in all, these looks like iperf bugs. It should refuse your "-F" option, and even with "-f" instead exit with an error code because pcap will refuse the filter expression. No big deal, iftop is a modest program. See edit bellow.
EDIT:
I just checked iftop version 1.0pre4 source code, and there is no such obvious bug from a look at set_filter_code() and its caller packet_init() in iftop.c. It correctly exit with error, but...
Error 2, use the "-f" option, but your incorrect filter syntax:
jbm#sumo:~$ sudo iftop -f "port http 57787"
interface: eth0
IP address is: 192.168.1.67
MAC address is: 8c:89:a5:57:10:3c
set_filter_code: syntax error
That's OK.
Error 1, the "-F" instead of "-f", there is a problem:
jbm#sumo:~$ sudo iftop -F "port http 57787"
(everything seems more or less OK, but then quit the program)
Could not parse net/mask: port http 57787
interface: eth0
IP address is: 192.168.1.67
MAC address is: 8c:89:a5:57:10:3c
Oops! "Could not parse net/mask: port http 57787"! That's a bug: it should exit right away.
I'm trying to set up a pair of serial ports between my QEMU host (Debian Jessie x86_64) and guest (also Debian Jessie, but on ARM). Everything except the serial port part works.
I'm really new to QEMU so there might be a better way but I've tested the following flags when running QEMU:
-chardev tty,id=mytty,path=/dev/pts/2 (/dev/pts/2 & 3 are up with socat)
-chardev pty,id=mypty QEMU opens a PTY but when I try to read or write from host get permission denied.
In either case I can't find the ports in my guest. /dev/pts is empty and in /dev there are only tty and ttyAMA3. So, my problem is setting up communication in general and I'm especially curious on where the ports are on my guest.
I found a solution to my own question. First the device tree was incomplete so I needed to add 3 additional uart ports. That's the reason I could not find my ports in the guest.
Second, I needed to tell QEMU to use on of the ports as stdio: -append ... console=ttyAMA3 and -serial mon:stdio. Then I'm able to, with -serial pty, link QEMUs ttyAMA* to pts/* on the host.
I need to know how to connect to a beaglebone (or beagleboard) with SSH when I plug it into a new network with an ethernet cable like this:
$ ssh root#beaglebone.local
So far I've only been able to access it like this, if I know the IP address:
$ ssh root#<ip_address>
But I don't always know the IP address of the board on new networks so I'm hoping to access it with with a name like: beaglebone.local.
Right now when I try to do this I get this error:
"ssh: Could not resolve hostname beaglebone.local: nodename nor servname provided, or not known"
I checked the hostname and hosts files, and added "127.0.0.1 beaglebone" to the hosts on the beaglebone, but not sure what else I can do?
# cat /etc/hostname
beaglebone
# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
127.0.0.1 beaglebone
I had a similar issue running my beaglebone on Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.04.22.img.xz. In this distribution, "beaglebone.local" should appear on the network after the system boots.
About 50% of the time after reboot, "beaglebone.local" would not appear on the network (although the bone would be available by IP address). When this happened, "systemctl status avahi-daemon.service" showed that the avahi-daemon failed with "exit code 255". Interestingly, a subsequent "systemctl start avaihi-daemon.service" would always be successful and "beaglebone.local" would appear on the network.
Also "journalctl | grep avahi" returned a single message stating something like "Daemon already runnin gon PID NNN".
So, I "fixed" the problem by adding the line "ExecStartPre=/bin/rm -f /var/run/avahi-daemon/pid" to the [Service] section of /lib/systemd/system/avahi-daemon.service. With this addition, "beaglebone.local" now appears on the network 100% of reboots.
I say "fixed" (i.e., in quotes) because I have not been able to track down the root cause that is leaving around the stray avahi pid file(s) and thus don't have a true fix.
-- Frank
For 'beaglebone.local' to work, your host machine must recognize Zeroconf. The BeagleBone uses Avahi to tell other systems on the LAN that it is there and serving up applications and that it should be called a 'beaglebone'. If there are more than one, the second one is generally called 'beaglebone-2.local'.
I hate answering my own questions. The following hack will work until a better way emerges:
This shell script (where xxx.xxx.xxx is the first three numbers in your computer's IP) will find your beaglebone or beagleboard (that is plugged-into ethernet on a new network with DHCP) by looping through all the ip address on the subnet and attempting to login to each as root. If it finds one then try your password. If it doesn't work just hit enter until the loop starts again. If it doesn't find the board then something else is probably wrong.
for ip in $(seq 1 254); do ssh root#xxx.xxx.xxx.$ip -o ConnectTimeout=5; [ $? -eq 0 ] && echo "xxx.xxx.xxx.$ip UP" || : ; done
UPDATE 1
Today I plugged-in the beaglebone and saw Bonjour recognize that it joined the network. So I tried it and it worked. No idea why it decided to all of the sudden but it did. Strange, but true.
I had this issue quite often with Mac OS X 10.7. But unlike Frank Halasz "systemctl status avahi-daemon.service" shown no failure. And in fact the problem was on the Mac side. Restarting Bonjour with the following commands fixed the issue.
$ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
$ sudo launchctl load -F /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
i need to find the host name of a UNIX host whose IP is known with out login to that UNIX host
Use nslookup
nslookup 208.77.188.166
...
Non-authoritative answer:
166.188.77.208.in-addr.arpa name = www.example.com.
You can do a reverse DNS lookup with host, too. Just give it the IP address as an argument:
$ host 192.168.0.10
server10 has address 192.168.0.10
Another NS lookup utility that can be used for reversed lookup is dig with the -x option:
$ dig -x 72.51.34.34
; <<>> DiG 9.9.2-P1 <<>> -x 72.51.34.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12770
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1460
;; QUESTION SECTION:
;34.34.51.72.in-addr.arpa. IN PTR
;; ANSWER SECTION:
34.34.51.72.in-addr.arpa. 42652 IN PTR sb.lwn.net.
;; Query time: 4 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Fri Jan 25 21:23:40 2013
;; MSG SIZE rcvd: 77
or
$ dig -x 127.0.0.1
; <<>> DiG 9.9.2-P1 <<>> -x 127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11689
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 10 IN PTR localhost.
;; Query time: 2 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Fri Jan 25 21:23:49 2013
;; MSG SIZE rcvd: 63
Quoting from the dig manpage:
Reverse lookups -- mapping addresses to names -- are simplified by the
-x option. addr is an IPv4 address in dotted-decimal notation, or a colon-delimited IPv6 address. When this option is used, there is no
need to provide the name, class and type arguments. dig automatically
performs a lookup for a name like 11.12.13.10.in-addr.arpa and sets
the query type and class to PTR and IN respectively.
For Windows ping -a 10.10.10.10
For Windows, try:
NBTSTAT -A 10.100.3.104
or
ping -a 10.100.3.104
For Linux, try:
nmblookup -A 10.100.3.104
They are almost same.
It depends on the context. I think you're referring to the operating system's hostname (returned by hostname when you're logged in). This command is for internal names only, so to query for a machine's name requires different naming systems. There are multiple systems which use names to identify hosts including DNS, DHCP, LDAP (DN's), hostname, etc. and many systems use zeroconf to synchronize names between multiple naming systems. For this reason, results from hostname will sometimes match results from dig (see below) or other naming systems, but often times they will not match.
DNS is by far the most common and is used both on the internet (like google.com. A 216.58.218.142) and at home (mDNS/LLMNR), so here's how to perform a reverse DNS lookup: dig -x <address> (nslookup and host are simpler, provide less detail, and may even return different results; however, dig is not included in Windows).
Note that hostnames within a CDN will not resolve to the canonical domain name (e.g. "google.com"), but rather the hostname of the host IP you queried (e.g. "dfw25s08-in-f142.1e100.net"; interesting tidbit: 1e100 is 1 googol).
Also note that DNS hosts can have more than one name. This is common for hosts with more than one webserver (virtual hosting), although this is becoming less common thanks to the proliferation of virtualization technologies. These hosts have multiple PTR DNS records.
Finally, note that DNS host records can be overridden by the local machine via /etc/hosts. If you're not getting the hostname you expect, be sure you check this file.
DHCP hostnames are queried differently depending on which DHCP server software is used, because (as far as I know) the protocol does not define a method for querying; however, most servers provide some way of doing this (usually with a privileged account).
Note DHCP names are usually synchronized with DNS server(s), so it's common to see the same hostnames in a DHCP client least table and in the DNS server's A (or AAAA for IPv6) records. Again, this is usually done as part of zeroconf.
Also note that just because a DHCP lease exists for a client, doesn't mean it's still being used.
NetBIOS for TCP/IP (NBT) was used for decades to perform name resolution, but has since been replaced by LLMNR for name resolution (part of zeroconf on Windows). This legacy system can still be queried with the nbtstat (Windows) or nmblookup (Linux).
python -c "import socket;print(socket.gethostbyaddr('127.0.0.1'))"
if you just need the name, no additional info, add [0] at the end:
python -c "import socket;print(socket.gethostbyaddr('8.8.8.8'))[0]"
The other answers here are correct - use reverse DNS lookups.
If you want to do it via a scripting language (Python, Perl) you could use the gethostbyaddr API.
If you are specifically looking for a Windows machine, try below command:
nbtstat -a 10.228.42.57
You can use traceroute command as well.
http://linux.die.net/man/8/traceroute
just use the traceroute it will show you the routing path with host names (IPs resolved)
In most cases, traceroute command works fine. nslookup and host commands may fail.