VM
~ # find / -name 'radvd*'
/var/radvd
/var/run/radvd.pid
/var/lock/radvd.lock
/usr/sbin/radvd
~ #
Size: a a a
2018 June 09
AO
А в режим моста его перевести не вариант?
AO
чтоб не мучаться с их прошивкой
VM
(в /var/radvd пусто, а процесса, указанного в пидфайле не существует)
VM
А в режим моста его перевести не вариант?
да что-то, вот, кроме падучего radvd у них вроде всё норм
VM
даже, вон, гостевые вайфайные точки
VM
я на мыльнице под owrt так и не осилил их настроить, например :)
AO
да что-то, вот, кроме падучего radvd у них вроде всё норм
А ты попробуй 1.1.1.1 трейсануть ещё, увидишь сюрприз -)
VM
HOST: tp Loss% Snt Last Avg Best Wrst StDev
1.|— 1dot1dot1dot1.cloudflare-dns.com 0.0% 1 1.5 1.5 1.5 1.5 0.0
1.|— 1dot1dot1dot1.cloudflare-dns.com 0.0% 1 1.5 1.5 1.5 1.5 0.0
VM
вангую, спуфят :)
AO
чотко, да?
AO
неа
AO
На МГТСном роутере столкнулся с тем, что запросы к 1.1.1.1 (CloudFlare DNS) почему-то замыкаются на себя. Зашёл на него под рутом, сделал ip addr и увидел такую запись:
Ввод ip addr del 1.1.1.1/32 dev multicast конечно решил проблему, но вопрос — зачем было такое делать?..
20: multicast: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff //оригинальный mac-адрес скрыт
inet 1.1.1.1/32 brd 1.255.255.255 scope global multicast
inet6 fe80::7a94:b4ff:fed9:88b3/64 scope link
valid_lft forever preferred_lft forever
Ввод ip addr del 1.1.1.1/32 dev multicast конечно решил проблему, но вопрос — зачем было такое делать?..
VM
VM
На МГТСном роутере столкнулся с тем, что запросы к 1.1.1.1 (CloudFlare DNS) почему-то замыкаются на себя. Зашёл на него под рутом, сделал ip addr и увидел такую запись:
Ввод ip addr del 1.1.1.1/32 dev multicast конечно решил проблему, но вопрос — зачем было такое делать?..
20: multicast: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff //оригинальный mac-адрес скрыт
inet 1.1.1.1/32 brd 1.255.255.255 scope global multicast
inet6 fe80::7a94:b4ff:fed9:88b3/64 scope link
valid_lft forever preferred_lft forever
Ввод ip addr del 1.1.1.1/32 dev multicast конечно решил проблему, но вопрос — зачем было такое делать?..
хм
VM
и правда что
VM
у них там прям зоопарк разных IP: и 10ки, и 192.168, и, вон, 1.1.1.1
T
На МГТСном роутере столкнулся с тем, что запросы к 1.1.1.1 (CloudFlare DNS) почему-то замыкаются на себя. Зашёл на него под рутом, сделал ip addr и увидел такую запись:
Ввод ip addr del 1.1.1.1/32 dev multicast конечно решил проблему, но вопрос — зачем было такое делать?..
20: multicast: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff //оригинальный mac-адрес скрыт
inet 1.1.1.1/32 brd 1.255.255.255 scope global multicast
inet6 fe80::7a94:b4ff:fed9:88b3/64 scope link
valid_lft forever preferred_lft forever
Ввод ip addr del 1.1.1.1/32 dev multicast конечно решил проблему, но вопрос — зачем было такое делать?..
у AT&T похожее было тоже на модемам, да и много где 1.1.1.1 по дефалту (в вафай контролерах цисках) например
https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/
https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/
AO
Tony
у AT&T похожее было тоже на модемам, да и много где 1.1.1.1 по дефалту (в вафай контролерах цисках) например
https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/
https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/
Гениально...а где-то в стандартах написано, что 1.1.1.1 они имеют право использовать под "внутренние" нужды?
T
Гениально...а где-то в стандартах написано, что 1.1.1.1 они имеют право использовать под "внутренние" нужды?
нет конечно, просто адрес удобный. поэтоум так часто и встречаеться даже в примерах документации