ogni tanto mi torna la voglia di rimettermi a linare, visto che nn posso riprendere in mano il progettone del mio cloud personale ed i sitarelli degli amici sono noiosi (vanno) mi sono rimesso a giocare con il wireless.
dunque:
https://wireless.wiki.kernel.org/en/users/document...
mac80211 Multiple Virtual Interface (vif) Support
The mac80211 subsystem in the linux kernel supports multiple wireless interfaces to be created with one physical wireless card. This depends on the driver implementing this. This could allow you to join multiple networks at once, or connect to one network while routing traffic from an access point interface.

quindi pare proprio che se gli dei dei driver mi sono propizi (su questo particolare device e' ath9k, su un altro device ho una ralink ma di solito intel) potrei avere una interfaccia virtuale che monitorizza le onde radio e le da in pasto a kismet ad esempio e contemporaneamente potrei tenere la connettivita' del portatile, ottimo.
alcuni links
www.candelatech.com/vsta.php
<- howto datato di una societa' che ci fa questi cosi qua con le virtual interface
-> http://www.candelatech.com/ct523-600_product.php
The CT523-600 wireless traffic generator is an excellent choice for testing Access Points and other WiFi networks. The CT523-600 uses a modified Wireless driver for WiFi NICs based on the Atheros chipset. It can support up to 600 Virtual Stations (Up to 200 per radio). Each of the Virtual Stations has its own IP address, IP port space, MAC address and routing table. The Virtual Stations can be assigned to communicate to a particular Access Point, use a particular SSID, and have a WEP (64 or 128bit) or WPA/WPA2 authentication assigned. More advanced 802.1X authentication is also included.
Se i driver e il sw di sistema si stanno simpatici e si vogliono bene si puo fare, ci sono anche howto su come ottenere la cosa con hostapd (un coso che fa un access point software) ma nn li ho letti che erano ancora piu' datati.
a quanto pare cmq dovrebbe essere abbastanza straightforward se supportato dai driver.
la procedura grossomodo dovrebbe essere:
1) creare una interfaccia virtuale con iw
2) dire al sistema di lasciarla in pace
3) attaccarci sopra kismet, hostapd, ghostphisher, etc.
1) creare una interfaccia virtuale su quella fisica (phy0), si puo specificare il tipo tra
* ibss - IBSS/ad-hoc
* mp - Mesh Point
* monitor - Monitor
* ap - Access Point (special steps required)
* station - Station/Client
e nel caso di una interfaccia monitor ci sono un paio di flags possibili:
fcsfail: FCS (Frame Check Sequence) is the checksum of the frame (CRC32), to make sure it was received correctly. By default, a driver should only forward valid frames to the monitor mode interface. This flag allow you to receive frame that also fail the test. One of the use could be monitoring the quality of a wireless network.
control: There are 3 type of frames: data, management and control. Data is pretty obvious. Management help maintain a connection and control (beacons, probe request/response, authentication, association, deauthentication, deassociation, etc). Control help facilitate the transmission of frame between devices (ACK, RTS, CTS, etc). This is hardware-dependent.
otherbss: It would allow receiving frames from other BSS (other than the ones to/from the access point the card is connected to or the clients this access point is serving). This is hardware-dependent.
cook: Refer to a mode for HostAPd where authentication frames that mac80211 didn't actually look at. It is only for ancient versions of HostAPd.
active: ACK is time sensitive and software is too slow to answer it quick enough so this would be done in the hardware itself instead of software. If an ACK is not received within a certain amount of time, the frame will be considered as lost and a new frame with the retry flag will be sent. The only exception would be very long distance links: the longer the links, the longer it takes for a frame to arrive and in some rare cases, software could be fast enough.
edit: il flag in grassetto e' molto strano, in monitor mode una scheda dovrebbe poter ricevere i pacchetti di tutti i bssid, ed in effetti lo fa anche senza il flag otherbss, boh, che dite voialtri al riguardo?
i comandi sono
il risultato sul mio sistema e' che le interfacce vengono aggiunte e sono visibili con iw dev
2) a questo punto si cominciano a verificare i comportamenti strani con i servizi di rete (mainly network manager)
se la periferica virtuale (wlo2) e' in station mode network manager la vede ed il sistema sembra essere felicissimo e capire tutto, una volta aggiunte le periferiche e riavviati i servizi il sistema vede due schede di rete identiche cui puoi cambiare i mac e che si collegano agli AP indipendentemente (nn si collega con un errore strano se cerchi di farle collegare allo stesso AP).
se la periferica virtuale (mon0) e' in monitor mode network manager NON la vede e cmq questa nn va, per fare andare la periferica virtuale in monitor mode devo per forza stoppare tutti i servizi di rete e killare i processi che rischiano di interferire,
oltre a questo c'e' da notare che mon0 funziona solo se e' l'unica cosa che sta facendo la scheda, pur con i servizi/nm spenti se qualcosa legge mon0 iw scan non funziona piu' su wlo1.
porcaccia la pupazza devo poter tenere il network manager avviato e poter dire al sistema di lasciar stare quella periferica, oppure dite che anche se ce la faccio e' una limitazione hw il fatto che non vada in monitor/station mode contemporaneamente? chi vivra' vedra'.
cmq ho letto nella man di nmcli che c'e' questo coso qua
ed in effetti sulla virtual device in station mode funziona, la attivo o disattivo via nmcli ma la device rimane sempre visibile da iw dev, se nn viene managed dal network manager posso comunque usarla con iw (iw scan funziona)
ora pero' scavando nei file di configurazione e documentazione di network manager e wpa_supplicant (che e' dove credevo di dover dire al sistema di non rompere le palle alle virtual device) ho trovato questo:
NetworkManager tries to read and write your distribution's normal network configuration files through plugins called "system settings plugins". A generic plugin called 'keyfile' is also provided to read and write configuration that your distro's native file format cannot handle.
These plugins are configured through the /etc/NetworkManager/NetworkManager.conf configuration file.
ifupdown
This plugin is used on the Debian and Ubuntu distributions, and reads connections from /etc/network/interfaces. Since it cannot write connections out (that support isn't planned) it is usually paired with the 'keyfile' plugin to enabled saving and editing of new connections. The ifupdown plugin supports basic wired and wifi connections, including WPA-PSK.
Persistent Hostname
As the standard location for the persistent system hostname on Debian-base distributions is /etc/hostname, the ifupdown plugin reads the hostname from that location.
Unmanaged Devices
The ifupdown plugin also uses the /etc/NetworkManager/NetworkManager.conf for some configuration. All ifupdown-specific options go in a "[ifupdown]" section. If the "managed" key is set to "false", then any device listed in /etc/network/interfaces will be completely ignored by NetworkManager. Remember that NetworkManager controls the default route, so because the device is hidden, NetworkManager will assign the default route to some other device.
quindi mi sa che devo usare ifupdown in managed=false e dirgli o di ignorare mon0 e wlo2 in /etc/network/interfaces oppure ifupdown in managed=true e dirgli di maneggiare wlo1 in /etc/network/interfaces.
che dite? come proseguo?
**Modificato dall'autore il 10.12.2017 23:07**
dunque:
https://wireless.wiki.kernel.org/en/users/document...

mac80211 Multiple Virtual Interface (vif) Support
The mac80211 subsystem in the linux kernel supports multiple wireless interfaces to be created with one physical wireless card. This depends on the driver implementing this. This could allow you to join multiple networks at once, or connect to one network while routing traffic from an access point interface.

quindi pare proprio che se gli dei dei driver mi sono propizi (su questo particolare device e' ath9k, su un altro device ho una ralink ma di solito intel) potrei avere una interfaccia virtuale che monitorizza le onde radio e le da in pasto a kismet ad esempio e contemporaneamente potrei tenere la connettivita' del portatile, ottimo.
alcuni links
www.candelatech.com/vsta.php
<- howto datato di una societa' che ci fa questi cosi qua con le virtual interface-> http://www.candelatech.com/ct523-600_product.php

The CT523-600 wireless traffic generator is an excellent choice for testing Access Points and other WiFi networks. The CT523-600 uses a modified Wireless driver for WiFi NICs based on the Atheros chipset. It can support up to 600 Virtual Stations (Up to 200 per radio). Each of the Virtual Stations has its own IP address, IP port space, MAC address and routing table. The Virtual Stations can be assigned to communicate to a particular Access Point, use a particular SSID, and have a WEP (64 or 128bit) or WPA/WPA2 authentication assigned. More advanced 802.1X authentication is also included.
Se i driver e il sw di sistema si stanno simpatici e si vogliono bene si puo fare, ci sono anche howto su come ottenere la cosa con hostapd (un coso che fa un access point software) ma nn li ho letti che erano ancora piu' datati.
a quanto pare cmq dovrebbe essere abbastanza straightforward se supportato dai driver.
la procedura grossomodo dovrebbe essere:
1) creare una interfaccia virtuale con iw
2) dire al sistema di lasciarla in pace
3) attaccarci sopra kismet, hostapd, ghostphisher, etc.
1) creare una interfaccia virtuale su quella fisica (phy0), si puo specificare il tipo tra
* ibss - IBSS/ad-hoc
* mp - Mesh Point
* monitor - Monitor
* ap - Access Point (special steps required)
* station - Station/Client
e nel caso di una interfaccia monitor ci sono un paio di flags possibili:
fcsfail: FCS (Frame Check Sequence) is the checksum of the frame (CRC32), to make sure it was received correctly. By default, a driver should only forward valid frames to the monitor mode interface. This flag allow you to receive frame that also fail the test. One of the use could be monitoring the quality of a wireless network.
control: There are 3 type of frames: data, management and control. Data is pretty obvious. Management help maintain a connection and control (beacons, probe request/response, authentication, association, deauthentication, deassociation, etc). Control help facilitate the transmission of frame between devices (ACK, RTS, CTS, etc). This is hardware-dependent.
otherbss: It would allow receiving frames from other BSS (other than the ones to/from the access point the card is connected to or the clients this access point is serving). This is hardware-dependent.
cook: Refer to a mode for HostAPd where authentication frames that mac80211 didn't actually look at. It is only for ancient versions of HostAPd.
active: ACK is time sensitive and software is too slow to answer it quick enough so this would be done in the hardware itself instead of software. If an ACK is not received within a certain amount of time, the frame will be considered as lost and a new frame with the retry flag will be sent. The only exception would be very long distance links: the longer the links, the longer it takes for a frame to arrive and in some rare cases, software could be fast enough.
edit: il flag in grassetto e' molto strano, in monitor mode una scheda dovrebbe poter ricevere i pacchetti di tutti i bssid, ed in effetti lo fa anche senza il flag otherbss, boh, che dite voialtri al riguardo?
i comandi sono
iw phy phy0 interface add wlo2 type station iw phy phy0 interface add mon0 type monitor flags none
il risultato sul mio sistema e' che le interfacce vengono aggiunte e sono visibili con iw dev
2) a questo punto si cominciano a verificare i comportamenti strani con i servizi di rete (mainly network manager)
se la periferica virtuale (wlo2) e' in station mode network manager la vede ed il sistema sembra essere felicissimo e capire tutto, una volta aggiunte le periferiche e riavviati i servizi il sistema vede due schede di rete identiche cui puoi cambiare i mac e che si collegano agli AP indipendentemente (nn si collega con un errore strano se cerchi di farle collegare allo stesso AP).
se la periferica virtuale (mon0) e' in monitor mode network manager NON la vede e cmq questa nn va, per fare andare la periferica virtuale in monitor mode devo per forza stoppare tutti i servizi di rete e killare i processi che rischiano di interferire,
oltre a questo c'e' da notare che mon0 funziona solo se e' l'unica cosa che sta facendo la scheda, pur con i servizi/nm spenti se qualcosa legge mon0 iw scan non funziona piu' su wlo1.
porcaccia la pupazza devo poter tenere il network manager avviato e poter dire al sistema di lasciar stare quella periferica, oppure dite che anche se ce la faccio e' una limitazione hw il fatto che non vada in monitor/station mode contemporaneamente? chi vivra' vedra'.
cmq ho letto nella man di nmcli che c'e' questo coso qua
DEVICE MANAGEMENT COMMANDS
nmcli device {status | show | set | connect | reapply | modify | disconnect | delete | monitor | wifi | lldp}
set [ifname] ifname [autoconnect {yes | no}] [managed {yes | no}]
Set device properties.
ed in effetti sulla virtual device in station mode funziona, la attivo o disattivo via nmcli ma la device rimane sempre visibile da iw dev, se nn viene managed dal network manager posso comunque usarla con iw (iw scan funziona)
ora pero' scavando nei file di configurazione e documentazione di network manager e wpa_supplicant (che e' dove credevo di dover dire al sistema di non rompere le palle alle virtual device) ho trovato questo:
NetworkManager tries to read and write your distribution's normal network configuration files through plugins called "system settings plugins". A generic plugin called 'keyfile' is also provided to read and write configuration that your distro's native file format cannot handle.
These plugins are configured through the /etc/NetworkManager/NetworkManager.conf configuration file.
$ cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile [ifupdown] managed=false
ifupdown
This plugin is used on the Debian and Ubuntu distributions, and reads connections from /etc/network/interfaces. Since it cannot write connections out (that support isn't planned) it is usually paired with the 'keyfile' plugin to enabled saving and editing of new connections. The ifupdown plugin supports basic wired and wifi connections, including WPA-PSK.
Persistent Hostname
As the standard location for the persistent system hostname on Debian-base distributions is /etc/hostname, the ifupdown plugin reads the hostname from that location.
Unmanaged Devices
The ifupdown plugin also uses the /etc/NetworkManager/NetworkManager.conf for some configuration. All ifupdown-specific options go in a "[ifupdown]" section. If the "managed" key is set to "false", then any device listed in /etc/network/interfaces will be completely ignored by NetworkManager. Remember that NetworkManager controls the default route, so because the device is hidden, NetworkManager will assign the default route to some other device.
$ cat /etc/network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback
quindi mi sa che devo usare ifupdown in managed=false e dirgli o di ignorare mon0 e wlo2 in /etc/network/interfaces oppure ifupdown in managed=true e dirgli di maneggiare wlo1 in /etc/network/interfaces.
che dite? come proseguo?
**Modificato dall'autore il 10.12.2017 23:07**
Please consider the environment before printing this message, 50% of the above is useless!
-
-
■ @ 2017-12-13 17:08:24.0 di ::1
-
■ @ 2017-12-15 15:23:58.0 di dada216
-
-
■ @ 2017-12-11 01:28:37.0 di Non Autenticato
-
■ @ 2017-12-11 15:10:25.0 di dada216
-
■ @ 2017-12-12 16:58:32.0 di Non Autenticato
-
-
-