Я нашел этот сценарий по http://vim.wikia.com. Не идеальное решение, а приемлемое, я думаю.
function! SetExecutableBit()
let fname = expand("%:p")
checktime
execute "au FileChangedShell " . fname . " :echo"
silent !chmod a+x %
checktime
execute "au! FileChangedShell " . fname
endfunction
command! Xbit call SetExecutableBit()
Можно теперь установить выполнить бит с командой :Xbit
. Весь кредит Max Ischenko по vim.wikia.com
socat
уничтожающая утилита. Помещенный где-нибудь в Ваши init сценарии:
socat -u -T1 UDP-LISTEN:1234,fork UDP-DATAGRAM:255.255.255.255:5678,broadcast
У некоторых пользователей есть проблемы с UDP - СЛУШАЮТ, так использование UDP-RECV кажется лучше (предупреждение: мог отправить широковещательные пакеты в бесконечном цикле):
socat -u UDP-RECV:1234 UDP-DATAGRAM:255.255.255.255:5678,broadcast
fork
позвольте сохранять прислушивающийся socat к следующим пакетам.
T1
предельная жизнь разветвленных подпроцессов к 1 секунде.
255.255.255.255
является более общим, чем 192.168.0.255. Разрешение Вас только к вставке копии, не думая о Вашей текущей структуре сети. Протест: это, вероятно, отправляет широковещательно переданные пакеты в каждый интерфейсы.
Как Вы, я заметил работы WOL с любым портом. Интересно, надежно ли это. Много документов только говорит о портах 0, 7 и 9.
Это позволяет использовать non-pivilegied порт, таким образом, можно работать socat
с пользователем nobody
.
Благодаря lgeorget
Hauke Laging
и Gregory MOUSSAT
участвовать к этому ответу.
Упал свободный добавить детали.
Я нашел этот вопрос на Serverfault.
Мне не удалось получить такой широковещательный трафик через мой маршрутизатор все же. Пакеты DNATted даже не прибыли в мой ВПЕРЕД цепочка. Возможно, существует некоторая странная опция ядра, которая запрещает это.
Но идея ARP интересна. Я предполагаю, что это должно сопровождаться правилом в ВЫВОДЕ, который запрещает пакеты этому адресу так, чтобы это могло быть достигнуто с переданным трафиком только.
Транслируемый трафик по определению предназначен для локальной машины. Это означает, что пакет получает DNAT'ed к 192.168.0.255, а затем ядро видит пакет и решает, что он предназначен самому маршрутизатору, так что вы увидите этот пакет в цепочке INPUT. Маршрутизатор (и любое другое устройство) подумает, что 192.168.0.255 пакеты предназначены для него самого, и не будет пересылать их дальше. Трансляционные пакеты не маршрутизируются/пересылаются по схеме.
Существует отличный обходной путь с упомянутым трюком с ARP. Вы "потеряете" один IP-адрес. В этом примере я использую фиктивный 192.168.0.254
-- не забудьте никогда не присваивать 192.168.0.254
никаким устройствам в вашей сети:
Создайте статическую ARP запись на LAN интерфейсе для IP адреса, который вы никогда не будете использовать для любой машины:
arp -i ethLAN --set 192.168.0.254 FF:FF:FF:FF:FF:FF:FFF
DNAT ваш UDP-трафик на WAN-интерфейсе к этому фиктивному IP-адресу:
iptables --table nat --append PREROUTING --in-interface ethWAN --protocol udp --destination-port 1234 --jump DNAT --to-destination 192.168.0.254
Это идеально подходит для пакетов WOL. Этот обходной путь также работает с продуктами, основанными на ядре Linux, такими как устройства Mikrotik и openwrt. Я использую этот трюк на устройствах Mikrotik, чтобы удаленно разбудить мою машину с помощью мобильного телефона.
Socat уже был указан в качестве ответа, однако указанный ответ не работал для меня на моей платформе, OpenWRT, с динамическим WAN-адресом.
Моя цель заключается в пересылке одноадресных UDP пакетов wake-on-lan с UDP порта 9 WAN интерфейса на подсеть, транслируемую на 192.168.20.255.
Я тоже пытался использовать iptables, но каждый раз, когда я добавляю правило, которое заканчивается на 255, правило превращается в mush с адресом назначения 0.0.0.0, когда я печатаю с:
iptables -t nat -L
Я считаю, что iptables не способен мультиплексировать трафик, как это требуется при преобразовании одноадресной рассылки в широковещательную.
Подделка записей arp не так уж плоха, потому что пакеты попадают ко всем в сегменте ethernet, но у нее есть следующие недостатки
Примечание: Это может быть сделано с помощью команды arp
или ip neigh
.
socat, как следует из предыдущего ответа, - это badass. Предыдущий ответ socat, однако, я столкнулся с несколькими проблемами с ним.
Я смог привязаться к 0.0.0.0 (все адреса) и избежать широковещательного шторма, добавив правило iptables для блокирования входящего широковещания, чтобы оно не возвращалось в socat со стороны LAN. Это правило, в дополнение к правилу iptables для приема трафика на UDP порт 9, и правилу iptables для его регистрации, мы получаем следующие три правила в дополнение к команде socat.
iptables -I input_wan_rule -p udp --dport 9 -j ACCEPT -m comment --comment "firewall entry to allow udp port 9 to socat"
iptables -I input_wan_rule -p udp --dport 9 -j LOG --log-prefix 'Received MAGIC PACKET on udp/9'
iptables -I input_lan_rule -p udp --dport 9 -d 192.168.20.0/24 -j DROP -m comment --comment "block broadcast from bouncing back to socat to avoid storm"
killall socat 2>/dev/null
socat -u -T1 UDP-LISTEN:9,bind=0.0.0.0,fork UDP-DATAGRAM:192.168.20.255:9,broadcast &
Для пользователей OpenWRT достаточно вставить это в /etc/firewall.user
и выполнить /etc/init.d/firewall restart
.
Поздравляем, теперь WoL должен работать в вашей сети из любой точки Интернета.
На самом деле netfilter не может осуществлять широковещательную рассылку, это делает механизм маршрутизации.
Но по умолчанию он отбрасывает все переадресованные широковещательные сообщения.
В недавнем ядре Linux (примерно версии 5.0 стало возможным пересылать направленную широковещательную рассылку UDP)
Необходимо изменить параметр bc_forwarding
для широковещательного сетевого интерфейса:
sudo sysctl -w net.ipv4.conf.eth1.bc_forwarding=1
(Обратите внимание :Кажется, опция net.ipv4.conf. все .bc _пересылка не работает)
Итак, теперь вам должно хватить ядра примерно 5.0 + iptables