Не подскажет ли уважаемый All, как сделать так, чтобы широковещательные пакеты форвардились во внешнюю сеть? Подключение к ней по PPPoE с "nat enable yes".
Проблема с Vypress Chat, пробовал даже vchatd, но в логах пишет, что, мол, can't assign address. Хотя, если ставить любой другой, кроме 255.255.255.255 (и 0.0.0.0 соответственно), то все нормально. Но ведь нужно именно на 255.255.255.255. Вообще, по какому принципу этот Vypress Chat работает? Сниффером смотрел - отсылает пакеты на 255.255.255.255:8167, но тот, кто отсылал, обратно ничего не получает...
Помогите, плз, уже который день над этой проблемой бьюсь :(
Это, судя по всему, какая то принципиальная проблема.
Правило:
ipfw add 10 fwd 192.168.1.1 udp from 192.168.1.0/24 to 255.255.255.255 8167
Хоть то, что правило работает, видно по ipfw -a l, но на порт 8167 машины 192.168.1.1 ничего не приходит :(
Ну хотя бы подскажите участок кода на C, с помощью которого можно отослать пакет на 255.255.255.255. Стандартными средствами не получается - все время выдается Can't assign address, хотя с любыми другими broadcast'ами работает (типа 192.168.1.255 и т.п.).
>Не подскажет ли уважаемый All, как сделать так, чтобы широковещательные пакеты форвардились
>во внешнюю сеть? Подключение к ней по PPPoE с "nat enable
>yes".
>Проблема с Vypress Chat, пробовал даже vchatd, но в логах пишет, что,
>мол, can't assign address. Хотя, если ставить любой другой, кроме 255.255.255.255
>(и 0.0.0.0 соответственно), то все нормально. Но ведь нужно именно на
>255.255.255.255. Вообще, по какому принципу этот Vypress Chat работает? Сниффером смотрел
>- отсылает пакеты на 255.255.255.255:8167, но тот, кто отсылал, обратно ничего
>не получает...
>Помогите, плз, уже который день над этой проблемой бьюсь :(Броадкаст будет задавлен на первом встречном маршрутиризаторе
У меня аналогичная проблемма только на Linux. Я не могу отослать пакет в лан на броудкаст, хотя никаких ошибок sendto не выдает.Но с твоей проблемой все посложней - броадкаст по ррр проходить не будет!
Если бы все было так просто :( Дело в том, что когда я подключаю кабель сразу к виндовой машине (на которой vypress chat), все замечательно работает и пакеты ничем не давятся и прекрасно ходят по ppp. Проблема в том, как бы их провести через nat на FreeBSD.
Сорри, ошибка в предыдущем постинге: пакеты, судя по всему, не по ppp ходят, а по сетевому интерфейсу. Есть tun0 и rl1. Ну так вот какая мысль: nat на все, что идет по tun0, делается. Но, как сказал MA, broadcast пакеты по ppp-интерфейсу ходить не могут. Значит, они ходят по rl1 (это, кстати, легко доказывается сниффером). Следовательно, надо на этот интерфейс nat ручками делать, а не простой строчкой nat enable yes :) Вот только как?..
Следовательно,
>надо на этот интерфейс nat ручками делать, а не простой строчкой
>nat enable yes :) Вот только как?..
nat taget адрес_rl1 может быть в ppp.conf ?
Делал:
#ipfw add 10 divert natd udp from any to 255.255.255.255 8167
#natd -a 192.168.1.1 -v -redirect_address 192.168.1.255 255.255.255.255Natd показывает, что пакеты перенапрявляются:
In [UDP] [UDP] a.b.c.d:4012 -> 255.255.255.255:8167 aliased to
[UDP] a.b.c.d:4012 -> 192.168.1.255:8167Но сниффером смотрел - ничего на 192.168.1.255 не приходит. А если вместо 192.168.1.255 подставить адрес любой реальной машины - то все работает.
Смежные постинги (к тому, что проблема интересная и так и не решенная):
https://www.opennet.ru/openforum/vsluhforumID1/13387.html
https://www.opennet.ru/openforum/vsluhforumID1/20375.html
//sysctl -a|grep bmcast//sysctl net.inet.icmp.bmcastecho=1
>//sysctl -a|grep bmcast//
>
>sysctl net.inet.icmp.bmcastecho=1Не все так просто, к сожалению :( ICMP тут ни при чем. Этот же параметр, если я не ошибаюсь, заставляет хост отвечать, если послан широковещательный ECHO REQUEST, т.е., например, ping 192.168.1.255.
Но за ответ все равно спасибо :)
>>//sysctl -a|grep bmcast//
>>
>>sysctl net.inet.icmp.bmcastecho=1
>
>Не все так просто, к сожалению :( ICMP тут ни при чем.
>Этот же параметр, если я не ошибаюсь, заставляет хост отвечать, если
>послан широковещательный ECHO REQUEST, т.е., например, ping 192.168.1.255.
>
>Но за ответ все равно спасибо :)Вот что написано...
Why is my ipfw ``fwd'' rule to redirect a service to another machine not working?
Possibly because you want to do network address translation (NAT) and not just forward packets. A ``fwd'' rule does exactly what it says; it forwards packets. It does not actually change the data inside the packet. Say we have a rule like:01000 fwd 10.0.0.1 from any to foo 21
When a packet with a destination address of foo arrives at the machine with this rule, the packet is forwarded to 10.0.0.1, but it still has the destination address of foo! The destination address of the packet is not changed to 10.0.0.1. Most machines would probably drop a packet that they receive with a destination address that is not their own. Therefore, using a ``fwd'' rule does not often work the way the user expects. This behavior is a feature and not a bug.
See the FAQ about redirecting services, the natd(8) manual, or one of the several port redirecting utilities in the ports collection for a correct way to do this