Что означает «в локали POSIX»?
Я не знаком с netctl, но ваша основная проблема связана с тем фактом, что в вашей таблице маршрутизации ядра указаны два шлюза по умолчанию.
Why would the wifi ping fail when both devices are connected (or, more accurately, when both netctl profiles are active)?
Проблема здесь связана с тем, что ваша таблица маршрутизации содержит два шлюза по умолчанию:
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
0.0.0.0 10.10.0.1 0.0.0.0 UG 303 0 0 wlan0
Когда маршруты конфликтуют (, как эти два ), ядро выбирает маршрут с наименьшей «метрикой» (, в данном случае eth0 со значением «0» )или тот, который был добавлен первый я верю.
Причина, по которой эхо-запросы на удаленных хостов не выполняются, когда вы указываете беспроводной интерфейс в вашем примере ping -Iwlan0, скорее всего, заключается в том, что ядро не знает, как маршрутизировать к этому удаленному хосту, используя указанный вами интерфейс, поскольку шлюз по умолчанию (с самой низкой метрикой )технически доступен через другой интерфейс. Эти пинги, скорее всего, идут в битбакет.
Резервирование
Если вы ищете резервный интернет на случай отключения на той или иной стороне,вам, вероятно, потребуется создать свой собственный сценарий оболочки, который может делать следующее:
- Обнаружение отсутствия трафика на основном интерфейсе шлюза
- Измените таблицу маршрутизации ядра, чтобы использовать новый интерфейс для GW по умолчанию
- Мониторинг основного интерфейса на наличие трафика (UP и доступ к удаленным хостам)
- Перенастройте таблицу маршрутизации, чтобы вернуться к основному интерфейсу.
Примечание :Настройки netctl для проводного -на -аварийное переключение беспроводной сети могут быть полезны, если вы хотите обеспечить базовое подключение уровня 1 (кабель отключен или точка доступа Wi-Fi выходит из строя ), но обычно два интерфейса должны находиться в одной сети и в основном получать доступ в Интернет через один и тот же шлюз.
Is there a way to configure netctl to stop the profile if the interface goes down?
Думаю, вы можете сделать это с помощью директив preup и predown.
ExecUpPost='ifconfig wlan0 down|| true'
ExecDownPre='ifconfig wlan0 up|| true'
Взгляните на /etc/netctl/hooks/в документации.
Когда POSIX говорит (для «верхнего»)
In the POSIX locale, only:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
shall be included:
он определяет локаль POSIX. Это означает, что в контексте локали POSIX «верхний» класс символов состоит только из перечисленных символов.
POSIX не определяет никакую другую локаль, но системы могут это делать. В результате вы не можете полагаться на то, что grep '[[:lower:]]' fileсделает что-то полезное в локали, отличной от POSIX, если вы ограничитесь только POSIX. Однако многие системы определяют другие локали и их классы символов. Например, в системе, использующей локали библиотеки GNU C,
$ echo 'α' | LC_ALL=el_GR.UTF-8 grep '[[:lower:]]'
α
Я не совсем понял ваше предложение (в другом вопросе ). Однако похоже, что вы неверно истолковали вариант использования локали POSIX .
Вы предполагаете, что локаль не очень удобна для пользователя. И что его нужно настроить, чтобы он был таким. Однако удобство для пользователя не является целью posix local, это работа других локалей с другими правилами.
Работа posix local должна быть предсказуемой. Действительно, он также выигрывает от простоты. Как только вы начинаете включать другие языки в стандарт, очень трудно остановиться, и в результате получается стандарт, который требует тщательного обслуживания и трудно реализуем.
Я, как разработчик, никак не могу знать все правила для каждого языка, как сортировать их в «алфавитном» порядке и действительно знать, какой из них в верхнем или нижнем регистре. Правила для не -английских языков могут быть действительно очень сложными. Поэтому, если вы настроите локальный код Posix, включив в него правила для любого другого языка, вы действительно сделаете его поведение очень непредсказуемым.
Изменения в локали posix действительно могут нанести вред программному обеспечению, если старые системы не соответствуют поведению новых систем. (См. анекдот ниже)
Анекдот
Одна из самых неясных и трудно диагностируемых ошибок, которые я когда-либо видел, заключалась в ETL-инструменте, "случайно" удаляющем строки. После тщательного анализа выяснилось, что программное обеспечение работает нормально, но только при запуске с LC _COLLATE=C. Это произошло потому, что при сопоставлении записей он полагался на порядок сортировки из базы данных, соответствующий его собственному внутреннему порядку сортировки. Разработчики просто не заметили, что в некоторых локалях числа сортируют текст в алфавитном порядке «0, -1, 1, -2, 2» вместо «-1, -2, 1, 2».
Помимо взаимодействия с пользователем,это показывает подлинную потребность в том, чтобы системы вели себя предсказуемым образом, который может быть общим для всех систем.