JenyaKh's questions

我按下鼠标左键并拖动。这样我就可以在 Xterm 中选择最多一个显示大小的文本，然后复制它（我设置为能够使用 Ctrl+Shift+C 执行此操作）。

但是，当我开始使用鼠标中键滚动时，选择就会停止。所以我无法选择和复制多个屏幕。如何解决这个问题（不使用eg tmux）？下面是我的~/.Xresources文件。感谢您的关注！

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)

如果我运行 ifconfig 我可以看到没有分配给任何接口的 ipv6 地址。如果我尝试创建 AF_INET6 套接字，则会收到一条错误消息，指出不支持地址系列。我没有/proc/sys/net/inet6文件夹。该机器运行 Debian 10 (buster)。在/etc/default/grub中没有关于禁用 ipv6 的行。

$ uname -r
4.19.52.1.amd64-smp

请你告诉我如何启用ipv6？我找到了很多关于如何禁用它而不是如何启用它的文章。

我在主机之间发送 TCP 数据（拓扑是使用网络命名空间和 veth 对创建的）。对于主机，我使用 NFLOG 和 tcpdump 将其入口和出口数据包保存到 pcap 文件，并在主机上执行以下命令：

# 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

因此，对于所有Len为零的传出TCP 数据包，校验和总是错误的。对于出口流量拓扑中的所有主机都是如此。对于传入的流量，没有这样的问题。这是因为，正如我所检查的（通过使用 tcpdump 定期通过主机接口而不是通过 NFLOG 进行捕获），当出口流量离开主机接口时，校验和已经被纠正。

发送方 (11.0.0.5) 的 Pcap，使用 NLOG 捕获：

发送方的 Pcap (11.0.0.5)，在发送方界面定期捕获：

接收器 (11.0.0.1) 处的 Pcap，使用 NLOG 捕获：

接收器 (11.0.0.1) 处的 Pcap，在接收器接口定期捕获：

因此，正如您在上图中所见，对于从 iptables NFLOG 捕获的 pcap，对于 Len 等于 0 的所有出口 TCP pcaket，TCP 校验和是错误的。可能是什么原因？

感谢您的关注！

我有两个用 veth 对连接的 linux 容器。在一个容器的 veth-interface 上，我设置了 tc qdisc netem 延迟并将流量从它发送到另一个容器。如果我使用 tcpdump/wireshark 观察双方的流量，可以看出发送方和接收方的同一数据包的时间戳不会因所选延迟而有所不同。

我想更详细地了解 libpcap 将时间戳放入对应于 tc qdisc 的出口流量。我在互联网上搜索了一个方案/图像，但没有找到。我找到了这个主题（wireshark 数据包捕获点），但它建议通过多一个容器/接口来引入间接性。在我的情况下，这不是一个可能的解决方案。有没有什么方法可以解决这个问题，而不是引入额外的中间接口（即不改变拓扑），并且只通过在已经给定的 veth-interface 上记录但以可以看到延迟的方式来解决这个问题？

更新：

我太快了，所以弄错了。我的解决方案（与@AB 的答案的第一个变体相同）和@AB 的 IFB 解决方案（我已经检查过）都不能解决我的问题。a1-eth0问题是拓扑中发送方接口的传输队列溢出：

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

我太快了，只检查了a1-eth0和 router之间链接的延迟 10ms r1。今天我试图让延迟更高：100 毫秒、200 毫秒，结果（我得到的每个数据包延迟和速率图）对于上面的拓扑和普通拓扑开始有所不同：

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

所以不，当然，对于准确的测试，我不能有额外的链接：Linux 桥、这个 IFB 和任何其他第三方系统都没有引入。我测试拥塞控制方案。我想在一个特定的拓扑中做到这一点。而且我不能仅仅为了绘图而改变拓扑——我的意思是，如果我的速率和延迟结果/图同时发生变化。

更新 2：

所以看起来解决方案已经找到了，如下图所示（NFLOG解决方案）。

更新 3：

这里描述了 NFLOG 解决方案的一些缺点（大的 Link-Layer 标头和错误的 TCP 校验和，用于零负载的出口 TCP 数据包），并提出了一个更好的解决方案，使用 NFQUEUE 没有任何这些问题：零长度出口数据包的 TCP 校验和错误（使用 iptables 捕获）。然而，对于我的任务（测试拥塞控制方案），NFLOG 和 NFQUEUE 都不适合。正如同一个链接所解释的，当从内核的 iptables 捕获数据包时，发送速率会受到限制（这就是我的理解）。因此，当您通过从接口捕获（即定期）在发送方进行记录时，您将获得 2 GB 转储，而如果您通过从 iptables 捕获在发送方进行记录，您将获得 1 GB 转储。大致说来。

更新 4：

最后，在我的项目中，我使用了我自己的答案中描述的 Linux 桥接解决方案。

我有带有 hwe 内核 4.13.0-39-generic 的 Ubuntu 16.04 LTS。我在默认网络命名空间中配置 veth 对，如下所示：

$ 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

这是我在上述配置后得到的设置：

$ 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 
...

现在我可以从另一个接口 ping 一个接口，如下所示：

$ 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

但第一个问题是，当我尝试使用接口名称而不是 IP 地址 ping 时，ping 失败：

$ 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

如果 h1-eth0 的 IP 地址为 10.0.0.1，这怎么会是个问题？

我相信第二个问题是相关的。我将接口配置如下：

$ 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

现在我再次延迟ping：

$ 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

并且可以看出rtt不是预期的60ms*2=120ms。所以看起来 tc qdisc netem 不适用于我的接口。

所以总的来说，我看到我的配置在某种程度上被破坏了。