Autor Tema: parches que vais a necesitar en 3.8 en adelante (Leído 56307 veces)

alist3r · « **Respuesta #40 en:** 01-09-2013, 03:21 (Domingo) »

Cita de: USUARIONUEVO en 01-09-2013, 03:04 (Domingo)

me cague to ,que me lio yo solo. , lo he tirado y estaba bien parcheado. $:-\$

es que sin control de versiones y tocando los ficheros a mano, lo raro es que no nos hagamos más daño!

pero bueno, todo controlado mientras tenga los gists actualizados. no te preocupes que ahi estan todos perfectos.

ya para el final te hago un udiff combinado (bien hecho xD) y te lo guardas como mejor te convenga para cocinar los kernels

USUARIONUEVO · « **Respuesta #41 en:** 01-09-2013, 03:26 (Domingo) »

yo tengo estos, que hacen lo mismo , pero no de dan guerra con lo de espacios en blanco.

Código: [Seleccionar]

--- a/net/mac80211/cfg.c	Tue May 28 16:57:23 2013 -0400
+++ b/net/mac80211/cfg.c	Tue May 28 17:16:15 2013 -0400
@@ -801,3 +801,4 @@
 		}
-	} else if (local->open_count == local->monitors) {
+	// Patch: Always allow channel change, even if a normal virtual interface is present
+	} else /*if (local->open_count == local->monitors)*/ {
 		local->_oper_channel = chandef->chan;
--- a/net/wireless/chan.c	2013-08-29 18:47:51.000000000 +0200
+++ b/net/wireless/chan.c	2013-08-31 22:20:45.014734447 +0200
@@ -441,4 +441,2 @@
 		return -EOPNOTSUPP;
-	if (!cfg80211_has_monitors_only(rdev))
-		return -EBUSY;

Código: [Seleccionar]

--- a/net/mac80211/tx.c	2013-08-29 18:47:51.000000000 +0200
+++ b/net/mac80211/tx.c	2013-08-31 22:35:10.386721602 +0200
@@ -1454,7 +1454,10 @@
 		}
 	}
 
-	ieee80211_set_qos_hdr(sdata, skb);
+	// Don't overwrite QoS header in monitor mode
+	if (likely(info->control.vif->type != NL80211_IFTYPE_MONITOR)) {
+        	ieee80211_set_qos_hdr(sdata, skb);
+	}
 	ieee80211_tx(sdata, skb, false, band);
 }

Código: [Seleccionar]

--- a/drivers/net/wireless/rtl818x/rtl8187/dev.c	2013-08-29 18:47:51.000000000 +0200
+++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c	2013-08-31 22:50:38.266707828 +0200
@@ -252,9 +252,14 @@
 	flags |= RTL818X_TX_DESC_FLAG_NO_ENC;
 
 	flags |= ieee80211_get_tx_rate(dev, info)->hw_value << 24;
-	if (ieee80211_has_morefrags(tx_hdr->frame_control))
-		flags |= RTL818X_TX_DESC_FLAG_MOREFRAG;
 	if (info->control.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS) {
+	if (ieee80211_has_morefrags(tx_hdr->frame_control))
+	{
+      		// If info->control.vif is NULL it's mostly likely in monitor mode
+      		if (info->control.vif != NULL && info->control.vif->type != NL80211_IFTYPE_MONITOR) {
+        		flags |= RTL818X_TX_DESC_FLAG_MOREFRAG;
+      		}
+	}
 		flags |= RTL818X_TX_DESC_FLAG_RTS;
 		flags |= ieee80211_get_rts_cts_rate(dev, info)->hw_value << 19;
 		rts_dur = ieee80211_rts_duration(dev, priv->vif,

USUARIONUEVO · « **Respuesta #42 en:** 01-09-2013, 03:38 (Domingo) »

el segundo y tercero son los tuyos que si aplican bien , fragmentacion y el de realtek.

y el primero , es la union de las dos funciones ...este a mi me va perfecto. ( el del post anterioe en el que te puse mis tres patch , los tres perfectos, 2 y 3 tuyos y el 1 , es un variante pero hacen lo mismo ,solo que el tuyo directamente elimina la funcion , y el mio la deja comentada e inutilizada. )

el de channel que tienes ahora mismo en el git ...ahora esta peor que antes ...

alist3r · « **Respuesta #43 en:** 01-09-2013, 04:02 (Domingo) »

no se si debo tomar como guia tu aplicación del parche, o la mia.
la mia es perfecta en unas fuentes limpias.

prueba usando
patch -p1 < ruta/hacia/el/parche
porque es la unica diferencia que tenemos

en cualquier caso, sigamos mantendiendo el contro del código y una sola version de los parches, aunque luego haya que reparar saltos de linea o cosas raras.

no se por que te pasa, he recreado los parches sin hacer un solo copypaste ni tocar nada a mano.

USUARIONUEVO · « **Respuesta #44 en:** 01-09-2013, 04:38 (Domingo) »

Bueno , pues kernel compilado ..y nada.

debe haber mas rutinas de comprobaciond e channel ...de hecho vi una interesante ..si la localizo lo posteo.

alist3r · « **Respuesta #45 en:** 01-09-2013, 04:40 (Domingo) »

aunque ahora no puedo cortar la conexion porque estoy haciendo otra tarea, en cuanto pueda, voy a reproducir el error y obtener logs.
si tu mientras tanto tienes algunos, pásamelos por privado.

USUARIONUEVO · « **Respuesta #46 en:** 01-09-2013, 04:47 (Domingo) »

tengo sospechas acerca de esta funcion , en el cfg.c

static int ieee80211_cfg_get_channel(struct wiphy *wiphy,
              struct wireless_dev *wdev,
              struct cfg80211_chan_def *chandef)
{
   struct ieee80211_sub_if_data *sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
   struct ieee80211_local *local = wiphy_priv(wiphy);
   struct ieee80211_chanctx_conf *chanctx_conf;
   int ret = -ENODATA;

   rcu_read_lock();
   chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
   if (chanctx_conf) {
      *chandef = chanctx_conf->def;
      ret = 0;
   } else if (local->open_count > 0 &&
        local->open_count == local->monitors &&
        sdata->vif.type == NL80211_IFTYPE_MONITOR) {
      if (local->use_chanctx)
         *chandef = local->monitor_chandef;
      else
         *chandef = local->_oper_chandef;
      ret = 0;
   }
   rcu_read_unlock();

   return ret;
}

alist3r · « **Respuesta #47 en:** 01-09-2013, 04:54 (Domingo) »

jajaja
lo has clavao tio.
hay una discriminación clarisima.
voy a machacarla.

EDIT:
claro, devuelve un -ENODATA, que es un -61 segun las defs del kernel

en el caso de aircrack, este pregunta al sistema mediante el "ioctl" correspondiente en qué canal estamos. Si recibe un numero negativa (como es el caso de -ENODATA) se sobreentiende que los negativos estan reservados a errores, y en caso de este error, aircrack devuelve el famoso -1 que vemos, con la excepcion de que si está activado el ignore-negative-one, simplemente ignora el problema y no reporta nada, ni canal, ni numero negativo de error.

NOTA
Cada vez que veas referencias a LOCAL -> BLA BLA BLA; mírate la tabla de referencia de ese struct para comprender de qué va. Es como un array de configuración de la interfaz.
http://kerneldox.com/kdox-ubuntu-natty/de/d22/structieee80211__local.html

USUARIONUEVO · « **Respuesta #48 en:** 01-09-2013, 05:06 (Domingo) »

Cita de: alister en 01-09-2013, 04:54 (Domingo)

jajaja
lo has clavao tio.
hay una discriminación clarisima.
voy a machacarla.

es lo que dije , yo "creo ver donde estan los problemas" ,pero al no entender el code , no puedo hacer nada por remediarlo.

a parte de esta , no vi ninguna mas ... ojala sea esta la ultima vez que comprueban los canales, por que me lleva frito este tema desde principios de año.

mientras , voy a fulminar el 3.10.10 , y regresar a mi 3.6.11 para recompilar again , cuando tengas listo el nuevo patch.

USUARIONUEVO · « **Respuesta #49 en:** 01-09-2013, 05:21 (Domingo) »

Te pongo una captura para que veas lo que busco ... ( en realidad siempre funcionaron asi , hasta los 3.8 que empezaron a envenenar con restricciones de canal. )

fijate que wlan y mon , estan las dos up ...y aun asi airodump , no tiene problemas.

alist3r · « **Respuesta #50 en:** 01-09-2013, 06:06 (Domingo) »

tengo que estudiar estos commits

https://github.com/torvalds/linux/commit/b4a7ff75ba3545b061d4fe63f0bb9136ccfe8b19
https://github.com/torvalds/linux/commit/4bf88530be971bf95a7830ca61b4120980bf4347

USUARIONUEVO · « **Respuesta #51 en:** 01-09-2013, 06:17 (Domingo) »

Cita de: alister en 01-09-2013, 06:06 (Domingo)

https://github.com/torvalds/linux/commit/b4a7ff75ba3545b061d4fe63f0bb9136ccfe8b19

No lo entiendo ....

parece que ese patch , ya viene aplicado, asi que ... ¿ reverse ?

USUARIONUEVO · « **Respuesta #52 en:** 01-09-2013, 07:27 (Domingo) »

me voy a mimir , ya revisare el post a la tarde.

alist3r · « **Respuesta #53 en:** 01-09-2013, 13:13 (Domingo) »

hi
perdona que con las prisas no explico.

esos commits, tengo que analizarlos bien porque estan cambiando profundamente la forma en la que se comporta el stack wireless y revertirlos no es una opción valida porque estan creando una api nueva llamada "contexto de canales". ha conllevado modificaciones en drivers wireless y ha venido para quedarse, asi que tenemos que tocar con cuidado, y revertirlo nos condenaria a separarnos enormemente de maintree. no es una opcion.

alrededor de estos commits estan los cambios que ahora molestan. pero por lo menos es un alivio comprobar que la intencion, segun los commits, no era fastidiar las interfaces en modo monitor, sino ampliar el funcionamiento general del stack wireless.

alist3r · « **Respuesta #54 en:** 01-09-2013, 14:37 (Domingo) »

leete esto
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/105347

es exactamente lo que pasa ahora mismo, desde que se introdujeron los channel_ctx

la interfaz esta en modo monitor
el kernel no tiene en cuenta los nuevos channel contexts cuando la interfaz esta en modo monitor
si el driver de esa interfaz es compatible con los channel contexts y estos han sido creados, entonces ieee80211_cfg_get_channel intenta llamar al ioctl(i/o control) llamado SIOCGIWFREQ, y como este devuelve un -ENODATA (negativo), aircrack lo traduce en un -1.

el uso o no uso de de contextos es el motivo por el cual a mi no me afecta. depende del driver. la gente de intel ha modificado algunos drivers para adaptarlos al channel_ctx, mientras que otros no.

(la gente de intel no solo hace los drivers intel del kernel. tambien tienen mucho peso en el desarrollo del stack wireless)

EDIT
Como habrás visto la actualización del primer post, en el lab tenemos dos interfaces ath9k y rtl8192se y ambas nos va perfectamente en el kernel parcheado, así que ya no podemos hacer más pruebas. Solo puedo aportar e análisis del código y propuestas de parches para que otros los prueben.

Te recomiendo que te instales el GITK y lo uses para navegar por la historia de commits que existen entre las versiones 3.7 y 3.8, Te ayudará a entender qué cambios se han hecho al kernel, qué los há motivado, y en qué nos afecta.

alist3r · « **Respuesta #55 en:** 01-09-2013, 18:45 (Domingo) »

bueno, esto deberia funcionarte.

2 - Prevenir el negative one en aicrack - parte 2 - Habilita la consulta al channel_ctx por parte de SIOCGIWFREQ incluso en modo monitor (necesario para algunos drivers)
https://gist.github.com/alist3r/6405555

Al menos lo ha hecho para Clay McPherson, aunque no sé qué driver utiliza él, pero le puedo preguntar.

USUARIONUEVO · « **Respuesta #56 en:** 01-09-2013, 21:31 (Domingo) »

alist3r , si yo tengo un ar9285 y me pasa .... $:-\$

probare este ultimo parche que pones.

""" tal vez """ , hay algun otro parametro en mi configuracion de kernel ....que pueda culparse de ese comportamiento.

aqui dejo mi config del 3.10.10 -->> http://www.multiupload.nl/K0CG41QX36

la suite aircrack ,la compilo con este parametro ...que igual tiene que ver tambien

make libnl=true

Tras "quitar" el espacio en blanco de la ultima linea del patch nuevo ..ya los aplique todos ...COMPILANDO .. aver que sale de esta.

alist3r · « **Respuesta #57 en:** 01-09-2013, 21:38 (Domingo) »

Cita de: USUARIONUEVO en 01-09-2013, 21:31 (Domingo)

alist3r , si yo tengo un ar9285 y me pasa .... $:-\$

WTF!!

Citar

""" tal vez """ , hay algun otro parametro en mi configuracion de kernel ....que pueda culparse de ese comportamiento.

no veo nada en el código que sugiera esa posibilidad, de momento. seguiré mirando.

bueno, aplica este ultimo parche numero 4 que he puesto en la lista, y me cuentas? otra cosa, de momento, no te puedo decir...

USUARIONUEVO · « **Respuesta #58 en:** 01-09-2013, 21:43 (Domingo) »

modifique en penultimo post con algo mas de info , de como compilo aircrack ... y añadi la config del kernel ...

el uso de libnl podria tener culpa de algo ?¿ ..en el kernel lo tengo habilitado ,creo recordar.

USUARIONUEVO · « **Respuesta #59 en:** 01-09-2013, 22:09 (Domingo) »

Por pura curiosidad ,probe los patches contra el 3.11-rc7 y aplican todos ....a ver si hay suerte y si se arregla todo al menos se que las ramas 3.10 y 3.11 las tengo aseguradas ( en caso de que el patch 4 de resultados positivos )

Noticias:

Autor Tema: parches que vais a necesitar en 3.8 en adelante (Leído 56307 veces)

alist3r

alist3r

alist3r

alist3r

alist3r

alist3r

alist3r

alist3r

alist3r