Nov 04

InterScan Messaging de TrendMicro problematic amb kernel 2.4 i ECN

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.

Nov 03

PAN IP sobre bluetooth amb Gentoo/Linux

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.

Oct 23

nat traversal

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.

Aug 08

Remote Power Manager

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.

ioPower.jpg

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

mapa1.jpg

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

mapa2.jpg

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