El Fri, 17 Oct 2014 20:23:54 +0200, José Miguel (sio2) escribió: > El Fri, 17 de Oct de 2014, a las 04:22:22PM +0000, Camaleón dijo: > >> Con la opción b) puedes decirle que envíe como UID la dirección MAC >> editando manualmente el campo desde los clientes lo que a todos los >> efectos sería como si sólo se le enviara un dato,o al menos als ervidor >> sólo le llegaría el mismo dato (UID → dirección MAC o MAC → dirección >> MAC). > > No son datos distintos: la MAC es una cosa y el UID es otra, que se > envían en campos distintos del paquete DHCPREQUEST. De hecho, de modo > predeterminado ocurre lo que tú dices: que el UID vale lo mismo que la > MAC. Pero a pesar de ello un cliente que envía un UID(=MAC) y una MAC se > considera distinto al que no envía UID y sí la misma MAC (que es dato > que siempre se envía).
La idea central es que al servidor le llegue el mismo identificador (UID=MAC) para que el servidor trabaje siempre con ese dato y que pueda aplicar la configuración que necesite en base a ese identificador. >> ¿Seguro? Si fuerzo una petición de IP desde el cliente (dhclient -r) me >> da una IP distinta de la que aparece en el archivo "/var/lib/dhcp/ >> dhclient.leases" :-? > > En todo momento estoy hablando de ifup/ifdown que internamente usan > dhclient. En cualquier caso, he mirado el manual y "dhclient -r" no pide > ip, sino que para el cliente enviando al servidor una notificación para > que libere la ip. Como con ifdown ocurre esto, supongo que ipdown usará > esta opción "-r". Si usas Network-Manager ifup/down no es el comando apropiado para configurar la interfaz de red (independientemente de que lo ejecute N-M como parte de su rutina). Y obviamente cuando se libera una IP el cliente pide otra al servidor, al menos eso es lo que aparece en el syslog cuando ejecutas el comando. > Si el cliente vuelve a pedir la ip y nadie recibió esa ip entre el > momento en que se liberó y el que se ha vuelvo a pedir, se le concede la > misma, porque el cliente le sugiere al servidor que se la dé. Esa es mi > experiencia: no he hecho pruebas exhaustivas, que tampoco vienen mucho a > cuento, porque en nada cambian el problema con "deny duplicates". Ya te digo que ese no es comportamiento que veo en mi netbook (con N-M y dhcp) y no tengo ninguna configuración especial en el servidor dhcp. >> No sé qué decirte... ¿es posible que esa opción sea aplicable sólo a >> clientes que usan BOOTP? > > La estructura del paquete DHCPREQUEST que te envié yo era de un artículo > sobre el protocolo DHCP. La opción 50 que mencionabas en el correo anterior es una extensión del protocolo relacionada con BOOTP, por eso te lo decía. >> No sé... yo sigo pensando que si el cliente no pide otra IP al servidor >> no volverías a tener problemas porque mantendría la misma durante toda >> la sesión, salvo, efectivamente que el equipo reiniciara o recargara el >> demonio de la red y no tuviera información alguna de los leases que >> como dices más arriba, > > Es que el problema no se produce mientras se está usando un ordenador y, > de repente, se queda uno sin ip. El problema se produce porque se está > usando un ordenador en windows (o se estuvo usando hace sólo unas horas > por lo que la concesión de ip no ha caducado) y se reinicia en linux o > se reinicia para arrancar por red. De ahí la importancia de que el cliente se identifique (UID o MAC) siempre de la misma forma tanto en linux como en windows para que el servidor le dé la misma IP. Y si ambos sistemas mantienen los leases que han recibido, siguiendo con tu argumento de que los clientes siempre piden la última IP que tienen almacenada, tendrían que recibir la misma y no renovarla. >> Pero eso no ataca el problema de fondo que es evitar que los clientes >> pidan (u obtengan) direcciones distintas cada vez. > > Es que ese no es el problema que quiero resolver: a mí me trae sin > cuidado que un ordenador no reciba siempre la misma ip: para eso ya está > fixed-address. Lo que yo quiero impedir es que un cliente (entendiendo > por cliente una ordenador con una tarjeta de red) acapare dos ips a la > vez: una que le dieron cuando ejecutaba windows y que no está libre > porque no ha acabado la concesión, y otra que usa en el presente porque > está ejecutando linux. Con el "deny duplicates" entiendo que el cliente va a tener (o puede tener) siempre dos IP asociadas, así que tampoco te serviría. Sigo pensando que la mejor forma de ver cómo funciona o qué es lo que hace esa opción es probándola y analizando el syslog del cliente para ver qué IP recibe con cada reinicio. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.10.18.15.49...@gmail.com