Adiciona o segundo IP à interface - Linux (Android)

Question

Eu tenho uma configuração de rede local, como mostrado na figura abaixo

A ponte tem um IP estático configurado para 10.245.245.253/30. Meu dispositivo Android tem um IP configurado para 172.17.2.200 via DHCP. Se eu alterar as configurações de IP da interface para 10.245.245.254/30, ela funcionará.

Mas eu quero ter as configurações de IP do DHCP, mas basta adicionar um endereço IP secundário ou rotear para a interface , para que eu possa acessar a rede e acesse minha bridge ao mesmo tempo.

Eu tentei este comando, mas ainda não funciona.

ip addr add 10.245.245.254/30 dev wlan0

Esta é a minha configuração.

130|shell@msm8916_64:/ # busybox ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
    link/ether 76:0d:fc:b7:9d:4f brd ff:ff:ff:ff:ff:ff
3: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
    link/ether 00:0a:f5:80:c2:50 brd ff:ff:ff:ff:ff:ff
    inet 172.17.2.245/24 brd 172.17.2.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet 10.245.245.254/30 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:f5ff:fe80:c250/64 scope link
       valid_lft forever preferred_lft forever
5: p2p0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq qlen 1000
    link/ether 02:0a:f5:80:c2:50 brd ff:ff:ff:ff:ff:ff

shell@msm8916_64:/ # busybox ip route show
10.245.245.252/30 dev wlan0  src 10.245.245.254
172.17.2.0/24 dev wlan0  src 172.17.2.245  metric 304

shell@msm8916_64:/ # busybox traceroute 10.245.245.253
traceroute to 10.245.245.253 (10.245.245.253), 30 hops max, 38 byte packets
 1  172.17.2.1 (172.17.2.1)  12.263 ms  2.305 ms  2.102 ms

Eu posso fazer ping no meu próprio IP:

130|shell@msm8916_64:/ # ping 10.245.245.254
PING 10.245.245.254 (10.245.245.254) 56(84) bytes of data.
64 bytes from 10.245.245.254: icmp_seq=1 ttl=64 time=0.775 ms
64 bytes from 10.245.245.254: icmp_seq=2 ttl=64 time=0.201 ms

Alguma idéia?

EDIT 1: Para esclarecer a grande figura. A ponte sem fio é o dispositivo que estou desenvolvendo. Será um dispositivo que, ao conectar um cabo ethernet, fornecerá acesso sem fio à rede. Eu não sei nada sobre essa rede. É por isso que desativei o cliente DHCP na minha ponte sem fio, porque não posso ter certeza de que a rede à qual eu o conecto terá um servidor DHCP em funcionamento.

Eu ainda quero ter um endereço IP definido para a ponte sem fio por causa das atualizações de firmware. É por isso que optei por um endereço IP que tem uma chance muito pequena de colidir com qualquer coisa lá fora.

No meu dispositivo Android, desejo ter uma conexão de internet ativa e acesso à minha ponte no mesmo tempo . É por isso que quero adicionar uma rota estática.

Mais alguns detalhes sobre minha configuração

shell@msm8916_64:/ $ busybox ip route get 10.245.245.253
10.245.245.253 via 172.17.2.1 dev wlan0  src 172.17.2.245

E mais alguns

1|shell@msm8916_64:/ $ busybox ip rule
0:      from all lookup local
10000:  from all fwmark 0xc0000 lookup 99
13000:  from all fwmark 0x10063 lookup 97
13000:  from all fwmark 0x10069 lookup 236
14000:  from all lookup 236
15000:  from all lookup 99
16000:  from all lookup 98
17000:  from all lookup 97
19000:  from all fwmark 0x69 lookup 236
22000:  from all lookup 236
23000:  from all lookup main
32000:  from all unreachable

E mais alguns:

shell@msm8916_64:/ # ip route list table main
10.245.245.252/30 dev wlan0  proto kernel  scope link  src 10.245.245.254
172.17.2.0/24 dev wlan0  proto kernel  scope link  src 172.17.2.245  metric 304

shell@msm8916_64:/ # ip route list table local
broadcast 10.245.245.252 dev wlan0  proto kernel  scope link  src 10.245.245.254
local 10.245.245.254 dev wlan0  proto kernel  scope host  src 10.245.245.254
broadcast 10.245.245.255 dev wlan0  proto kernel  scope link  src 10.245.245.254
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
broadcast 172.17.2.0 dev wlan0  proto kernel  scope link  src 172.17.2.245
local 172.17.2.245 dev wlan0  proto kernel  scope host  src 172.17.2.245
broadcast 172.17.2.255 dev wlan0  proto kernel  scope link  src 172.17.2.245

1|shell@msm8916_64:/ # iptables -t main -n -L
iptables v1.4.20: can't initialize iptables table 'main': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

    

Answer 1

Você tem uma configuração de roteamento bastante complicada, com quatro tabelas de roteamento adicionais e regras de roteamento extras para marcas definidas pelo firewall. Este é quase certamente o problema. Então olhe para as tabelas exta ( ip route list table 99 etc.), veja as regras do firewall ( iptables -t table_name -n -L para todo table_name ), então descubra o que está acontecendo.

Editar

Tabelas de roteamento e tabelas de firewall ( iptables ) são completamente diferentes, portanto, iptables -t main -n -L não faz sentido porque main é uma tabela de roteamento, não uma tabela de firewall.

Edite a pergunta com a saída de ip route list table 97 , ip route list table 98 etc. incluindo 99 e 236 . Também com saída de iptables -t filter -n -L , iptables -t nat -n -L etc. incluindo mangle , raw e qualquer outra tabela que possa ser mencionada nas regras. Se a saída for muito longa, coloque tudo em um pastebin e crie um link para ele.

Existem muitos tutoriais na web para iptables e roteamento de políticas se você quiser fazer alguma leitura. Mas, mesmo se descobrirmos o que impede que o segundo endereço se torne o endereço de origem, a tarefa mais difícil é descobrir por que todas essas regras estão lá, o que a pessoa que essas regras desejavam alcançar e como podemos mudar as regras para fazer o segundo endereço funcionar sem quebrar outras coisas.

Então, se você está feliz com a resposta "porque algum tipo de regra de firewall a impede", também podemos deixar por isso mesmo. : -)