Comutador ethernet RAETH incapaz de receber pacotes / DHCP

0

Eu tenho trabalhado em uma plataforma RALINK comum (MT7621) e tive alguns problemas para fazer com que as portas ethernet recebessem pacotes, o que eu suponho ser a principal razão pela qual eles não podem receber um IP do servidor DHCP (DNSMASQ) no roteador. Não há nada de errado com as portas, e o driver ethernet relata corretamente o Link indo para cima / para baixo quando o cabo é inserido / removido.

Informações do sistema:

root@DD-WRT:~# uname -a
Linux DD-WRT 4.14.19 #946 SMP PREEMPT Wed Feb 14 11:25:30 MST 2018 mips GNU/Linux

Há três itens conectados à interface de ponte 'br0': dois rádios sem fio e o comutador gigabit ethernet:

Interfaces LAN (eth2) / WAN (eth3):

eth2: flags=4163 < UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
      inet6 fe80::7a32:xxxx:xxxx:96fd  prefixlen 64  scopeid 0x20<link>
      ether 78:32:xx:xx:96:fd  txqueuelen 1000  (Ethernet)
      RX packets 0  bytes 0 (0.0 B)
      RX errors 0  dropped 0  overruns 0  frame 0
      TX packets 102  bytes 7444 (7.2 KiB)
      TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
      device interrupt 3  

eth3: flags=4931 < UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,MULTICAST>  mtu 1500  metric 1
      inet6 fe80::7a32:xxxx:xxxx:9700  prefixlen 64  scopeid 0x20<link>
      ether 78:32:xx:xx:97:00  txqueuelen 1000  (Ethernet)
      RX packets 0  bytes 0 (0.0 B)
      RX errors 0  dropped 0  overruns 0  frame 0
      TX packets 13  bytes 1006 (1006.0 B)
      TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ponte:

bridge name     bridge id               STP enabled     interfaces
br0             8000.7832xxxx96fd       no              eth2
                                                        ra0
                                                        rai0

Editar: devo mencionar que não há modem conectado à porta WAN (ou seja, estou apenas tentando obter o DHCP local). o conteúdo de 'route', /etc/resolv.conf e / etc / hosts são os seguintes:

root@DD-WRT:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0

root@DD-WRT:~# cat /etc/hosts
127.0.0.1       localhost
192.168.1.1     DD-WRT
root@DD-WRT:~# cat /etc/resolv.conf 
nameserver 192.168.1.1

Nenhuma interface sem fio tem qualquer problema ao atribuir IPs a dispositivos conectados, levando-me a acreditar que isso está relacionado a algumas mudanças entre o Kernel 3.xe 4.x em relação ao roteamento

Abaixo, forneci o máximo de informações possíveis sobre esse problema. Também mencionarei que os recursos relevantes para este comutador gigabit específico (MT7530) estão ativados (NET_DSA_MT7530, CONFIG_BRIDGE_VLAN_FILTERING, CONFIG_BRIDGE_NETFILTER)

Para garantir que o problema não estava relacionado ao iptables, eu compilei o kernel sem nenhum recurso NAT / IPTABLES / NF e ainda tenho esse problema, o que me leva a acreditar que estou perdendo alguma coisa com relação às "tags vlan ". Eu não desviei do script de configuração do RALINK.

root@DD-WRT:~# cat /proc/net/vlan/config 
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth2.1         | 1  | eth2
eth2.2         | 2  | eth2
eth2.3         | 3  | eth2
eth2.4         | 4  | eth2

onde cada vlan tem a mesma configuração, como segue:

root@DD-WRT:~# cat /proc/net/vlan/eth2.1
eth2.1  VID: 1   REORDER_HDR: 1  dev->priv_flags: 1001
     total frames received            0
      total bytes received            0
  Broadcast/Multicast Rcvd            0

  total frames transmitted           14     
  total bytes transmitted          1076
Device: eth2
INGRESS priority mappings: 0:0  1:1  2:2  3:3  4:4  5:5  6:6 7:7
 EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 

Uma nota adicional: não importa se eu adiciono as vlans (eth2.1, eth2.2, eth2.3, eth2.4) à bridge ou não, o comportamento não muda (o que, eu suspeito, é o comportamento esperado).

aqui estão algumas informações adicionais para pessoas familiarizadas com o programa de comutação do RALINK, apenas para fornecer uma ideia de como o comutador está configurado:

root@DD-WRT:~# switch dump
hash  port(0:6)   fid   vid  age   mac-address     filter my_mac
724:   ---1 ----    0     4  146  406c8xxxx9d2     -     -
found the last entry 1 (not ready)

root@DD-WRT:~# cat /proc/mt7621/port_status 
Port0: LinkDown
Port1: LinkDown
Port2: LinkDown
Port3: LinkUp
Port4: LinkDown

o dispositivo relatado no vid 4 está conectado à porta ethernet 3 (quarta porta, vai 0,1,2,3), o que é correto ao inspecionar o mapeamento vlan abaixo (eth2.4 é vid 4, o vlan para porta 3 no interruptor):

root@DD-WRT:~# switch vlan dump
  vid  fid  portmap    s-tag
    1    0  1-----11       0
    2    0  -1----11       0
    3    0  --1---11       0
    4    0  ---1--11       0
    5    0  ----11--       0
    6    0  invalid
    7    0  invalid
    8    0  invalid
    9    0  invalid
   10    0  invalid
   11    0  invalid
   12    0  invalid
   13    0  invalid
   14    0  invalid  
   15    0  invalid
   16    0  invalid

Se alguém quiser informações adicionais sobre a configuração do kernel e outras coisas, terei prazer em fornecê-la. Como é, não sei o que está faltando. Eu concordo que não sou um especialista quando se trata de redes (embora eu tenha algum conhecimento na área de computação, não apenas este), então eu poderia estar perdendo um simples "echo 1 > / proc / net /" ou algo assim assim.

Para mim, tudo parece correto. Eu só não tenho idéia do porque os pacotes não estão sendo recebidos!

edit (FEB 22 2018): Aqui está uma saída de ethool. se isso ajudar, a porta LAN deve ser "TRGMII" (não tenho certeza se isso é refletido no ethtool, pode não ser), e a porta wan "RGMII":

root@DD-WRT:~# ethtool eth2
Settings for eth2:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full     
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
    Speed: 10Mb/s
    Duplex: Half
    Port: MII
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on
    Link detected: no

o "wan":

Settings for eth3:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 4
        Transceiver: internal
        Auto-negotiation: on
        Link detected: no

e as VLANs:

Settings for eth2.1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Link detected: yes

Vou adicionar mais informações enquanto jogo com o ethtool (novo para isso, desculpe!)

    
por gagan 14.02.2018 / 20:10

0 respostas