Uma impressora defeituosa não responde às solicitações de ARP. Como falsificar isso de um roteador Linux?

Question

Eu tenho essa impressora idiota que responderá ao ARP apenas de vez em quando (relativamente raramente, às vezes é preciso esperar 5 minutos para obter uma conexão). No entanto, quando eu adiciono seu MAC manualmente à tabela ARP em uma máquina cliente, ele funciona muito bem (responde a pings ICMP, imprime etc. instantaneamente).

Uma solução poderia ser adicioná-lo estaticamente a /etc/ethers em cada máquina cliente. Mas isso provavelmente está errado, já que novas máquinas não poderão aprender sobre isso no futuro.

Esta rede local é executada por um roteador Linux.

Outra solução seria então para esse roteador (10.77.4.1) responder a solicitações ARP direcionadas a essa impressora (10.77.4.5). Eu li alguns manuais e pensei que seria suficiente apenas fazer isso no roteador Linux:

$ sudo arp -i wlan0 -s 10.77.4.5 f4:81:39:86:73:cb pub

… isto é, adicione uma entrada manual ( permanente ) e publicada , mas acontece que a funcionalidade pub nunca funcionou, após o rápido lançamento do Google ™…

Também pensei em usar arping ou arpoison para transmitir o endereço desta impressora, mas eles precisariam fazer isso constantemente (digamos, a cada segundo) para que as coisas funcionassem de maneira confiável. Seria melhor se o roteador respondesse apenas a solicitações .

Como posso fazer isso?

É assim que parece:

# arping 10.77.4.5
ARPING 10.77.4.5
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=0 time=250.435 msec
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout

… e sob o capô:

# tcpdump -i wlp8s0 -v arp
tcpdump: listening on wlp8s0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:34:44.877417 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:45.878547 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:46.879713 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:47.880887 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:48.882064 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:49.883216 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:50.884338 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:51.134742 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.77.4.5 is-at f4:81:39:86:73:cb (oui Unknown), length 28
21:34:51.928209 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:52.886242 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:53.886689 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:54.887869 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:55.889023 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:56.890206 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:57.891361 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:58.892543 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:34:59.893485 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:35:00.894657 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:35:01.895783 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:35:02.896968 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:35:03.898118 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44
21:35:04.899301 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.77.4.5 tell 10.77.4.100, length 44

    

Answer 1

Eu usaria isso como uma desculpa para configurar um servidor CUPS, já que forçar o ARP a funcionar corretamente neste caso de borda em todo o domínio de broadcast tem maior probabilidade de causar confusão se alguma vez precisar ser uma mudança futura das mãos do administrador ou se as redes precisam de refatoração.

Você não só pode consolidar seu plano de gerenciamento de impressão dessa maneira, mas também pode usar o CUPS como um servidor central para endereçamento, permitindo que você concentre qualquer correção ARP em um único servidor. As impressoras que usam vários tipos de conexão podem ser representadas com conexões IPP ou IPPS do CUPS, facilitando muito o gerenciamento de conexões do cliente.

Não tenho certeza se essa é sua única impressora nesse ambiente, mas mesmo se for o CUPS, ainda é uma boa solução para o problema. Alguns detalhes sobre a instalação podem ser encontrados aqui:

link

    

Answer 2

Eu estou supondo que você está olhando para o problema errado. Existe a possibilidade de a impressora estar configurada incorretamente? Se tivesse a subnetmask errada, existe a possibilidade de que algo como este sintoma se manifestasse.

Além disso, qual é a topologia da rede? É estranho que você fale sobre um roteador, mas o ARP é um protocolo da camada 2. A impressora está atrás do roteador? O roteador também está agindo como um switch com algumas interfaces em ponte? Existe outro interruptor envolvido? A impressora e os clientes estão todos conectados ao wlan0 do servidor Linux? O que é a segurança configurada como na rede sem fio com comunicação cliente-cliente?

    

Answer 3

Embora eu ame a idéia aceita do CUPS, o que eu fiz (porque eu sou teimoso e deveria ter sido possível fazer ...: - \ Acontece que foi) foi hackear usando este código: link .

Ele aguardará por uma solicitação e só então responderá, efetivamente evitando que a proteção do kernel do cliente de /proc/sys/net/ipv4/conf/all/arp_accept seja, por padrão, definida como 0 .

O diff pode ser visto aqui: link - meu mod apenas permite configurar qual endereço será falsificado.

O serviço é executado no NixOS, então é muito fácil de configurar: link . Por baixo dessa definição, também decidi fazer ping na impressora a cada dois segundos, para mantê-la viva.

O resultado:

# cat /proc/sys/net/ipv4/conf/all/arp_accept
0

# arp -d 10.77.4.5

# arping 10.77.4.5                          
ARPING 10.77.4.5
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=0 time=2.770 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=1 time=354.998 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=2 time=1.980 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=3 time=2.050 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=4 time=299.506 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=5 time=2.060 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=6 time=2.143 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=7 time=348.676 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=8 time=5.234 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=9 time=1.990 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=10 time=294.930 msec
42 bytes from f4:81:39:86:73:cb (10.77.4.5): index=11 time=6.950 msec
^C
--- 10.77.4.5 statistics ---
8 packets transmitted, 12 packets received,   0% unanswered (4 extra)
rtt min/avg/max/std-dev = 1.980/110.274/354.998/152.334 ms

# arp -n 10.77.4.5
Address                  HWtype  HWaddress           Flags Mask            Iface
10.77.4.5                ether   f4:81:39:86:73:cb   C                     wlp8s0

Esse arping recebeu 4 pacotes extras com RTTs relativamente longos dessa impressora preguiçosa; então ficou mais animado agora.

Mas as coisas estão funcionando maravilhosamente agora! Obrigado a todos.