JenyaKh's questions

Pressiono o botão esquerdo do mouse e arrasto. Dessa forma, posso selecionar até um pedaço de texto do tamanho de exibição no Xterm e depois copiá-lo (configurei para poder fazer isso com Ctrl + Shift + C).

No entanto, quando começo a rolar com o botão do meio do mouse, a seleção é interrompida. Portanto, não posso selecionar e copiar mais de uma tela. Como isso pode ser curado (sem usar, por exemplo tmux)? Aqui está meu ~/.Xresourcesarquivo abaixo. Obrigado pela atenção!

xterm*selectToClipboard: true
xterm*disallowedWindowOps: 20,21,SetXProp
xterm*faceName: Monospace
xterm*faceSize: 15
xterm*background: black
xterm*foreground: cyan
XTerm*Fullscreen: true
xterm*saveLines: 500000
XTerm*selectToClipboard: true
XTerm*translations: #override \
    Shift Ctrl <Key> C: copy-selection(CLIPBOARD) \n\
    Shift Ctrl <Key> V: insert-selection(CLIPBOARD)

Se eu executar o ifconfig, posso ver que não há endereços ipv6 atribuídos a nenhuma das interfaces. Recebo um erro informando que a família de endereços não é suportada se eu tentar criar o soquete AF_INET6. Eu não tenho a pasta /proc/sys/net/inet6 . A máquina roda o Debian 10 (buster). Em /etc/default/grub não há linhas sobre a desativação do IPv6.

$ uname -r
4.19.52.1.amd64-smp

Você poderia, por favor, dizer como posso habilitar o ipv6? Eu encontro muitos artigos sobre como desativá-lo, mas não como habilitá-lo.

Eu envio dados TCP entre hosts (a topologia é criada usando namespaces de rede e pares de veth). Para um host, salvo seus pacotes de entrada e saída no arquivo pcap usando NFLOG e tcpdump com os seguintes comandos executados no host:

# we turn off checksum offload:
sudo ethtool -K veth0 tx off sg off tso off ufo off

# we log packets with nflog:
sudo iptables -A OUTPUT -j NFLOG --nflog-group 17
sudo iptables -A INPUT  -j NFLOG --nflog-group 17

# we write the packets:
sudo tcpdump -i nflog:17 -w mypcap.pcap

Portanto, para todos os pacotes TCP de saída com Len zero , a soma de verificação está sempre errada. Isso é verdadeiro para todos os hosts na topologia para tráfego de saída . Para o tráfego de entrada não existe esse problema. Isso ocorre porque, como verifiquei (capturando regularmente com tcpdump na interface do host em vez de no NFLOG), quando o tráfego de saída está saindo da interface do host, a soma de verificação já está corrigida.

Pcap no remetente (11.0.0.5), capturado com NLOG:

Pcap no remetente (11.0.0.5), capturado regularmente na interface do remetente:

Pcap no receptor (11.0.0.1), capturado com NLOG:

Pcap no receptor (11.0.0.1), capturado regularmente na interface do receptor:

Então, como você pode ver nas imagens acima, para pcaps capturados do iptables NFLOG, para todos os pcakets TCP de saída que possuem Len igual a zero, o checksum TCP está errado. Qual pode ser a razão?

Obrigado pela atenção!

Eu tenho dois contêineres linux conectados com um veth-pair. Na veth-interface de um container eu configuro o tc qdisc netem delay e envio o tráfego dele para o outro container. Se eu observar o tráfego em ambos os lados usando tcpdump/wireshark, pode-se ver que os carimbos de data e hora do mesmo pacote no remetente e no destinatário não diferem pelo atraso selecionado.

Eu queria entender mais detalhadamente em que ponto a libpcap coloca timestamps para sair do tráfego correspondente a tc qdisc. Procurei um esquema/imagem na Internet mas não encontrei. Eu encontrei este tópico ( wireshark packet capture point ) mas ele aconselha a introduzir uma indireção tendo mais um container/interface. Esta não é uma solução possível na minha situação. Existe alguma maneira de resolver o problema não introduzindo interfaces intermediárias adicionais (ou seja, não alterando a topologia) e apenas gravando na interface veth já fornecida, mas de forma que o atraso possa ser visto?

ATUALIZAR:

Fui muito rápido e me enganei. Nem minha solução presente abaixo (igual à primeira variante de solução da resposta de @AB), nem a solução com IFB de @AB (já verifiquei) resolvem meu problema. O problema está no estouro da fila de transmissão da interface a1-eth0do remetente na topologia:

[a1-br0 ---3Gbps---a1-eth0]---100Mbps---r1---100Mbps---r2

Eu fui muito rápido e verifiquei apenas o atraso de 10ms no link entre o a1-eth0roteador r1. Hoje tentei aumentar o atraso: 100ms, 200ms e os resultados (por pacote de atraso e gráficos de taxa que recebo) começam a diferir para a topologia acima e para a topologia normal:

[a1-eth0]---100Mbps---r1---100Mbps---r2

Então não, certamente, para testes precisos não posso ter links extras: nem introduzidos pela ponte Linux, nem por este IFB, nem por qualquer outro sistema terceiro. Eu testo esquemas de controle de congestionamento. E eu quero fazer isso em uma topologia específica. E eu não posso alterar a topologia apenas por uma questão de plotagem - quero dizer, se ao mesmo tempo meus resultados / gráficos de taxa e atraso forem alterados.

ATUALIZAÇÃO 2:

Então parece que a solução foi encontrada, como pode ser visto abaixo (solução NFLOG).

ATUALIZAÇÃO 3:

Aqui são descritas algumas desvantagens da solução NFLOG (grandes cabeçalhos Link-Layer e checksums TCP errados para pacotes TCP de saída com carga útil zero) e proposta uma solução melhor com NFQUEUE que não tem nenhum destes problemas: Checksum TCP errado para pacotes de saída de comprimento zero (capturado com iptables) . No entanto, para minhas tarefas (teste de esquemas de controle de congestionamento) nem NFLOG, nem NFQUEUE são adequados. Como é explicado pelo mesmo link, a taxa de envio é limitada quando os pacotes são capturados do iptables do kernel (é assim que eu entendo). Então, quando você grava no remetente capturando da interface (ou seja, regularmente) você obtém 2 Gigabytes de despejo, enquanto se você grava no remetente capturando de iptables você obtém 1 Gigabyte de despejo. A grosso modo.

ATUALIZAÇÃO 4:

Finalmente, no meu projeto eu uso a solução de ponte Linux descrita em minha própria resposta abaixo.

Eu tenho o Ubuntu 16.04 LTS com o kernel hwe 4.13.0-39-generic. Eu configuro o par veth no namespace de rede padrão da seguinte forma:

$ sudo ip link add h1-eth0 type veth peer name h2-eth0

$ sudo ip link set dev h1-eth0 up
$ sudo ip link set dev h2-eth0 up

$ sudo ip addr add 10.0.0.1/24 dev h1-eth0
$ sudo ip addr add 10.0.0.2/24 dev h2-eth0

Aqui estão as configurações que recebo após a configuração acima:

$ ifconfig
...
h1-eth0   Link encap:Ethernet  HWaddr ea:ee:1e:bb:66:55  
          inet addr:10.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          ...

h2-eth0   Link encap:Ethernet  HWaddr ba:aa:99:77:ff:78  
          inet addr:10.0.0.2  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          ...

$ ip route show
10.0.0.0/24 dev h1-eth0  proto kernel  scope link  src 10.0.0.1 
10.0.0.0/24 dev h2-eth0  proto kernel  scope link  src 10.0.0.2 
...

Agora eu posso pingar uma interface de outra da seguinte forma:

$ ping -I 10.0.0.1 -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.046 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.046/0.046/0.046/0.000 ms

Mas o primeiro problema é que o ping falha quando tento pingar usando o nome da interface, em vez do endereço IP:

$ ping -I h1-eth0 -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 h1-eth0: 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Como isso pode ser um problema se h1-eth0 tiver o endereço IP 10.0.0.1?

O segundo problema, creio eu, está relacionado. Eu configuro as interfaces da seguinte forma:

$ sudo tc qdisc add dev h1-eth0 root netem delay 60ms
$ sudo tc qdisc add dev h2-eth0 root netem delay 60ms
$ tc qdisc show 
qdisc netem 8006: dev h2-eth0 root refcnt 2 limit 1000 delay 60.0ms
qdisc netem 8005: dev h1-eth0 root refcnt 2 limit 1000 delay 60.0ms

Agora eu pingo novamente com o atraso:

$ ping -I 10.0.0.1 -c4 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.033 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.059 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.027 ms

--- 10.0.0.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3063ms
rtt min/avg/max/mdev = 0.027/0.038/0.059/0.013 ms

E pode-se ver que o rtt não é esperado 60ms*2=120ms. Então parece que tc qdisc netem não funciona para minhas interfaces.

Então, no geral, vejo que minha configuração está de alguma forma quebrada.