Recebendo pacotes UDP do gateway / hotspot

3

Eu tenho uma configuração do Raspberry Pi como um hotspot Wi-Fi (é um servidor DHCP e tem o HOSTAPD em execução). Ele não tem uma conexão com a Internet e não está roteando o tráfego. Os clientes só se conectam à sua rede quando querem se comunicar com ela.

Eu tenho um script python no Raspberry Pi que está enviando uma mensagem UDP ~ 5 segundos.

Eu posso ver os pacotes sendo enviados através do Wireshark (que eu instalei no Raspberry Pi), mas nenhum dos clientes que se conectam à rede do Pi pode ver esses pacotes. É como se eles estivessem chegando a um beco sem saída antes de saírem do Pi.

Também devo mencionar que os clientes têm seus firewalls desativados.

Aqui estão algumas imagens do Pi: Você pode ver o Wireshark mostra os pacotes sendo enviados. Você também pode ver que o BROADCAST está ativado no wlan0.

Ocliente(umcomputadorWindows10,nestecaso)tambémestáexecutandooWiresharkevocêtambémpodeverasinformaçõesderede:

O que estou perdendo na configuração da rede que impede que essa transmissão atinja os clientes? Se eu conectar o Raspberry Pi a um roteador real, os clientes dessa rede poderão ver as mensagens UDP bem. Isso me faz pensar que há algo errado com o hostspot auto-hospedado que eu configurei.

Obrigado por qualquer insight que você possa fornecer.

O conteúdo da configuração do hostapd:

interface=wlan0
driver=nl80211
#driver=rtl871xdrv
ssid=PI032378
channel=6
dtim_period=1
beacon_int=400

Estas são as informações do Wireshark sobre os pacotes que estão sendo enviados, mas não recebidos:

Frame 162: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
    Interface id: 0 (wlan0)
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 21, 2017 16:45:08.000647000 Central Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1487717108.000647000 seconds
    [Time delta from previous captured frame: 0.007711000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 1.299469000 seconds]
    Frame Number: 162
    Frame Length: 60 bytes (480 bits)
    Capture Length: 60 bytes (480 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:data]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Shenzhen_0c:b4:25 (40:a5:ef:0c:b4:25), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: Shenzhen_0c:b4:25 (40:a5:ef:0c:b4:25)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.42.1, Dst: 192.168.42.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 46
    Identification: 0xa04d (41037)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xc420 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.42.1
    Destination: 192.168.42.255
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 44661, Dst Port: 5003
    Source Port: 44661
    Destination Port: 5003
    Length: 26
    Checksum: 0x779c [unverified]
    [Checksum Status: Unverified]
    [Stream index: 3]
Data (18 bytes)
    Data: 426c756562657272793a5049303332333738
    [Length: 18]
    
por Jason Williams 09.02.2017 / 17:42

1 resposta

1

Multicasts e broadcasts no 802.11 devem ser enviados usando um esquema de modulação (taxa de dados) que todo cliente pode receber. Eles devem ser uma das taxas no Conjunto de taxas básicas (taxa obrigatória definida) para essa rede e devem ser criptografados com a chave de grupo e a codificação de grupo dessa rede.

Embora você possa ter um problema de taxa de multicast, se estiver usando criptografia (ou seja, WPA2-PSK), é mais provável que seja um problema de criptografia. Como um teste, tente desativar a criptografia sem fio em sua configuração hostapd e veja se o problema desaparece.

    
por 09.02.2017 / 19:36