|
Aetzer99
Anmeldungsdatum:
15. Januar 2013
Beiträge: 34
Wohnort: Wertingen
|
Hallo Leute, hoffe ihr könnt mir mit meinem Problem helfen. Ich habe neulich von Ubuntu 16.04 auf 18.04 upgegradet. Seitdem habe ich das Problem das ich im Terminal meine lokalen Hostnamen nicht mehr anpingen kann. Ping auf IP-Adresse funktioniert aber. | aetzer99@Monster1:~$ ping media1
ping: media1: Der Name oder der Dienst ist nicht bekannt
aetzer99@Monster1:~$ ping 192.168.178.9
PING 192.168.178.9 (192.168.178.9) 56(84) bytes of data.
64 bytes from 192.168.178.9: icmp_seq=1 ttl=64 time=0.324 ms
^C
--- 192.168.178.9 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.324/0.324/0.324/0.000 ms
aetzer99@Monster1:~$
|
System:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34 | aetzer99@Monster1:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic
aetzer99@Monster1:~$ uname -a
Linux Monster1 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
aetzer99@Monster1:~$ lspci | grep Ethernet
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V
aetzer99@Monster1:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.178.2 netmask 255.255.255.0 broadcast 192.168.178.255
inet6 fe80::f387:7310:f285:bcdd prefixlen 64 scopeid 0x20<link>
inet6 2001:a61:6013:f701:1bfc:6b27:487c:666 prefixlen 64 scopeid 0x0<global>
inet6 2001:a61:6013:f701:41ca:e726:9f1a:c15e prefixlen 64 scopeid 0x0<global>
ether f0:79:59:60:a0:44 txqueuelen 1000 (Ethernet)
RX packets 26976 bytes 20729111 (20.7 MB)
RX errors 0 dropped 5846 overruns 0 frame 0
TX packets 12554 bytes 2239086 (2.2 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf7100000-f7120000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Lokale Schleife)
RX packets 1326 bytes 109032 (109.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1326 bytes 109032 (109.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
Es wurde eine feste IP mittels Grafischer Oberfläche vergeben. Bild im Anhang. Vielen Dank schon mal im voraus.
- Bilder
|
|
Bournless
Anmeldungsdatum:
4. Mai 2019
Beiträge: 915
|
Lass mich raten - Du hast eine Fritz!Box? Falls ja, fehlt einfach die Angabe zu DNS-Search/zur Suchdomäne. Diese lässt sich unter 18.04 nicht mehr per GUI eintragen. Nimm stattdessen die alte Version nm-connection-editor und trage unter den IPv4-Einstellungen im Feld "Zusätzliche-Suchdomänen": fritz.box ein Abschließend die Netzwerkverbindung deaktivieren und wieder aktivieren oder alternativ das System rebooten.
|
|
Aetzer99
(Themenstarter)
Anmeldungsdatum:
15. Januar 2013
Beiträge: 34
Wohnort: Wertingen
|
Das war's. Ja habe eine Fritz!Box. Vielen Dank PS: Warum musste ich das unter Ubuntu 16.04 nicht eintragen?
|
|
Bournless
Anmeldungsdatum:
4. Mai 2019
Beiträge: 915
|
Warum musste ich das unter Ubuntu 16.04 nicht eintragen?
Höchstwahrscheinlich, weil Du erst nach dem Upgrade auf die Version 18.04 von Automatisch(DHCP) auf manuelle IP umgestellt hast. Grundsätzlich muss auch unter der Version 16.04 - bei der manuellen Vergabe einer IP-Adresse- eine zusätzliche Suchdomäne angegeben werden, wenn eine Fritz!Box mit im Spiel ist.
|
|
Aetzer99
(Themenstarter)
Anmeldungsdatum:
15. Januar 2013
Beiträge: 34
Wohnort: Wertingen
|
Nein, betreibe diesen Rechner seit Ubuntu 12.04 mit den gleichen Einstellungen. Habe dort nie was geändert. Hat nach jedem Distributionsupgrade eigentlich immer gepasst. Deswegen ja die Frage.
|
|
Bournless
Anmeldungsdatum:
4. Mai 2019
Beiträge: 915
|
Da ich mich erst seit der Version 14.04 mit Ubuntu beschäftige und diese mehrfachen Upgrades (12->14->16->18) nie durchführen musste, ziehe ich mich ab jetzt zurück. Vielleicht kann ja sonst jemand anderes deine letzte Frage beantworten!? Gruß
Bournless PS. Falls sich in den nächsten Tagen keiner mehr meldet, markiere diesen Thread bitte trotzdem als gelöst.
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14336
|
Aetzer99 schrieb: Das war's. Ja habe eine Fritz!Box.
Wie sind jetzt die Ausgaben von:
host -t A media1
cat /etc/resolv.conf
cat /etc/nsswitch.conf
? BTW: ping macht die dns-Anfrage anders als die dns-Tools (z. B. host): ping:
127.0.0.1.59781 > 127.0.0.1.53: [bad udp cksum 0xfe3e -> 0x92ac!] 63975+ [1au] A? ######. ar: . OPT UDPsize=1024 (35)
host
127.0.0.1.40805 > 127.0.0.1.53: [bad udp cksum 0xfe33 -> 0x3012!] 53181+ A? ######. (24)
ping ist erfolgreich und host ist nicht erfolgreich.
|
|
Aetzer99
(Themenstarter)
Anmeldungsdatum:
15. Januar 2013
Beiträge: 34
Wohnort: Wertingen
|
| aetzer99@Monster1:~$ host -t A media1
media1.fritz.box has address 192.168.178.9
|
| aetzer99@Monster1:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
search fritz.box
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20 | aetzer99@Monster1:~$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat systemd
group: compat systemd
shadow: compat
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
|
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14336
|
Aetzer99 schrieb: aetzer99@Monster1:~$ host -t A media1
media1.fritz.box has address 192.168.178.9 aetzer99@Monster1:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
search fritz.box
Dann wird mit 18.04, host die dns-Anfrage evtl. anders machen, als mit 14.04 (oder 12.04):
sudo tcpdump -c 50 -vvveni any dst port 53
|
|
Aetzer99
(Themenstarter)
Anmeldungsdatum:
15. Januar 2013
Beiträge: 34
Wohnort: Wertingen
|
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14336
|
Aetzer99 schrieb: Soll heißen ?
Naja, wenn Du es weiter verfolgen willst, dann die Ausgabe von tcpdump, nach der Benutzung von host (im W/LAN) hier posten.
|
|
Aetzer99
(Themenstarter)
Anmeldungsdatum:
15. Januar 2013
Beiträge: 34
Wohnort: Wertingen
|
Ah ja. Alles klar. Hier die Ausgabe: | aetzer99@CF-52:~$ sudo tcpdump -c 50 -vvveni any dst port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:04:08.102000 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 7228, offset 0, flags [none], proto UDP (17), length 62)
127.0.0.1.44958 > 127.0.1.1.53: [bad udp cksum 0xff3d -> 0x001c!] 9491+ A? media1.fritz.box. (34)
15:04:08.102129 Out 58:94:6b:68:a9:c0 ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 6633, offset 0, flags [DF], proto UDP (17), length 62)
192.168.178.215.45024 > 192.168.178.1.53: [udp sum ok] 65035+ A? media1.fritz.box. (34)
15:04:08.102195 Out 58:94:6b:68:a9:c0 ethertype IPv6 (0x86dd), length 98: (flowlabel 0x8bc77, hlim 255, next-header UDP (17) payload length: 42) 2001:a61:606b:a201:14f2:4e8d:3243:f8fd.37217 > fd00::a96:d7ff:fe8a:2889.53: [udp sum ok] 65035+ A? media1.fritz.box. (34)
^C
3 packets captured
4 packets received by filter
0 packets dropped by kernel
|
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14336
|
Aetzer99 schrieb: aetzer99@CF-52:~$ sudo tcpdump -c 50 -vvveni any dst port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:04:08.102000 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 7228, offset 0, flags [none], proto UDP (17), length 62)
127.0.0.1.44958 > 127.0.1.1.53: [bad udp cksum 0xff3d -> 0x001c!] 9491+ A? media1.fritz.box. (34)
OK, dann liegt es schon am host. Denn obwohl Du:
host -t A media1
ausgeführt hast, wird in der dns-Anfrage von host, das "media1.fritz.box" benutzt.
Warum geht die dns-Anfrage an die IP-Adresse 127.0.1.1:53, wenn diese gar nicht in der resolv.conf eingetragen ist?
Wie sind die Ausgaben von:
sudo netstat -tulpena | grep -i 53
? Teste mal, ob das mit einer dns-Anfrage, die von der FritzBox nicht aufgelöst werden kann, auch so ist. Z. B.:
host -t A xynhzfbjfh
Versuch mal auch mit geänderter Zeile in der nsswitch.conf:
#hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
hosts: files dns
|
|
Aetzer99
(Themenstarter)
Anmeldungsdatum:
15. Januar 2013
Beiträge: 34
Wohnort: Wertingen
|
| aetzer99@Monster1:~$ sudo netstat -tulpena | grep -i 53
[sudo] Passwort für aetzer99:
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 122 21319 922/systemd-resolve
tcp 0 0 192.168.178.2:53812 74.125.133.16:993 VERBUNDEN 1000 65301 8209/thunderbird
tcp 0 0 192.168.178.2:53794 93.184.220.29:80 TIME_WAIT 0 0 -
tcp6 0 0 2001:a61:606b:a20:34026 2a00:1450:400c:c0c::993 VERBUNDEN 1000 65369 8209/thunderbird
tcp6 0 0 2001:a61:606b:a20:34024 2a00:1450:400c:c0c::993 VERBUNDEN 1000 65368 8209/thunderbird
tcp6 0 0 2001:a61:606b:a20:34018 2a00:1450:400c:c0c::993 VERBUNDEN 1000 65357 8209/thunderbird
udp 0 0 0.0.0.0:5353 0.0.0.0:* 111 27714 1158/avahi-daemon:
udp 0 0 127.0.0.53:53 0.0.0.0:* 122 21318 922/systemd-resolve
udp6 0 0 :::5353 :::* 111 27715 1158/avahi-daemon:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | aetzer99@Monster1:~$ sudo tcpdump -c 50 -vvveni any dst port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:25:47.645218 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 64, id 40478, offset 0, flags [none], proto UDP (17), length 66)
127.0.0.1.39916 > 127.0.0.53.53: [bad udp cksum 0xfe75 -> 0x7007!] 43686+ A? xynhzfbjfh.fritz.box. (38)
20:25:47.645349 Out f0:79:59:60:a0:44 ethertype IPv4 (0x0800), length 93: (tos 0x0, ttl 64, id 60517, offset 0, flags [DF], proto UDP (17), length 77)
192.168.178.2.47698 > 192.168.178.1.53: [bad udp cksum 0xe59f -> 0xd680!] 5519+ [1au] A? xynhzfbjfh.fritz.box. ar: . OPT UDPsize=512 (49)
20:25:47.646179 Out f0:79:59:60:a0:44 ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 64, id 60518, offset 0, flags [DF], proto UDP (17), length 66)
192.168.178.2.47698 > 192.168.178.1.53: [bad udp cksum 0xe594 -> 0xff99!] 5519+ A? xynhzfbjfh.fritz.box. (38)
20:25:47.646960 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 72: (tos 0x0, ttl 64, id 40479, offset 0, flags [none], proto UDP (17), length 56)
127.0.0.1.39024 > 127.0.0.53.53: [bad udp cksum 0xfe6b -> 0x98d8!] 43460+ A? xynhzfbjfh. (28)
^C
4 packets captured
6 packets received by filter
0 packets dropped by kernel
|
Mit geänderter nsswitch.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | aetzer99@Monster1:~$ sudo tcpdump -c 50 -vvveni any dst port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:24:01.532852 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 64, id 33239, offset 0, flags [none], proto UDP (17), length 66)
127.0.0.1.55868 > 127.0.0.53.53: [bad udp cksum 0xfe75 -> 0x42c0!] 39325+ A? xynhzfbjfh.fritz.box. (38)
20:24:01.533004 Out f0:79:59:60:a0:44 ethertype IPv4 (0x0800), length 93: (tos 0x0, ttl 64, id 41289, offset 0, flags [DF], proto UDP (17), length 77)
192.168.178.2.50647 > 192.168.178.1.53: [bad udp cksum 0xe59f -> 0xdab0!] 1498+ [1au] A? xynhzfbjfh.fritz.box. ar: . OPT UDPsize=512 (49)
20:24:01.533778 Out f0:79:59:60:a0:44 ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 64, id 41290, offset 0, flags [DF], proto UDP (17), length 66)
192.168.178.2.50647 > 192.168.178.1.53: [bad udp cksum 0xe594 -> 0x03ca!] 1498+ A? xynhzfbjfh.fritz.box. (38)
20:24:01.534581 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 72: (tos 0x0, ttl 64, id 33240, offset 0, flags [none], proto UDP (17), length 56)
127.0.0.1.49291 > 127.0.0.53.53: [bad udp cksum 0xfe6b -> 0xe002!] 14975+ A? xynhzfbjfh. (28)
^C
4 packets captured
6 packets received by filter
0 packets dropped by kernel
|
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14336
|
Aetzer99 schrieb: aetzer99@Monster1:~$ sudo tcpdump -c 50 -vvveni any dst port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:25:47.645218 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 64, id 40478, offset 0, flags [none], proto UDP (17), length 66)
127.0.0.1.39916 > 127.0.0.53.53: [bad udp cksum 0xfe75 -> 0x7007!] 43686+ A? xynhzfbjfh.fritz.box. (38)
20:25:47.645349 Out f0:79:59:60:a0:44 ethertype IPv4 (0x0800), length 93: (tos 0x0, ttl 64, id 60517, offset 0, flags [DF], proto UDP (17), length 77)
OK, das ist der Beweis, dass host in 18.04 die dns-Anfrage anders macht. Es wird immer auch die search domain aus der resolv.conf benutzt.
|
