LINUX.ORG.RU

Сообщения bolvan

 

yate + tls+srtp

Есть простая задача. Устроить шифрованное общение по SIP-TLS/SRTP между софтфонами. Клиенты - eyebeam или 3cx phone. Сервер на linux. Удалось эту задачу решить на asterisk, но есть ряд проблем : трафик при включении шифрования роутится через сервер, напрямую никак, и возникают ничем не убираемые шумы, как будто хаотично теряются пакеты и их заменяют шшшшшшшшшш. Был однажды сервер на windows с 3cx phone, и это работало очень хорошо, шифрованный трафик шел напрямую, никаких шипений, качество отличное. Но сейчас нужен именно linux. Пробую настроить yate. Простейший вариант с sip udp пошел с ходу. Но дальше оказалось, что без udp листенера с обоими упомянутыми клиентами происходит глюк : call established, никакой голос не идет, через 15 секунд hangup. Подробнее проблему описал на форуме yate : http://forum.yate.ro/index.php?topic=323.msg898#msg898. Но там мало отвечают, боюсь придется ждать очень долго.

bolvan
()

asterisk, SRTP, directmedia

Сочетание трех товарищей из сабжа возможно ? Если encryption отключен, то нормально идет директом. Если включен - траф гонится через сервер. На 3CX Phone System такого не наблюдалось, кажется.

И еще вопрос : можно ли к астериску прикрутить кодеки от броадком - BV16,BV32. Они по умолчанию включены в eyebeam, при прогоне через астериск перекодируются из 16 Кгц в 8 Кгц другого кодека. Слышимость ужасна. Пока решил вопрос включением G722 в eyebeam. Его же в астериске как самый приоритетный. Лучше бы, конечно, вообще траф не гнался через астериск

bolvan
()

ipsec linux<>windows

Есть windows сервер за NAT. Нужно устроить с ним ipsec в transport mode. С windows клиентов все работает хорошо, но с linux мне не удалось настроить ни racoon, ни openswan. Если я сейчас буду описывать суть проблем, это будет надолго. Я прошу всего лишь поделиться реально работающими конфигами racoon или openswan для описанного случая. Авторизация идет через сертификаты

bolvan
()
30 комментариев

6to4 проблемы с дупликацией пакетов

Есть у меня роутер на openwrt. Ядро 3.3.8. Раздает он ipv4 через nat и ipv6 через 6to4.

С недавних пор стали пропадать сразу целые группы пакетов ipv6. Пингаешь роутер с внешнего ipv6, все хорошо, вдруг группа из потерь от 3 до 15 пингов, потом опять идет несколько минут нормально, потом опять потеря, ...

Стал смотреть TCPDUMP-ом и обнаружил очень интересную картину. В моменты, когда роутер перестает отвечать на пинги по ipv6 ему приходят дуплицированые ping реквесты, на которые он уже ответил 15 секунд назад. Разумеется, дупликация пакетов - проблема внешняя, но роутер ведет себя в этой ситуации странно - перестает воспринимать нормальные пакеты, которые идут в перемешку с дупами.

Смотрим внимательно на seq.

Идут нормальные пинг-реплаи :

2127	1067.024602	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20844, hop limit=128 (reply in 2128)
2128	1067.024912	2002:yyyy:yyyy::1	2002:xxxx:xxxx::yyyy:yyyy	ICMPv6	114	Echo (ping) reply id=0x0001, seq=20844, hop limit=64 (request in 2127)

13 секунд спустя опять 2 пинг-реплая, но почему-то в последнем из них неправильный адрес источника - он заменен с адреса хоста-ответчика на адрес назначения. Но это только в данной проблемной группе, в других такого может и не быть. Далее приходит уже приходивший ранее пакет с seq=20844. Ethernet frame number у него отличается, разумеется, это просто дуп.

2153	1079.031124	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20856, hop limit=128 (reply in 2154)
2154	1079.031432	2002:yyyy:yyyy::1	2002:xxxx:xxxx::yyyy:yyyy	ICMPv6	114	Echo (ping) reply id=0x0001, seq=20856, hop limit=64 (request in 2153)
2155	1080.030487	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20857, hop limit=128
2156	1080.030814	2002:xxxx:xxxx::yyyy:yyyy	2002:xxxx:xxxx::yyyy:yyyy	ICMPv6	114	Echo (ping) reply id=0x0001, seq=20857, hop limit=128
2157	1081.029856	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20858, hop limit=128
2158	1081.030170	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20844, hop limit=128

И дальше системка начинает игнорировать нормальные пакеты вперемешку с дупами до тех пор, пока дупы не перестанут приходить. Если напустить tcpdump прямо на 6to4 интерфейс - там в проблемные периоды вообще все исчезает. Если это не ICMP, а что-то полезное через TCP - рвутся конекты.

2159	1082.029775	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20859, hop limit=128
2160	1082.030093	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20845, hop limit=128
2161	1083.030218	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20860, hop limit=128
2162	1083.030534	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20846, hop limit=128
2163	1084.030631	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20861, hop limit=128
2165	1085.028964	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20862, hop limit=128
2166	1085.029310	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20847, hop limit=128
2167	1086.032314	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20863, hop limit=128
2168	1086.032623	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20848, hop limit=128
2169	1087.032282	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20864, hop limit=128
2170	1087.032588	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20849, hop limit=128
2171	1088.033225	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20865, hop limit=128 (reply in 2172)
2172	1088.033546	2002:yyyy:yyyy::1	2002:xxxx:xxxx::yyyy:yyyy	ICMPv6	114	Echo (ping) reply id=0x0001, seq=20865, hop limit=64 (request in 2171)
2173	1089.034199	2002:xxxx:xxxx::yyyy:yyyy	2002:yyyy:yyyy::1	ICMPv6	114	Echo (ping) request id=0x0001, seq=20866, hop limit=128 (reply in 2174)
2174	1089.034506	2002:yyyy:yyyy::1	2002:xxxx:xxxx::yyyy:yyyy	ICMPv6	114	Echo (ping) reply id=0x0001, seq=20866, hop limit=64 (request in 2173)

И что же это такое, как с этим бороться ? В логах абсолютно никакой информации не появляется

bolvan
()

ограничить cpu usage

Экспериментирую с провайдером beeline на DIR-320 + openwrt. Работает этот провайдер через VPN L2TP. Процессор у роутера слабоват, поэтому от 20 мбит он забивается на 100% в ядре. Вешаются намертво остальные процессы. dnsmasq и hostapd перестают работать, следовательно рушится wifi, dhcp и dns. И еще много всяких неприятностей. Можно ли ограничить использование cpu или поставить низкий приоритет на это дело ? Пусть бы резалась скорость, но необходимо, чтобы остальные службы не умирали

bolvan
()
7 комментариев

beeline & xl2tpd

Нужна помощь в настройке билайн интернет на openwrt. Для тех, кто не в курсе, билайн работает через VPN на L2TP без шифрования с авторизацией по CHAP. С винды все нормально работает. Через роутер как-бы тоже работает. Но билайну не нравятся какие-то опции полученного vpn соединения. Пинги не ходят, по web пускает только на некоторые страницы вроде help.internet.beeline.ru (то есть это уже значит, что vpn и маршрутизация работают, пакеты ходят), при попытке захода броузером по http на любой ip адрес получаем от билайна страницу вида :

Уважаемый абонент ! Вы подключаетесь к сети интернет с неверным типом соединения. Необходимо пересоздать VPN подключение или перенастроить роутер согласно инструкциям на сайте поддержки.

Что имеем на openwrt. openwrt работает с такого рода соединениями через xl2tpd. Так что вопрос касается настройки связки beeline + linux + xl2tpd, неважно openwrt или нет. Для чистоты эксперимента настраиваю xl2tpd вручную без использования механизмов управления интерфейсами openwrt.

xl2tpd.conf :

[global]
port = 1701
auth file = /etc/xl2tpd/xl2tp-secrets
access control = no

[lac corbina] (вместо corbina можно всё, что угодно)
lns = 83.102.254.215
;lns = tp.internet.beeline.ru
redial = yes
redial timeout = 15
require chap = yes
require authentication = no
name = <my_username>
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd.corbina
require pap = no
autodial = yes

options.xl2tpd.corbina

name <my_username>
remotename l2tp
ipparam corbina
ifname 'l2tp-bee'
connect /bin/true
logfile /var/log/xl2tpd.corbina.log
nodeflate
nobsdcomp
persist
maxfail 0
nopcomp
noaccomp
defaultroute

В chap-secrets прописаны l/p

Судя по логам все абсолютно нормально. Фактически VPN работает без проблем.

xl2tpd.corbina.log 

Plugin pppol2tp.so loaded.
using channel 2
Using interface l2tp-bee
Connect: l2tp-bee <--> 
PPPoL2TP options: debugmask 0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3ff20660>]
rcvd [LCP ConfReq id=0x1 <mru 1460> <asyncmap 0xa0000> <auth chap MD5> <magic 0x1e3037aa> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <mru 1460> <asyncmap 0xa0000> <auth chap MD5> <magic 0x1e3037aa> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x3ff20660>]
PPPoL2TP options: debugmask 0
sent [LCP EchoReq id=0x0 magic=0x3ff20660]
rcvd [CHAP Challenge id=0x1 <c22349f68bb5a460bb6acf6190b961a1>, name = "bras41.spb"]
sent [CHAP Response id=0x1 <c4e12ae730511b620bd26bc5f99e4d8c>, name = "0896320007"]
rcvd [CHAP Success id=0x1 ""]
CHAP authentication succeeded
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <addr 83.102.254.215>]
sent [IPCP ConfAck id=0x1 <addr 83.102.254.215>]
rcvd [IPCP ConfNak id=0x1 <addr 37.145.55.122>]
sent [IPCP ConfReq id=0x2 <addr 37.145.55.122>]
rcvd [IPCP ConfAck id=0x2 <addr 37.145.55.122>]
local  IP address 37.145.55.122
remote IP address 83.102.254.215
Terminating on signal 15
Connect time 5.6 minutes.
Sent 16820 bytes, received 244806 bytes.
PPPoL2TP options: debugmask 0
sent [LCP TermReq id=0x2 "User request"]
sent [LCP TermReq id=0x3 "User request"]
Connection terminated.
Modem hangup

Я сделал для сравнения cap дампы процесса установления соединения у microsoft и с xl2tpd, но не могу разобрать что там не так. Никаких принципиальных отличий не вижу. Просто билайн что-то такое хитрое требует, а я не знаю что.

bolvan
()
2 комментария

Wifi не видит 5 Ггц

Здравствуйте.

У меня есть роутер LinkSys WRT160NL. Роутер с 2 антенами, стандарт 802.11n. Чипсет AR71XX. На нем openwrt 12.09 (attitude adjustment). По пока неясным для меня причинам не доступен диапазон 5 Ггц.

root@bnr:~# lsmod | grep ath
ath79_wdt               2240  1 
ath9k                  92256  0 
ath9k_common            1264  1 ath9k
ath9k_hw              370624  2 ath9k,ath9k_common
ath                    14640  3 ath9k,ath9k_common,ath9k_hw
mac80211              291472  1 ath9k
cfg80211              169264  3 ath9k,ath,mac80211
compat                 11680  5 ath9k,ath9k_common,ath9k_hw,mac80211,cfg80211

root@bnr:~# iwinfo phy0 info
Wiphy phy0
        Band 1:
                Capabilities: 0x104e
                        HT20/HT40
                        SM Power Save disabled
                        RX HT40 SGI
                        No RX STBC
                        Max AMSDU length: 3839 bytes
                        DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 8 usec (0x06)
                HT TX/RX MCS rate indexes supported: 0-15
                Frequencies:
                        * 2412 MHz [1] (27.0 dBm)
                        * 2417 MHz [2] (27.0 dBm)
                        * 2422 MHz [3] (27.0 dBm)
                        * 2427 MHz [4] (27.0 dBm)
                        * 2432 MHz [5] (27.0 dBm)
                        * 2437 MHz [6] (27.0 dBm)
                        * 2442 MHz [7] (27.0 dBm)
                        * 2447 MHz [8] (27.0 dBm)
                        * 2452 MHz [9] (27.0 dBm)
                        * 2457 MHz [10] (27.0 dBm)
                        * 2462 MHz [11] (27.0 dBm)
                        * 2467 MHz [12] (disabled)
                        * 2472 MHz [13] (disabled)
                        * 2484 MHz [14] (disabled)
                Bitrates (non-HT):
                        * 1.0 Mbps
                        * 2.0 Mbps (short preamble supported)
                        * 5.5 Mbps (short preamble supported)
                        * 11.0 Mbps (short preamble supported)
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
        max # scan SSIDs: 4
        max scan IEs length: 2257 bytes
        Coverage class: 0 (up to 0m)
        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * CCMP (00-0f-ac:4)
        Available Antennas: TX 0x3 RX 0x7
        Configured Antennas: TX 0x3 RX 0x7
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * WDS
                 * monitor
                 * mesh point
                 * P2P-client
                 * P2P-GO
        software interface modes (can always be added):
                 * AP/VLAN
                 * monitor
        valid interface combinations:
                 * #{ managed, WDS, P2P-client } <= 2048, #{ AP, mesh point, P2P-GO } <= 8, #{ IBSS } <= 1,
                   total <= 2048, #channels <= 1, STA/AP BI must match
                 * #{ AP } <= 1,
                   total <= 1, #channels <= 1, STA/AP BI must match
        Supported commands:
                 * new_interface
                 * set_interface
                 * new_key
                 * start_ap
                 * new_station
                 * new_mpath
                 * set_mesh_config
                 * set_bss
                 * authenticate
                 * associate
                 * deauthenticate
                 * disassociate
                 * join_ibss
                 * join_mesh
                 * remain_on_channel
                 * set_tx_bitrate_mask
                 * frame
                 * frame_wait_cancel
                 * set_wiphy_netns
                 * set_channel
                 * set_wds_peer
                 * tdls_mgmt
                 * tdls_oper
                 * probe_client
                 * set_noack_map
                 * register_beacons
                 * Unknown command (89)
                 * Unknown command (92)
                 * testmode
                 * connect
                 * disconnect
        Supported TX frame types:
                 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * (null): 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
        Supported RX frame types:
                 * IBSS: 0x40 0xb0 0xc0 0xd0
                 * managed: 0x40 0xd0
                 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
                 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
                 * mesh point: 0xb0 0xc0 0xd0
                 * P2P-client: 0x40 0xd0
                 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
                 * (null): 0x40 0xd0
        Device supports RSN-IBSS.
        HT Capability overrides:
                 * MCS: ff ff ff ff ff ff ff ff ff ff
                 * maximum A-MSDU length
                 * supported channel width
                 * short GI for 40 MHz
                 * max A-MPDU length exponent
                 * min MPDU start spacing
        Device supports TX status socket option.
        Device supports HT-IBSS.

root@bnr:~#i w reg get
country US:
        (2402 - 2472 @ 40), (3, 27)
        (5170 - 5250 @ 40), (3, 17)
        (5250 - 5330 @ 40), (3, 20), DFS
        (5490 - 5600 @ 40), (3, 20), DFS
        (5650 - 5710 @ 40), (3, 20), DFS
        (5735 - 5835 @ 40), (3, 30)

Сразу скажу, что DFS не поддерживается. Но тем не менее есть 2 не DFS-ных диапазона 5 Ггц, доступных по регуляции.

Гадаю над вопросом действительно ли роутер в принципе не поддерживает 5 Ггц или это проблема ядра/драйверов/настройки. Обязует ли 802.11n поддержку диапазона 5 Ггц ? Если нет, то поддерживает ли эта модель роутера 5 Ггц ? Если да/да, то что не так и почему не видятся диапазоны ?

bolvan
()
20 комментариев

openwrt залогить kernel panic

У меня есть такая проблема. Роутер DIR-620/D1. Собирал под него openwrt attitude adjustment и trunk. Везде наблюдаются падения с зависанием или перезагрузкой примерно раз-два в день. Однажды упало от ls -lR /, другой раз от полчаса тяжелых пингов до одного из клиентов точки доступа. Да и просто так падало. Логично, что это падает ядро. Но пишет оно лог на консоль. Получить к нему доступ можно только подпаявшись к serial port. Всилу некоторых причин это сделать проблематично.

Есть ли возможность отправить dmesg куда-нибудь в файл, и как это сделать ? (в ubuntu dmesg лежат в /var/log) Могут ли туда записаться последние сообщения падения ядра ?

Цель - выяснить конкретную причину падения, чтобы знать где копать.

bolvan
()
2 комментария

RSS подписка на новые темы