wl500-gp/openwrt/* и телефонни номера

Най-после успях да си подкарам OpenWRT на Asus WL-500-GP, както исках. Устройството има два USB2.0 порта, на единия от които съм сложил един Flash drive 1GB, от който устройството успешно boot-ва. В момента на него върви OpenWrt White Russian – With X-Wrt Extensions 0.9, а между по-интересните пакети, които са сложени на него са OpenVPN, Asterisk, vsftpd, и lighthttpd с PHP5, което ми предстои да пробвам (съвсем не вярвам машинката да издържи на всичко това).

Note:За момента нямам възможност да ползвам скайп, така че отсега нататък ще съм достъпен на пловдивски телефон (номера е от SPNet, thx на kordoba за бързата техническа асистенция) и на US номер, които успешно се терминират на asteriska, който е регистриран и във Free World Dialup (още не е тестван за входящи обаждания). Имам 10-на вътрешни IAX extension-а, за моят от които ползвам FireFly с добавенa библиотека за поддръжка G729. Вътрешният extension на Firefly се пренасочва към мобилният телефон, когато софтуерният телефон не е включен, така че би трябвало да съм на линия постоянно. Ако някой иска вътрешен extension номер може да пише, трябва само IAX клиент за предпочитане с поддръжка на G729.

Ако някой реши да ползва OpenWRT с Asus WL500-GP може да прочете това – относно специфична информация, за мен лично се получи с whiterussian-0.9 firmware, а за настройката за boot от USB, може да се прочете това OpenWRT USB Storage Howto.

0

Cisco купи IronPort

Преди няколко дни Cisco обяви, че купува компанията, продаваща устройства за e-mail и web security IronPort – компания, на която самите те са били „дългогодишен клиент“. IronPort, с обявени приходи от близо $25 млн. за 2005, ще бъде закупена за обща цена от близо $830 млн. като плащането ще включва прехвърляне на акции, а сделката по сливането се очаква да бъде приключена през третата четвърт на фискалната 2007г.

IronPort е основана през 2000г. от Scott Weis, който е бивш Microsoft executive. Компанията развива устройства за E-mail и Web Security, работещи с тяхната AsyncOS, базиранa на BSD ядро, което хората от IronPort са модифицирали, с пренаписан mail-transfer-agent, OEM-нат Sophos като антивирусен engine, и оптимизирана работа с паметта. В частност за работата с паметта AsyncOS разчита на т.нар. „Stackless Thread Model“, който позволява на устройствата да издържат до 10 000 едновременни конекции (по думи на IronPort 😉 ). Личният ми опит с IronPort e крайно ограничен Чети по-нататък ( 3 мин)

0

OSPF Adjacency building. ExStart. Exchange.

Малък пример за OSPF adjacency building и по-специално за Database Description процеса.

Имаме серийна PPP връзка м/у два рутера – R5 и R1. Току-що сме задали hello интервал на PPP интерфейс(serial 0/1) м/у R1(Router ID: 1.1.1.254) и R5(Router ID: 1.1.1.5) на 5 секунди, което е различно от стойността по подразбиране от 10 секунди, която е настроена на R5. След изтичането на dead-интервала (4х hello, автоматично изчислен) на R1, за което време той не е получил съответстващ hello пакет от R5, R1 дропва neighbor-отношението. Използваната команда за показване на тези отношения е:

R1#debug ip ospf adj

Ето и дропването на neighbora, с log съобщение за dead timer expired на R1:

R1#
1d16h: OSPF: 1.1.1.5 address 192.168.15.2 on Serial0/1 is dead
1d16h: OSPF: 1.1.1.5 address 192.168.15.2 on Serial0/1 is dead, state DOWN
1d16h: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.5 on Serial0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#

Преглед на съседите за ospf process id 1:

R1#sh ip ospf neighb

Neighbor ID Pri State Dead Time Address Interface
1.1.1.3 1 FULL/BDR
00:00:31 192.168.101.254 FastEthernet0/0.101
1.1.1.3 1 FULL/BDR
00:00:31 192.168.102.254 FastEthernet0/0.102
1.1.1.3 1 FULL/ –
00:01:50 192.168.123.3 Serial0/0
1.1.1.5 1 FULL/ –
00:01:55 192.168.123.5 Serial0/0
1.1.1.4 1 FULL/ –
00:01:49 192.168.123.4 Serial0/0
R1#

Което потвърждава, че 1.1.1.5 е flush-нат от neighbor-таблицата, за интерфейс Serial0/1 и вече не се разпознава като ospf neighbor за този интерфейс.. (Заб: в използваната топология, имаме още един директен L3 линк към 1.1.1.5 през S0/0, който е свързан през Frame Relay облак към 1.1.1.5 с ip address 192.168.123.5) В такава ситуация, автомата на съседските отношения не може да премине в състояние Two-Way, единственото което се случва с него са преходи от Down->Init при всеки получен hello пакет от 1.1.1.5 през интерфейс S0/1.

След като сме установили пропадането на neighbor отношението, можем да вдигнем отново hello-интервала на стойността по подразбиране, за да оставим neighbor-отношението да се формира отново.

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/1
R1(config-if)#ip ospf hello-interval 10
R1(config-if)#^Z
R1#

При следващият hellо, neighbor-отношението се инициализира така:

R1#
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x11F6 opt 0x52 flag 0x7 len 32 mtu 1500 state INIT
1d16h: OSPF: 2 Way Communication to 1.1.1.5 on Serial0/1, state 2WAY
1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0x1793 opt 0x42 flag 0x7 len 32
1d16h: OSPF: First DBD and we are not SLAVE
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1793 opt 0x52 flag 0x2 len 192 mtu 1500 state EXSTART
1d16h: OSPF: NBR Negotiation Done. We are the MASTER
1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0x1794 opt 0x42 flag 0x3 len 192
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1794 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0x1795 opt 0x42 flag 0x1 len 32
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1795 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
1d16h: OSPF: Exchange Done with 1.1.1.5 on Serial0/1
1d16h: OSPF: Synchronized with 1.1.1.5 on Serial0/1, state FULL
1d16h: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.5 on Serial0/1 from LOADING to FULL, Loading Done
1d16h: OSPF: Build router LSA for area 0, router ID 1.1.1.254, seq 0x80000052
R1#

Кратко пояснение на формата на Database Description (DBD) пакетите:

8 бита

8 бита

16 бита

Version

Type

Packet Length

Router ID

Area ID

Checksum

AuthType

AuthInform

AuthInform

IntfcMTU

Options

0 0 0 0 0 I M MS

SequenceNm

LSAHeaders

Полетата в заглавната част се използват както следва:

  • Version – Версия на OSPF протокола, която е формирала този DBD пакет.
  • Type – тип на OSPF пакета. За DBD пакет това е type=2, или 0x02 в hex-запис.
  • Packet Length – Обща дължина на пакета, в брой 32-битови думи.
  • RouterID – ID номера на ospf процеса на изпращащия рутер.
  • Area ID – номера на area-та, в която се намира ospf интерфейса на изпращащия рутер.
  • Checksum – стандартна IP контролна сума (в самият LSA Header за контролна сума се използва контролна сума на Флечър, RFC1146, RFC905), изчислена върху целия пакет, вкл. заглавната част.
  • AuthType – вид на автентикацията за областта, в която се намира изпращащият интерфейс на изпращащият рутер.

Възможните видове автентикация са:

  • 0x0000 – Липса на автентикация, => полето AuthInform не се чете и може да съдържа каквото и да било;
  • 0x0001 – Cleartext автентикация => полето AuthInform съдържа парола в некриптиран текст, до 64 бита големина;
  • 0x0002 – MD5 Автентикация => полето AuthInform има вида (всеки ред е една 32-битова дума):

0x0000

KeyID

AuthDataLength

CryptographicSequenceNumber

където полетата са следните:

· 0x0000 – padding zeros 😉

· KeyId – конфигурираният key-id на изпращащия интерфейс на изпращащият рутер. Трябва да е същия на получаващият рутер за да работи механизма на автентикация успешно. AuthDataLength – дължина на Authentication Data информацията, т.е. на самият message-digest хеш.

· CryptographicSequenceNumber – ненамаляващ Sequence Number. Големината на полето е 32 бита => максималната му стойност е 0xFFFFFFFF или 2^32=4294967296
Заб: самият message-digest хеш се добавя след края на OSPF пакета, и не е част от хедъра.

· IntfcMTU – Maximum Transmission Unit на изпращащия рутер.

Полето Options съдържа флагове, показващи опционални възможности на изпращащия рутер и има следния вид:

*

*

DC

EA

N/P

MC

E

T

като всеки от флаговете е по 1 бит, и има следната функционалност:

· * – неспецифициран бит. В нашият случай, единия neighbor задава тези два бита като 01, а в отговора си другият рутер връща 01;

· DC – Demand Circuit – показва дали изпращащият рутер поддържа OSPF over Demand Circuits;

· EA – Показва дали изпращащият рутер поддържа External Attributes LSA;

· N/P – този флаг указва поддръжката на NSSA области:

· N – задава се в hello пакети, когато изпращащият рутер поддържа NSSA External LSA (type 7). Ako флага N е вдигнат, E трябва да е свален, защото може един рутер, който е част от NSSA да поддържа и AS External LSA(type 5) пакети.

· P – задава се в NSSA External LSA (type 7) пакети, които трябва да бъдат изпратени като AS External LSA(type 5) към останалите области от NSSA ABR рутерите. Двата флага заемат едно и също място в Options полето, защото единия (N) се използва в hello, а другият (P) се използва в LSA пакети (и де факто заема мястото на N).

· MC – показва дали изпращащият рутер поддържа multicasts (Multicast OSPF)

· E – в hello пакетите показва дали изпращащият рутер поддържа AS External LSA (type5), също така е вдигнат и във всички LSA, които произлизат от non-stub области. Флагът е свален в hello пакетите на stub, totally stubbby, и NSSA рутери, осве това директно свързани рутери с различни E-флагове не могат да станат adjacent, => можем да заключим че всички рутери в една област трябва да поддържат еднакво AS External LSA, за да станат adjacent помежду си. Същото важи и за Stub, Totally stubby и NSSA областите.
T – Показва дали изпращащият рутер поддържа Type Of Service.

Следващото поле е изписано като „flags“ в debug-output-а по-горе. То е характерно за DBD пакетите и има такъв формат:

  • 0000 – padding zeros 😉 след котйто следват флаговете:
  • I – Initial – показва дали този DBD пакет е е първият за изпращащия рутер в текущия DBD обмен.
  • M – More – показва дали този DBD пакет е последният за изпращащия рутер в текущия обмен. Ако флага е вдигнат, това показва че този DBD пакет не е последен.
  • MS – Master/Slave – показва дали изпращащият рутер е master в текущия обмен. Както се вижда от debug output-а по-горе, този флаг винаги е вдигнат в първите DBD пакети, които се обменят (ExStart състояние на автомата на neighbor отношението).

Да вземем първия получен DBD пакет от R5:

1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x11F6 opt 0x52 flag 0x7 len 32 mtu 1500 state INIT

Попълнен с OSPF информацията от конкретната ситуация, използвайки първия debug-нат пакет от 1.1.1.5, пакета би изглеждал така:

|0x02|0x02|0x0020|
|0x01010105|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|
01010010|0000|111|
|0x11F6|
|LSA Headers|

С човешки думи ;), пакетът казва, че рутер 1.1.1.5 поддържа External Attriibutes LSA, поддържа AS External LSA, това е първият (Initial) DBD който изпраща, последван от други (More) и текущият рутер се смята за Master в текущия DBD обмен. Заб: вижда се, че neighbor-автомата на 1.1.1.5 е състояние INIT, а след изпращането на този пакет е влязъл в състояние ExSTART, за договаряне на Master-Slave отношенията за DBD обмена. На този DBD пакет, R1 отговаря със следния DBD пакет (който освен всичко друго ще покаже на link neighbor-a, че R1 същто вече е в EXSTART):

|0x02|0x02|0x0020|
|0x010101FE|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01000010|0000|111|
|0x1793|
|LSA Headers|

R1 изпраща собствен DBD пакет, като включва собственото си Router ID 1.1.1.254, или 0x010101FE. Интересното в случая са опциите:
първите два (unused по спецификация) бита, са инвертираната стойност (10) на съответните битове от опциите на R1 (01). В RFC 2328 е указано, че устройство което получава пакети със сетнати unused-битове, трябва да ги резетва на нули, но тук явно не е така, което не съм убеден дали не е начин за означаване посоката на даден пакет към определен рутер в процеса на DBD обмен, иlи пък нещо друго ;). Освен това виждаме, че R1 не е означил поддържка за External Attributes LSA, което обаче не е причина за разпадане на adjacencyто. R1, също както и R5 (и двата са в една област – backbone 0) показва поддръжка за AS External LSA (type 5), което е нормално. R1 от своя страна също вдига и трите флага (I-Initial, M-More, MS-Master), заа да покаже че това също е неговият начален DBD пакет, след него има още, и той трябва да стане master за DBD сесията на този линк. R1 всъщност има пълното право 😉 да се обозначи като Master, защото неговото Router ID (1.1.1.254) е по-голямо от RouterID-то на линк-съседа(1.1.1.5). Оттук нататък, R5 трябва да приеме R1 за Master, от което следват две неща:
1. R5 няма да праща повече DBD пакети с вдигнат MS флаг;
2. R5 ще използва контекста за номериране на R1, т.е. DBD пакетите, които той праща ще бъдат номерирани с номерата на R1.
Debug съобщението „OSPF: First DBD and we are not SLAVE“ на R1 показва това още един път.

1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0x1793 opt 0x42 flag 0x7 len 32
1d16h: OSPF: First DBD and we are not SLAVE

Можем да видим отговора на R5 в следващия получен DBD пакет (R5 е в състояние EXSTART):

1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1793 opt 0x52 flag 0x2 len 192 mtu 1500 state EXSTART

|0x02|0x02|0x00C0|
|0x01010105|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|
01010010|0000|010|
|0x1793|
|LSA Headers|

DBD пакета е много подобен на предишния изпратен от R5, със следните разлики:

  • дължина на пакета е различна(0x00C0), заради съдържаните LSA хедъри;
  • Флаговете Init(това вече е втори DBD пакет от R5, не е Initial) и MS(1.1.1.5 не е Master в текущия DBD обмен) вече са свалени, и флаговетв са 010, или 0x02.
  • Очевидно R5 евче е разбрал от DBD пакета на R1, че той(R5) не е Master в текущия DBD обмен,затова е свалил MS флага в собствените си DBD пакети. Освен това, както се вижда от полето SequenceNm (0x1793, или същото като SequenceNm на R1), R5 номерира своите DBD пакети в контекста на R1, като дори използва същия номер, като изпратения от R1, с което де факто прави и DBD Acknowledgement, потвърждавайки успешното получаване на DBD пакета на R1.

След получаването на такъв DBD пакет линк-съседа, R1 вече е сигурен, че е приет за master от отсрещната страна на линка, което се потвърждава от съобщението:

1d16h: OSPF: NBR Negotiation Done. We are the MASTER

Оттук нататък, R1 може да продължи с описанието на собствената си Link-State база данни, и да получава обратно потвържденията на R5, съдържащи собствената му LSDB.

1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0x1794 opt 0x42 flag 0x3 len 192

|0x02|0x02|0x00C0|
|0x010101FE|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01000010|0000|011|
|0x1794|
|LSA Headers|

SequenceNm от 0x1794 показва, че това е следващият DBD пакет от номерацията на Master-рутера, Initial флага е свален, вдигнат е флага More, и флага MS, за Master. Следва потвърждение R5, което показва, че от предишния пакет и той вече е в съсояние Exchange:

1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1794 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE

|0x02|0x02|0x0020|
|0x01010105|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|
01010010|0000|000|
|0x1794|
|LSA Headers|

Флаговете са вече 000, което значи, че този DBD пакет е последният от R5. R1 праща обратно следният DBD пакет:

1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0x1795 opt 0x42 flag 0x1 len 32

|0x02|0x02|0x0020|
|0x010101FE|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01000010|0000|001|
|0x1795|
|LSA Headers|

От който се вижда, че това е последният пакет и от неговият Database Description процес. Следва потвърждение от R5:

1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1795 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE

|0x02|0x02|0x0020|
|0x01010105|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01010010|0000|000|
|0x1795|
|LSA Headers|

С това процеса на DBD обмен трябва да приключи, всеки от рутерите да влезе в състояние на LOADING или FULL:

1d16h: OSPF: Exchange Done with 1.1.1.5 on Serial0/1
1d16h: OSPF: Synchronized with 1.1.1.5 on Serial0/1, state FULL

Следва нормалното Syslog съобщение за вдигнат съсед:

1d16h: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.5 on Serial0/1 from LOADING to FULL, Loading Done

Както и изпращане на Router LSA за област area 0:

1d16h: OSPF: Build router LSA for area 0, router ID 1.1.1.254, seq 0x80000052
R1#

С което процесът приключва.

0

Carrier Pigeon Internet Protocol

RFC документите, наброяващи над 4000 технически и организационни публикации, описващи различни протоколи, технологии, и аспекти от работата на Интернет, имат вече близо 40-годишна история. Първото RFC, написано от Стив Крокър от UCLA е публикувано през 1969 година и описва хост-софтуера в крайните възли от ARPANET, свързани помежду си посредством Interface Message Processor устройството, което като първият пакетен комутатор можем да наречем прадядо на съвременните рутери.

През годините обаче, наред с огромния брой сериозни технически спецификации, са написани и доста смешни(хумористични) RFC-та. Например цитираното по-долу RFC1149: A standard for the transmission of IP Datagrams on Avian Carriers :-), лично на мен винаги ми е било много забавно, а през 2001 няколко души от Bergen Linux Users Group, формират силно неофициалната „CPIP Working Group“ и имплементират пренос на IP върху пощенски гълъби :-), от която имплементация има и снимков материал.

Някои други смешни RFC-та са например RFC 2324: HyperText Coffee Pot Control Protocol, RFC 2795: Infinite Monkey Protocol Suite, RFC3091:Pi Digit Generation Protocol, или RFC3521:Electricity over IP, също известно като „Mostly Pointless Lamp Switching (MPLS)“ 🙂
А това е текста на RFC1194:A standard for the transmission of IP Datagrams on Avian Carriers: Чети по-нататък ( 3 мин)

0

Internet

Интересно четиво на което се натъкнах последните дни: оригиналната презентация на Робърт Кан и Винт Сърф от 1974, когато по време на IEEE Transaction of Communications, те предлагат дизайн на нов протокол за пакетна комутация. Документът се казва A protocol for Packet Network Intercommunication и е доста интересен от гледна точка на плановете за разработка на протоколите, които впоследствие ще станат основа на Интернет. Интересни са голямата част от предвидени проблеми пред проткола, основната идея на работата, както и разликите от сегашния му вид.

Следва малко история за раждането и развитието на Интернет през годините, събрана от различни източници. Както винаги, за всичко са виновни руснаците, вкл. и за раждането на Интернет … 🙂 Чети по-нататък ( 7 мин)

0

Net of the free (a.k.a. „of the free“ – НЕТ(спасиба)!!)

в „земята на свободните“ са гласували поредния закон в полза на свободите на нищо неподозиращото население;-). няма само нормалните телекоми да се подслушват, я – трябва и VoIP, естествено…

това е цитат от SER Users mailing list. публикуван е поради своята „непреходна стойност“;-)

>Hi All.
>
>I’m located in the US and would like to comply with the Communications
>Assistance for Law Enforcement Act (CALEA)
that Congress passed which
>basically says that VoIP providers should have the ability to wiretap
>conversations for the FBI upon request.
>
>I use mediaproxy for NAT traversal. So my question is how can I be
>CALEA compliant? I assume I should be able to modify mediaproxy to
>write RTP streams to disk, but I’m unclear on how to „mix“ both sides
>of the conversation.
>
>Can anyone help with a suggestion?
>

това далеч не е първата проява на подкрепа за свободолюбивия дух от страна на федералното бюро, по чиято заповед миналата година са били свалени и предадени 20 сървъра със съдържание на медията Indymedia от лондонския филиал на хостинг провайдер.

0