Нет маршрута между клиентами, пока не пропингуют от одного из них (а не от другого)

Question

3 предмета оборудования задействованы:

1. Маршрутизатор Netgear R7000 с DD-WRT v24-sp2 (15.08.14) kongac (24865M) - это двухдиапазонный.
2. Сервер печати на основе Raspberry Pi модели B, с Raspbian (Debian для Raspberry). Подключен к WiFi (2,4 ГГц) с USB-адаптером ALFA AWUS050H, принтером HP LaserJet 3055, подключенным через USB. Запуск CUPS 1.5.3 и SANE. Ничего, кроме этого, и простой установки Raspbian.
3. Рабочий стол под управлением Windows 8.1 с Asus PCE68U. Подключен к 5 ГГц WiFi на том же маршрутизаторе. На самом деле все мои другие устройства, такие как ноутбуки, телефоны и т.д., Ведут себя одинаково.

Проблема: я не могу связаться с сервером печати с рабочего стола, пока я не пропингую рабочий стол с сервера печати. Я делаю это, войдя в маршрутизатор через SSH, а затем через другой сеанс SSH на сервер печати. Когда я пингую рабочий стол, сначала теряются 4-5 пакетов, а затем он начинает работать. Это работает в течение нескольких минут после того, как я перестал пинговать. Затем он снова останавливается, и я больше не могу подключиться к серверу печати.

Страница CUPS не отвечает, пинг на сервер печати дает

Ответ от 192.168.xxx.xxx: узел назначения недоступен.

Иногда (в основном, когда я пытаюсь подключиться к странице CUPS или печатать во время пинга):

Истекло время запроса.

Маршрутизатор может быть проверен с любого компьютера, с рабочего стола и с сервера печати.

Dmesg на сервере получает много:

wlan0: ограничение мощности передачи до 30 (30 - 0) дБм, как объявлено [MAC-адрес маршрутизатора 2,4 ГГц]

но не регулярно. Иногда каждые 4 секунды, иногда тихо в течение 10 минут. Никаких других вещей в dmesg за этот период.

Вопрос: что может быть не так? Поскольку это выглядит довольно странно и не выглядит согласованным (иногда оно работает в течение получаса после пинга, а иногда останавливается через 10 секунд), я был бы признателен за любые советы о том, как глубже исследовать проблему.

Заметки:

Оба клиента, сервер печати и рабочий стол, получают сетевые настройки с одного и того же DHCP-сервера (статическая аренда за пределами диапазона dhcp). Это dnsmasq работает на сервере. Оба получают IP в одной подсети с маской 255.255.255.0.

Answer 1

Это обычно указывает на несоответствие маски подсети.

Чтобы ПК отправлял пакеты на принтер, ему необходим MAC-адрес принтера. Это делается с помощью запроса arp, у who has ip xx.xx.xx.xx

Отправляется на широковещательный адрес локальной сети. Если принтер имеет другую маску подсети, он может не увидеть запрос, если маска подсети ПК не содержит IP-адрес принтера, и поэтому ПК не видит ответ и поэтому не получает MAC-адрес принтера ,

Когда принтер отправляет эхо-запрос на ПК, он отправляет запрос arp, и, поскольку его маска подсети включает в себя ПК, ПК отвечает своим MAC. Однако в этот момент ПК добавляет MAC-адрес принтера в свою таблицу arp и может обмениваться данными с ПК.

Через некоторое время срок действия записи ARP на ПК истечет, и он не сможет установить связь с принтером до тех пор, пока не произойдет повторное поступление входящих сообщений.

Answer 2

Кажется, что у вас есть некоторая изоляция уровня 2, вызванная наличием нескольких носителей уровня 1: кадр ip-less, отправляемый в MAC ff: ff: ff: ff: ff: ff, такой как это делается в запросе ARP, не кажется чтобы охватить обе полосы WiFi.

Непонятно, как два хоста в конечном итоге обмениваются данными; я полагаю, что системы linux выполняют какое-то перенаправление, которое игнорирует окно windows. tcpdump -env на сервере печати может показать некоторые подсказки. arp -a во всех системах до того, как сработает связь, и во время может также оказаться полезной. Появляется ли запись для каждого хоста, на каждом хосте? Просто для полноты, можно статически настроить таблицу ARP как клад, но я не рекомендую проводить здесь много времени.

Кроме того, возможно, что выполнение команды ping 255.255.255.255 из системы Windows может привести к тому, что в промежутке промежуточный запуск может начаться, поскольку это будет происходить на уровне IP, который, кажется, работает, и echo-reply от принтера будет временно установлен какая бы запись ARP ни требовалась.

Мои общие предложения по устранению проблемы включают изучение и переключение опций мостового интерфейса на вашем маршрутизаторе, а также включение функции proxy arp , которая может служить для адекватной маскировки фрагментации сети, которая, как я подозреваю, существует между двумя полосами. proxy arp будет заставлять ваш маршрутизатор отвечать на запросы who-has для IP-адреса вашего принтера, поэтому ваш Windows- сервер знает, что он должен отправлять трафик принтера на маршрутизатор. Маршрутизатор должен соединить связь между двумя диапазонами независимо от ...