Сетевая проблема - только одна машина не может получить доступ к веб-странице на другой машине
Мне наконец удалось зафиксировать это. Только для справки вот то, как я сделал это. Часть решения, которое я нашел здесь и это включает знание настроек, используемых для создания файловой системы (я был вполне уверен, я не изменил значения по умолчанию).
В основном я сначала должен был исправить таблицу разделов для отражения то, что я на самом деле имел там (я использовал testdisk для этого, но parted, cfdisk или fdisk должен хорошо работать также). Я просто удалил неправильные разделы и заменил единственным разделом типа ext4, покрывающим целый диск корректными значениями CHS.
Остальное главным образом из ссылки в запуске (считайте его для деталей), но в основном я работал mke2fs -n /dev/xxx найти положения для резервного копирования суперблоков. Затем используемый последнее резервное копирование, самое близкое в конец диска (только те в начале диска были перезаписаны с dd) выполнять fsck. Это генерировало много ошибок, но fsck имеет a -y опция (не то же как -a).
$ sudo e2fsck -a -b backup_block_number /dev/xxx
Я думал, что это не работало, потому что я не мог видеть файлы, но на самом деле они были все сохранены к lost+found каталог.
Таким образом в конце я действительно спасал большинство своих файлов при хранении их имен файлов и структуры каталогов. Надежда это может помочь другим в будущем.
A) Если исходящий пакет обнаруживается в tcpdump, который гарантирует, что пакет был на самом деле передан? (т.е. может там быть что-нибудь в нисходящем направлении точки касания, которая могла препятствовать тому, чтобы пакет был отправлен?)
Это означает, что пакет вытек из Вашего сетевого интерфейса, но не намного больше, чем это. Чтобы знать, достиг ли пакет, это - место назначения, необходимо было бы работать tcpdump на стороне получения.
Брандмауэр был бы вероятным преступником (или выход или поступление).
B) Если ожидаемый входящий пакет не обнаруживается в tcpdump, который гарантирует, что пакет никогда не получался? (т.е. может там быть что-нибудь в восходящем направлении точки касания, которая могла отбросить полученный пакет, прежде чем tcpdump будет видеть его?)
Да, если tcpdump наблюдает корректный интерфейс, и Вы видите, что никакой пакет не обнаруживается, который был подтвержден, как отправлено от внешней стороны, затем пакет, вероятно, никогда не отправлялся.
маршрут по умолчанию
Если бы маршруты по умолчанию не указаны правильно затем, пакеты не смогли бы добраться до сетевого устройства правильного шлюза, так, чтобы они могли быть поставлены устройству на той конкретной подсети.
Я удостоверился бы, что маршруты по умолчанию установлены правильно для Вашего Mac.
Пример
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 wlp3s0
192.168.1.0 0.0.0.0 255.255.255.0 U 9 0 0 wlp3s0
Примечание: Вышеупомянутое от моей системы Fedora 19, но Ваш Mac должен иметь что-то подобное. Удостоверьтесь, что маршрут по умолчанию установлен правильно для Вашей сети.
брандмауэр
Я также удостоверился бы, что нет мешающего брандмауэра. На устройстве Пи необходимо смочь отключиться, любой iptables связал сервис.
$ /etc/init.d/iptables stop