Mostra notizie nelle discussioni
  • Avatar
    ☺
    Scritto da
    il 2017-12-10 23:02:23.0 alle 2017-12-10 23:02:23.0
    Trollate totali: 6369
    linux wireless (it's that time of the year again?)
    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.


    Sorpresa

    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!
    • Avatar
      Scritto da
      Non Autenticato
      il 2017-12-11 01:28:37.0 alle 2017-12-11 01:28:37.0
      Re: linux wireless (it's that time of the year again?)
      Scritto da: dada216
      > 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.
      >

      >
      > Sorpresa
      >
      > 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?

      UPPETE!!!

      Te lo uppeto così quando la suora passa di qui lo vede, prima se sia sepolto da discussioni su se sia meglio sparare ai musulmani o ai bulli.
    • Avatar
      ☺
      Scritto da
      ::1
      il 2017-12-13 17:08:24.0 alle 2017-12-13 17:08:24.0
      Trollate totali: 12321
      Re: linux wireless (it's that time of the year again?)
      Installa arch Linux. Debian fa troppa roba.
      Young professional woman and busy mom.
      • Avatar
        ☺
        Scritto da
        il 2017-12-15 15:23:58.0 alle 2017-12-15 15:23:58.0
        Trollate totali: 6369
        Re: linux wireless (it's that time of the year again?)
        Scritto da: ::1
        > Installa arch Linux. Debian fa troppa roba.

        anche dicendo a udev di farsi li cazzi sua (tramite systemd) nn e' cambiato nulla.

        N-mila device in station mode funzionano senza problemi.
        ho testato anche multipledevice in AP mode, va e nn va quello, hostapd vede la device ma poi l'AP nn funziona davvero, droppa leconnessioni,nn e'visibile, quando lo e' poi scompare, etc.etc.

        da quanto ho letto sulle mailing list e' una funzionalita' poco usata e molto complicata dagestirenei vari drivers e chi la usa seriamente (comelasocieta' linkata sopra che fa i wireless traffic generator) si modifica kernel e driver appositamente per fare andare tutto.

        a cosa potrebbero servire multiple schede di rete in station mode? collegarsi a due AP e poi?
        Please consider the environment before printing this message, 50% of the above is useless!
<softv>

Pagina generata in 81 millisecondi

Utenti attivi: 12 nell'ultimo minuto, 23 negli ultimi cinque minuti, 52 negli ultimi 15 minuti