Установить свойство WM_WINDOW_ROLE для произвольного окна?

[edit] My other devices can ping my PC, but my PC can not ping any other device including the router to which my PC is attached directly.

Я бы проверил наличие конфликтующего IP-адреса на другом устройстве.

(Хотя я не уверен, что ваши результаты pingсогласуются с этим. Это не совсем соответствует моим представлениям об ARP, и, к сожалению, я не нашел похожей комбинации в результатах поиска Google. Возможно, есть дополнительная проблема или другая проблема. Но это неплохо проверить, и это может помочь вам найти какую-то подсказку ).

Найдите на своем ПК MAC-адрес («аппаратный адрес» ). Если вы запустите ip link show dev eth1, MAC-адресом будет значение, показанное после link/ether.

На одном из других устройств внимательно проверьте, какой MAC-адрес закеширован для вашего IP-адреса, 192.168.0.146. Если другое устройство работает под управлением Linux, вы можете проверить кэш ARP с помощью ip -4 neigh. Если другое устройство работает под управлением Windows, вы можете проверить кэш ARP, используяarp -a(в командной строке Windows). Если он показывает другой MAC-адрес для вашего IP-адреса 192.168.0.146, то на самом деле вы пинговали другое устройство, а не свой ПК :-).

---

Предыдущая версия:

Что может быть вероятной причиной того, что не удается пропинговать?

AfroJoe: so many reasons

С технической точки зрения, pingсообщение «Назначенный хост недоступен» является довольно специфичным сообщением об ошибке! Ваш вывод почти наверняка означает, что разрешение ARP не работает. На 192.168.0.146. Похоже, это был тот же компьютер, на котором вы запускали ping, и вы подтвердили это в более позднем редактировании. В этом случае вот как подтвердить проблему с ARP:

$ ping 172.16.8.2
PING 172.16.8.2 (172.16.8.2) 56(84) bytes of data.
From 172.16.8.205 icmp_seq=1 Destination Host Unreachable
From 172.16.8.205 icmp_seq=2 Destination Host Unreachable
From 172.16.8.205 icmp_seq=3 Destination Host Unreachable
^C
--- 172.16.8.2 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms
pipe 4

$ ip -4 neigh
172.16.8.1 dev wlp2s0 lladdr 74:44:01:86:42:d6 REACHABLE
172.16.8.2 dev wlp2s0  INCOMPLETE

Успешное разрешение ARP включает такой обмен:

$ sudo tcpdump -n -i wlp2s0 arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
...
13:43:49.469349 ARP, Request who-has 172.16.8.1 tell 172.16.8.205, length 28
13:43:49.470046 ARP, Reply 172.16.8.1 is-at 74:44:01:86:42:d6, length 28
13:43:49.852608 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 21, length 64
13:43:49.854600 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 21, length 64
13:43:50.853879 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 22, length 64
13:43:50.855867 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 22, length 64
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel

(наблюдается при запуске ping и принудительном обновлении ARP с помощьюip neigh flush dev wlp2s0).

Примечание :эта интерпретация в основном применима только к ping. Он не применяется, когда вы получаете сообщение «Host Unreachable» от «нормального» приложения TCP/IP, такого как sshили curl, потому что это также может означать, что вы получили ответ об ошибке ICMP, такой как «Административно запрещено» (из брандмауэра ). Однако pingполучает и декодирует весь ответ ICMP. Таким образом, pingсообщит вам, что ошибка была конкретно «Административно запрещена», а не , а просто «Хост недоступен».

Кроме того, эти вопросы и ответы касаются IPv4. Я не проверял, как его можно адаптировать для IPv6.

Почему происходит сбой разрешения ARP?

AfroJoe: so many reasons

У меня есть еще одно секретное знание. Если ваша клиентская система Ubuntu не была кем-то преднамеренно настроена, адрес 192.168.0.146был назначен посредством обмена DHCP-пакетами. Обычно в этом обмене участвует маршрутизатор, хотя в других случаях он может включать только Windows Server или сервер другого типа. В этом случае, когда маршрутизатор является DHCP-сервером или ретранслятором, ваша система уже могла обмениваться некоторыми пакетами с маршрутизатором .

Вы можете проверить повторно -инициирование обмена DHCP, разорвав и повторно -установив соединение.[ *] Конечно, если проблема продолжает возникать снова "случайно", это не решает основную проблему. проблема,и вы можете захотеть исследовать соединение, пока оно все еще разорвано.

([ *] Apple написала оптимизацию, которая может выполнять обмен DHCPпосле обмена определенными пакетами ARP . Возможно, с этим есть новые причуды, но я еще не видел, чтобы это использовалось в Linux.)

Эта ошибка часто возникает при подключении с использованием DHCP и WiFi, когда в какой-то момент теряется сигнал беспроводной сети. (И вы заметили это до того, как беспроводный уровень полностью отказал... Я не знаю, почему я видел это так много раз, возможно, я наблюдал глючные или плохо написанные системы ). Но eth1 не является WiFi-соединением.

Я считаю, что DHCP для IPv4 работает без запроса ARP. По крайней мере, при первоначальном обмене DHCP.

Остальные возможности

Судя по фактам в первоначальной версии вашего вопроса, я изо всех сил пытался придумать какой-либо отдельный сценарий, который особенно распространен. (Включая мои неявные предположения. Маловероятно, что кто-то опубликует этот вопрос без попытки подключить свой компьютер к работающему маршрутизатору ).

• В сети, к которой вы подключены, нет устройства с адресом 192.168.0.1. Если это то, что дало вам DHCP-адрес, то он был удален из сети. Отключился или просто умер.
• Вы настроили eth1 вручную И один из
  • вы не используете NetworkManager в Ubuntu Desktop и
    • на самом деле у вас не обнаружено соединение Ethernet (проверьтеethtool).
    • Или у вас обнаружено соединение Ethernet, но коммутатор требует ввести пароль или другую аутентификацию с использованием 802.1X .
    • Или у вас обнаружено соединение Ethernet, но вам необходимо зарегистрировать MAC-адрес вашего компьютера у сетевого администратора.
  • у вас есть кабель, который работает достаточно хорошо, чтобы обнаружить связь,но недостаточно для надежной передачи пакетов данных.