oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: ip

digi AnywhereUSB (USB over IP)

2006/04/23 No hi ha comentaris

Reading time: 1 – 2 minutes

Fa un temps vaig publicar un article que parlava justament d’un producte igual que el que us parlaré en aquest article. En l’article en qüestió em queixava que només suportava dispositius 1.1 el producte de digi suporta també USB 2.0 tot i que com que la conversió a IP la fa sobre una xarxa a 100Mbps també limita la seva velocitat a 12Mbps (velocitat màxima del USB 1.1), però malgrat tenir el mateix problema que el producte que us comentava aquest dispositiu és molt més professional, tan en l’acabat com en les altres prestacions així que jo diria és el millor servidor IP USB que he trobat fins ara.

Un parell de documents (.pdf) per completar l’article, si us interessa el tema us aniran bé:

protocol de capa 4: SCTP (Stream Control Transmission Protocol)

2006/03/07 No hi ha comentaris

Reading time: 3 – 4 minutes

Tot navegant per la xarxa fa uns dies que vaig trobar un breu document d’IBM que parlava d’un protocol que fa temps que coneixo però que mai m’havia parat a pensar com funcionava per dintre. Es tracta d’un protocol de la capa de transport que intenta ser una eina molt més precisa i efectiva en alguns problemes que presenten els protocols TCP i UDP al transportar aplicacions d’streaming per sobre seu. Tot i la seva orientació a aplicacions multimèdia es pot usar per moltes altres aplicacions.

Més que fer un resum de les aplicacions que són òptimes corre sobre aquest relativament nou protocol (l’RFC és de l’any 2000) el que jo he trobat molt interessant i que vull explicar una mica aquí són dues funcionalitats que desconeixia completament d’aquest protcol:

1) Multi-homing

En un enllaç podem adreçar el tràfic d’un host a un altre a través de més d’una interficie de xarxa i de més d’una IP. A diferència del protocol TCP les comunicacions no s’estableixen entre un socket que uneix dos hosts, sinó que SCTP ens permet establir connexions que permeten connectar dos hosts a través de més d’una interficie simultaneament. El sorprenent és que el propi protocol de transport, al igual que fa TCP, s’encarrega d’entregar els paquets de forma ordenada a la capa d’aplicació.

2) Multi-streaming

Cada paquet SCTP té una associació d’stremas, o sigui, multiples streams en el seu interior. L’importància d’això esta en que, per exemple, quan estem esperant una retransmissió després d’haver perdut un paquet; això no afecta als altres streams de l’associació d’streams. Aquest és el problema més greu que tenim en TCP, perquè si ens falta el paquet inicial aquest bloc d’informació que ens falta bloqueja la resta d’informació que ja hem rebut. Per això, no és gens òptim treballar en connexions TCP si estem usant aplicacions basades en stream de dades. A part dels problemes de sobrecarrega de tràfic que suposa haver de tenir una capçalera tan pesada com la TCP, en protcol que depenen tan de la latència del canal.

El document també ens parla d’altres característiques molt interessants d’aquest protocol de transport. Per exemple, que per negociar l’obertura d’un enllaç ja no es fa amb una three-way handshake sinó que s’usa un sistema millorat que evita de forma intrínseca els problemes de SYN flood. La resta de característiques no les he vist especialment interessants així que si les voleu coneixer us convido a llegir el document en que m’he inspirat per escriure això: Better networking with SCTP (local).

cutter – tallem connexions TCP/IP en linux

2006/01/28 No hi ha comentaris

Reading time: < 1 minute

Aquesta eina la vaig veure fa molt temps al blog de Xavier Caballé, però no me l’havia pogut mirar fins avui i per no perdre la referència aquí va aquesta nota. Jo diria que la funcionalitat queda molt clara en el títol de l’article i en el propi nom de l’eina. Amb cutter quan veiem un socket TCP actiu al nostre linux, o tots els sockets que provenen d’una IP, els podrem desconnectar a l’instant de forma ben simple.

InterScan Messaging de TrendMicro problematic amb kernel 2.4 i ECN

2005/11/04 No hi ha comentaris

Reading time: 2 – 2 minutes

Tenia un problema amb un servidor de correu SMTP al qual no podia accedir des del servidor de correu de la feina. Encanvi des d’altres IPs del nostre mateix rang si que tenia accés al port 25/tcp d’aquest servidor remot. Doncs resulta que el servidor en qüestió té instal·lat un InterScan Messaging Security Suite de la casa TrendMicro i al servidor de correu de l’empresa jo hi tenia activat el ECN (Explicit Congestion Notification). El problema esta en que quan s’envia un “SYN” en el handshake TCP entre els nostres servidors el paquet TCP té activats dos flags més a part del ‘SYN’, el ‘W’ i el ‘E’.

Aquí podeu veure el que envia el meu servidor amb ECN, flags SWE:

14:12:31.257939 IP 1.1.1.1.44435 > 2.2.2.2.25: SWE 2986809236:2986809236(0) win 5840 <mss 1460,sackOK,timestamp 338497211 0,nop,wscale 0>

El que envia un altre servidor que no té ECN, flag S:

14:13:02.225358 IP 1.1.1.2.37876 > 2.2.2.2.25: S 3871099907:3871099907(0) win 5840 <mss 1460,sackOK,timestamp 3419720577 0,nop,wscale 2>

Per comprovar si realment tenim el ECN activat al kernel:

# cat /proc/sys/net/ipv4/tcp_ecn

Per desactivar el ECN del nostre kernel:

echo 0 > /proc/sys/net/ipv4/tcp_ecn

Només fent això la cosa ja ha començat a funcionar perfectament. Així doncs, dubto que mai a algú li passi algo tan enravassat com el que m’acaba de pasar però aquí queda explicat.

PAN IP sobre bluetooth amb Gentoo/Linux

2005/11/03 3 comentaris

Reading time: 2 – 3 minutes

Per llençar una xarxa IP sobre de bluetooth en un linux, concretament amb una gentoo linux. Doncs bé, el més important és que li donem suport al kernel del nostre sistema bluetooth i després hem de tenir el paquet: net-wireless/bluez-pan i el mòdul bnep carregat.

Missatges del kernel després de carregar el mòdul (dmesg):

Bluetooth: BNEP (Ethernet Emulation) ver 1.2
Bluetooth: BNEP filters: protocol multicast

Un cop tenim això llest dels dos PCs que volem connectar amb la xarxa PAN (Personal Area Network), el que hem fer és decidir qui farà de NAP (master – Network Access Point) i qui de PANU (slave – PAN user).

Configuració del servidor:

# pand -n --listen --role NAP
pand[24538]: Bluetooth PAN daemon version 2.19
pand[24539]: New connection from yy:yy:yy:yy:yy:yy bnep0

Configuració del client:

# pand -n --connect xx:xx:xx:xx:xx:xx
pand[15986]: PAN daemon ver 1.1
pand[15986]: Connecting to xx:xx:xx:xx:xx:xx
pand[15986]: bnep0 connected

En el client s’ha de posar la MAC del dispositiu BT del servidor perquè aquest es connecti al servidor. Un cop aquest tràmit funcioni podrem comprobar que ja tenim un nou dispositiu de xarxa el bnep0. Ara només cal assignar-li una IP a cada dispositiu el del servidor i del client i llestos. Ja tenim la xarxa PAN funcionant amb protocol IP.

Observeu que uso el paràmetre -n perquè no es llenci el pand com a dimoni, sinó com un programa interactiu així podem veure el debug a la mateixa línia de comandes. Un cop ho hagueu provat és bona idea tenir-lo com a dimoni així ja no ens hem de preocupar de que estigui enllaçat tota l’estona ho farà el propi dimoni.

Si voleu més detalls de com fer-ho, m’he basat amb el document HOWTO-PAN (local). Només afegir que els index de transferència a un metre un PC de l’altre eren força baixos d’uns 200kbps i molt irregulars, amb puntes d’uns 800kbps. L’allargada màxima aconseguida amb parets ha estat d’uns 10m, però amb un ample de banda ridicul.

nat traversal

2005/10/23 No hi ha comentaris

Reading time: 2 – 4 minutes

A vegades tampoc em funcionen les coses a mi, a què ve aquest comentari? doncs resulta que hi ha més d’un amic que em diu que li dona la sensació que sempre me’n surto de tot doncs bé. Aquí us parlo d’una eina que no he aconseguit que em funcionés tinc diverses teories del perquè però la veritat és que com que de moment no la necessito m’he cansat de seguir provant, o sigui, que de moment he de dir que no me n’he sortit a usar-la.

L’eina té molt bona pinta es diu nat-traversal serveix per connectar a ports de màquines internes que estan darrera de sistemes enmascarats (darrera de NAT). La web és molt explicativa i útil.

nat-traverse establishes connections between nodes which are behind NAT gateways, i.e. hosts which do not have public IP addresses. Additionally, you can setup a small VPN by using pppd on top of nat-traverse. nat-traverse does not need an external server on the Internet, and it isn’t necessary to reconfigure the involved NAT gateways, either. nat-traverse works out-of-the-box.

Tot i amb això trobo súper interessant la tècnica que usent fer entrar a través del NAT fins al PC que teoricament no té els ports públics:

1.Firstly, nat-traverse on host left sends garbage UDP packets to the NAT gateway of right. These packets are, of course, discarded by the firewall.

2.Then right’s nat-traverse sends garbage UDP packets to the NAT gateway of left. These packets are not discarded, as left’s NAT gateway thinks these packets are replies to the packets sent in step 1!

3.left’s nat-traverse continues to send garbage packets to right’s NAT gateway. These packets are now not dropped either, as the NAT gateway thinks the packets are replies to the packets sent in step 2.

4.Finally, both hosts send an acknowledgement packet to signal readiness. When these packets are received, the connection is established and nat-traverse can either relay STDIN to the socket or execute a program.

Jo concretament el que he provat és de redirigir un port amb el netcat, però el problema que crec que tinc és que jo no faig un ‘masquerade’ al firewall que tinc davant, sinó un ‘SNAT’ i per si fos poc abans d’arribar al firewall passo per un router intern, així doncs segur que hi ha alguna cosa pel camí que m’està estorbant, però com comentava abans com que de moment no necessito l’eina ja m’he cansat d’insisitir. Aquí queda el tema fins que realment em fassi falta o algú s’hi posi i em digui què tal.

Remote Power Manager

2005/08/08 No hi ha comentaris

Reading time: 2 – 2 minutes

Avui tot mirant el material de Cablematic he trobat un Remote Power Manager per 8 dispositius (o com dic jo 8 endolls gestionables) a molt bon preu, uns 188. Suposo que haureu sentit a parlar d’aquests dispositius acostumen a permetre apagar i encendre aparells a través d’IP. A través d’una WEB i d’altres protocols de xarxa més guapos. L’aparell en concret és un UniClass ioPower, crec que serà ideal per un projecte que tinc entremans a més permet enllaçar-lo amb un KVM via IP, impresionant.

Un esquema d’aquests aparells per us domèstic:

Ideal per unir amb el KVM via IP com ja comentava per administradors de xarxes remotes, jo diria que un somni fet realitat:

Features

Compatible to Kripman as a remote power control accessories
Allows full control of 8 A/C power outlets using ASCII commands over a serial interface
Cascadable up to 16 units and control up to 128 AC power outlets
19″ rack-mountable design with metal case
Numerical display to show power module bank number when in multiple cascaded application
Numerical display to monitor total current loads (showing 0.0 ~ 99A)
8 green (ON/OFF) LED indicators to show the ON/OFF status of each A/C power outlet
8 red (Alarm) LED indicators to show the state of failure of each AC power outlet
“One-Touch” power ON/Off control by front-panel buttons