Многоадресно передайте UDP, не работающий
Владение и права доступа в основном сотрудничают. Ownership говорит систему, кто может получить доступ к файлу, в полномочиях файла говорится как.
Владение разделяет доступ на три группы: пользователь (отдельный пользователь, владеющий файлом), группа (пользователей), другие (остальная часть мира).
Полномочия: r - чтение позволяется, w - запись позволяется, x - выполнение позволяется
Для каталогов значение немного отличается: x позволяет Вам вводить каталог, в то время как r список его содержания (и w позволяет Вам обновить его) - который означает, что, если Вы знаете точное имя файла, Вы не должны читать полномочия на каталоге, это находится в, x достаточно. Вам нужно r на файле все же.
Затем существует триплет на один дополнительный бит: setuid, setgid, липкий. Первые два заставляют (на исполняемом файле) программу быть выполненной как пользователь/группа, владеющий файлом (в зависимости от какого из двух битов установлены). Липкий бит является зависящим от реализации. Для исполняемых файлов это раньше означало, что код программы должен кэшироваться в подкачке для ускорения загрузки его в следующий раз. Для каталога это предотвращает непривилегированных пользователей, удаляющих файл, если они не владеют им, даже если они имели права сделать так иначе - это - то, почему это обычно устанавливается на мировых записываемых каталогах как /tmp.
В дополнение к этому много файловых систем поддерживают дополнительные списки управления доступом (ACL), которые позволяют более прекрасное гранулярное управление доступом. Они доступны с getfacl/setfacl вместо с chmod.
Как примечание стороны, подобная система разрешения обычно реализуется для памяти (RAM) с гранулярностью страницы. Основная цель состоит в том, чтобы придерживаться принципа "W^X": или можно записать в память, или можно выполнить ее, но не оба одновременно. В то время как обычно хорошая идея, это не работает на интерпретируемый своевременный скомпилированный код - например, Java, потому что интерпретатор должен компилировать/оптимизировать сгенерированный код (т.е. записать страницу) и затем выполнить его, часто инкрементно (и изменение полномочий, каждый раз не имел бы большого смысла).
Я понимаю, что ваш хост, 192.168.2.7 посылает многоадресный пакет группе 239.255.250.250 на порт 9131
ПРИМЕЧАНИЕ: Я предполагаю, что серверы слушают порт 9131. вы не предоставили никакой информации об этом.
Из вывода ifconfig я вижу, что MULTICAST включен, и tcpdump подтверждает это.
Сначала убедитесь, что хост, на котором работают серверы (тот, который получает многоадресный пакет), присоединился к многоадресной группе.
На каждом хосте сервера введите :
netstat -gn
Если вы видите свой многоадресный адрес, то он присоединился к группе. Если нет, то либо что-то не так с вашей серверной программой, либо, возможно, с настройками ядра.
Если сервер присоединился к группе, но вы не видите ни одного входящего пакета от клиента, проверьте на маршрутизаторе, включен ли у вас igmp (маршрутизатор должен поддерживать igmp)
Например, на маршрутизаторе cisco
enable
conf t
ip multicast-routing
For each interface involved.
int <NIC>
ip pim sparse-dense-mode
Если igmp включен на маршрутизаторе, поищите функции отладки для отслеживания пакетов.
На стороне сервера запустите захват пакетов:
tcpdump -i <NIC> host 239.255.250.250
Если вы не видите никаких пакетов, значит, многоадресные пакеты не пересылаются (предполагается, что
Затем на клиенте отправьте многоадресный пакет (используйте скрипт по ссылке ниже для устранения неполадок)
ПРИМЕЧАНИЕ: UDP пакет кажется неправильно сформированным, поэтому не уверены, что серверы смогут его прочитать. Вы можете использовать скрипт по ссылке ниже, чтобы проверить, отображается ли сообщение в tcpdump как ошибочное или нет (в моем случае это не так)
Пример кода python с использованием многоадресной рассылки :
https://stackoverflow.com/questions/603852/multicast-in-python
ПРИМЕЧАНИЕ: Я использовал этот скрипт на debian raspi (не raspbian и сервер получал пакеты через маршрутизатор - как установлено выше - нормально)
Руководство по Linux: http://stlinux. com/howto/network/short-guide
Я столкнулся с аналогичной проблемой, в которой попадаются пакеты, и я мог видеть их с TCPdump , но программа не может принимать данные.
Проблема в этом случае заключалась в том, что я использовал iptables , чтобы разрешить трафик от моей локальной подсети 192.168.0.0/24 , но, конечно, многоадресных приходит из 224,0. 0,0 / 4 вместо этого. Вместо того, чтобы открыть всю подсеть (может также иметь брандмауэр), я просто разрешил трафик от всех хостов на конкретном порту UDP, который я использовал для многоадресной точки, и это исправило проблему.
Я заметил, что это также может быть проблема оборудования и / или драйвера. Я без проблем использовал многоадресный UDP (передача и получение) на моем raspberryPI - с программами на C, Java и / или Python.
Однако я только что узнал, что прием многоадресной рассылки UDP НЕ РАБОТАЕТ с симпатичным маленьким USB-адаптером Wi-Fi от EDIMAX - отправка UDP (многоадресная рассылка) работает, а также получение собственных (локальных) сообщений.
сведения о USB-накопителях от lsusb:
Прием многоадресной рассылки UDP не работает: ID 7392: 7811 Edimax Technology Co., Ltd EW-7811Un Беспроводной адаптер 802.11n [Realtek RTL8188CUS]
Прием многоадресной рассылки UDP работает штраф: ID 148f: 3070 Ralink Technology, Corp. RT2870 / RT3070 Беспроводной адаптер
У нас была аналогичная проблема, когда группа многоадресной рассылки была успешно присоединена, но сообщения не были получены.
Мы проверили настройки igmp на роутере,что казалось бы в порядке вещей.
В конце концов мы перешли с многоадресного IPv6-адреса на IPv4, и это решило проблему для этой конкретной системы.