Задержка обнаружения UPnP

У меня установлен RaspBMC на Raspberry Pi, XBMC на ноутбуке с Windows и UPnPlay на моем устройстве Android. Raspberry Pi всегда включен и предназначен для работы в качестве сервера для системы.

Задействованные IP-адреса:

• 192.168.0.18: РПи

• 192.168.0.13: Ноутбук

• 192.168.0.1: Маршрутизатор

Когда я подключаю Android-устройство к WiFi и включаю UPnPlay или запускаю XBMC на ноутбуке, раньше была бы задержка в 5-10 минут, прежде чем Raspberry Pi появится в списке устройств. Однако в течение последних нескольких недель Pi вообще не появляется, если я не перезагружаю его во время работы других служб (XBMC или UPnPlay). Я могу подключиться к Pi по ssh и sftp и без проблем получить доступ к веб-интерфейсу RaspBMC с обоих устройств.

Возможно ли, что сообщения об обнаружении/объявлении сети UPnP каким-то образом теряются или блокируются? Как бы я расследовал это? Мои познания в сети ограничены переадресацией портов.

Я открыт для предложений альтернативных протоколов UPnP — это простой первый протокол, с которым я столкнулся, и он отлично работал в моей предыдущей настройке (XBMC на рабочем столе, отправляющий медиафайлы на Apple TV).

РЕДАКТИРОВАТЬ:

Некоторый анализ с помощью Wireshark на ноутбуке показывает, что ноутбук ведет себя так, как и ожидалось — отправляет пакеты M-SEARCH и NOTIFY через регулярные промежутки времени через SSDP на 239.255.255.250 (который, как я полагаю, является многоадресным адресом). Однако RPi не только не отвечает на эти пакеты одноадресными пакетами (как предполагает Википедия), но и не отправляет никаких пакетов SSDP, кроме как при загрузке.

Я очень новичок в Wireshark и анализе сети в целом, но я был бы очень признателен за любые рекомендации или советы, которые вы можете дать.

Фильтр Wireshark, который я использовал, был «(udp.dstport == 1900 или ip.addr == 192.168.0.18) и !(ip.src == 192.168.0.1)», где 192.168.0.18 — это адрес моего RPi. это правильно, но, как я уже сказал, я очень новичок в Wireshark - пожалуйста, поправьте меня, если я ошибся! В частности, я предположил, что многоадресный ответ RPi на M-SEARCH будет иметь ip.src = 192.168.0.18, но я не уверен в этом (предположительно это может быть 192.168.0.1 или 239.255.255.250).

РЕДАКТИРОВАТЬ 2:

Руководствуясь этим сообщением, я запустил /sbin/route -n и получил следующий результат.

pi@raspbmc:~$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Я не знаю, как это интерпретировать, но, судя по другим комментариям в связанной ветке, здесь отсутствует запись для многоадресной рассылки. Опять же, следуя этому совету из связанной ветки, я запустил sudo route add -net 239.0.0.0 netmask 255.0.0.0 eth0, добавил это в /etc/rc.local и перезапустил RPi, однако Pi по-прежнему не отображается в списке сетевых устройств для клиентов UPnP. Я также пытался использовать 239.255.255.250 в качестве многоадресного адреса (см. Редактировать 1 выше), что дало ошибку route: netmask doesn't match route address.

Опять же, руководствуясь связанным сообщением, я запустил установленный tshark и запустил sudo tshark -i et0 multicast | grep 192.168.0.18 (я добавил grep, так как видел большой трафик между другими устройствами в сети).

Вот результат.

RPi действительно отправляет кластер из 8_ пакетов, но очень редко (эта запись охватывает почти 20 минут, и отправляется только два кластера). Я полагаю, что пакеты ARP описаны здесь, подразумевая, что на некоторых устройствах отсутствуют MAC-адреса для других устройств в сети. Хотя это потенциально вызывает беспокойство (некоторые устройства запрашивают один и тот же адрес более одного раза — почему они «забывают» об этом?), возможно, более тревожными являются нерегулярность отправки этих пакетов и тот факт, что даже при их отправке , клиенты в сети по-прежнему не подхватывают RPi.

Итак, резюмируя:

• RPi отправляет NOTIFY пакетов, но очень редко. Есть ли способ контролировать это?

• Даже когда RPi отправляет NOTIFY пакетов (в обычном порядке, а не при загрузке), клиенты в сети не узнают о его существовании.

• Похоже, что RPi не отвечает на M-SEARCH пакетов, отправленных с других устройств.