组播分片报文重组后丢包问题（后续）

于 2022-10-04 16:35:23 发布
阅读量744 收藏
点赞数
分类专栏： linux arm 文章标签： 网络 linux 服务器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xqjcool/article/details/127156871
版权
linux 同时被 2 个专栏收录
12 篇文章 0 订阅
订阅专栏
arm
5 篇文章 0 订阅
订阅专栏

组播分片报文重组后丢包问题（后续）

上篇组播分片报文重组后丢包问题，分析到最后是接口eth0和eth1在同一个广播域，且两个接口都处于混杂模式导致。

解决方案是关闭接口的混杂模式。

尝试清除IFF_PROMISC失败

于是想清除IFF_PROMISC标志，验证问题是否消失。

手动echo设置清除

手动清除失败，但其他标志位可以成功清除。看起来像是IFF_PROMISC被设定不可清除。

root@test:~# cat /sys/class/net/eth0/flags 
0x1103
root@test:~# echo 0x1003 > /sys/class/net/eth0/flags  //尝试清除IFF_PROMISC失败
root@test:~# cat /sys/class/net/eth0/flags 
0x1103
root@test:~# 
root@test:~# echo 0x1102 > /sys/class/net/eth0/flags   //清除IFF_UP成功
root@test:~# cat /sys/class/net/eth0/flags 
0x1102
root@test:~# echo 0x103 > /sys/class/net/eth0/flags   //清除IFF_MULTICAST成功
root@test:~# cat /sys/class/net/eth0/flags 
0x103

最为对比 eth2接口的IFF_PROMISC标志就可以成功设置和清除。

root@test:~# cat /sys/class/net/eth2/flags 
0x1003
root@test:~# echo 0x1103 > /sys/class/net/eth2/flags
root@test:~# cat /sys/class/net/eth2/flags 
0x1103
root@test:~# echo 0x1003 > /sys/class/net/eth2/flags
root@test:~# cat /sys/class/net/eth2/flags 
0x1003

通过ioctl接口设置清除

手动设置清除不行，于是尝试使用ioctl接口设置清除。写了个change工具通过ioctl设置SIOCGIFFLAGS。
经过验证，结果和手动设置相同。无法修改接口eth0和eth1的IFF_PROMISC标志，但可以修改其他标志位。

root@test:~# cat /sys/class/net/eth0/flags 
0x1103
root@test:~# ./change eth0 8
root@test:~# cat /sys/class/net/eth0/flags 
0x1103

root@test:~# ./change eth0 0
root@test:~# cat /sys/class/net/eth0/flags 
0x1102
root@test:~# ./change eth0 0
root@test:~# cat /sys/class/net/eth0/flags 
0x1103

root@test:~# ./change eth0 12
root@test:~# cat /sys/class/net/eth0/flags 
0x103
root@test:~# ./change eth0 12
root@test:~# cat /sys/class/net/eth0/flags 
0x1103

作为对比，eth0是可以设置清除IFF_PROMISC

//eth2 可以正常设置和清除IFF_PROMISC标志
root@test:~# cat /sys/class/net/eth2/flags 
0x1003
root@test:~# ./change eth2 8           //设置IFF_PROMISC
root@test:~# cat /sys/class/net/eth2/flags 
0x1103
root@test:~# ./change eth2 8          //清除IFF_PROMISC
root@test:~# cat /sys/class/net/eth2/flags 
0x1003

分析驱动代码

一度怀疑是驱动代码逻辑写死IFF_PROMISC不允许修改，随即就推翻了。因为eth2接口是相同的驱动，但IFF_PROMISC标志可以随意设置清除。
稳妥起见还是查阅了驱动代码，没有发现特殊逻辑。

虚拟vlan配置

固件团队分析到后面发现了原因。问题的引入来自于之前一次新增vlan操作。
eth0新增了eth0.10虚拟vlan，配置的 mac地址和eth0不一样，eth1新增了eth0.20虚拟vlan，配置的mac地址和eth1的mac不一样。
eth0 mac地址是70:b3:d5:20:00:21，但eth0.10地址是70:b3:d5:21:64:00。
eth1 mac地址是70:b3:d5:20:ff:21，但eth1.20地址是70:b3:d5:21:c8:01。

root@test:~# ifconfig eth0
eth0: flags=4419<UP,BROADCAST,RUNNING,MULTICAST>  mtu 8966
        inet 10.84.10.42  netmask 255.255.255.0  broadcast 10.42.10.255
        inet6 fe80::72b3:d5ff:fe20:21  prefixlen 64  scopeid 0x20<link>
        ether 70:b3:d5:20:00:21  txqueuelen 1000  (Ethernet)
        RX packets 224529948  bytes 178857830781 (178.8 GB)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 305526669  bytes 131688196359 (131.6 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@test:~# ifconfig eth0.100
eth0.10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 8966
        inet 192.168.10.42  netmask 255.255.255.0  broadcast 192.168.100.255
        inet6 fe80::72b3:d5ff:fe21:6400  prefixlen 64  scopeid 0x20<link>
        ether 70:b3:d5:21:64:00  txqueuelen 1000  (Ethernet)
        RX packets 16276987  bytes 6107515472 (6.1 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 275497881  bytes 117600578758 (117.6 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@test:~# ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1466
        inet 10.84.0.42  netmask 255.255.255.0  broadcast 10.42.0.255
        inet6 fe80::72b3:d5ff:fe20:ff21  prefixlen 64  scopeid 0x20<link>
        ether 70:b3:d5:20:ff:21  txqueuelen 1000  (Ethernet)
        RX packets 233679757  bytes 181307309357 (181.3 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 62101583  bytes 5165309302 (5.1 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@test:~# ifconfig eth1.200
eth1.20: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1466
        inet 192.168.20.42  netmask 255.255.255.0  broadcast 192.168.200.255
        inet6 fe80::72b3:d5ff:fe21:c801  prefixlen 64  scopeid 0x20<link>
        ether 70:b3:d5:21:c8:01  txqueuelen 1000  (Ethernet)
        RX packets 3808158  bytes 517024458 (517.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3828411  bytes 578738870 (578.7 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

由于eth0.10 的报文 要通过真实物理网口 eth0接收，而eth0的mac地址和eth0.10mac地址不同。为了能够接收发向eth0.10mac地址的报文。eth0需要设置成 IFF_PROMISC 模式。

检查多mac地址的代码逻辑在__dev_set_rx_mode中。
当dev->priv_flags没有设置 IFF_UNICAST_FLT时，会设置IFF_PROMISC标志。
在这里插入图片描述

至此，eth0和eth1为何IFF_PROMISC标志位设置的原因也找到了。

修改配置并验证

修改eth0.10 mac地址

手动修改eth0.10 mac地址，使其与eth0一致后。可以看到eth0的flags中 不再包含IFF_PROMISC标志。

root@test:~# cat /sys/class/net/eth0/flags 
0x1003
root@test:~# ifconfig eth0.10 down
root@test:~# ifconfig eth0.10 hw ether 70:b3:d5:20:00:21
root@test:~# ifconfig eth0.10 up
root@test:~# cat /sys/class/net/eth0/flags 
0x1003

验证组播

使用test程序验证，发现不再有丢帧问题。

root@test:~# ./test 239.0.0.15 1067 10.84.0.42
UDP Server 239.0.0.15: 1067
recv from: 10.84.0.73:1067  805583  c4acf
recv from: 10.84.0.73:1067  805584  c4ad0
recv from: 10.84.0.73:1067  805585  c4ad1
recv from: 10.84.0.73:1067  805586  c4ad2
recv from: 10.84.0.73:1067  805587  c4ad3
recv from: 10.84.0.73:1067  805588  c4ad4
recv from: 10.84.0.73:1067  805589  c4ad5
recv from: 10.84.0.73:1067  805590  c4ad6
recv from: 10.84.0.73:1067  805591  c4ad7
recv from: 10.84.0.73:1067  805592  c4ad8
recv from: 10.84.0.73:1067  805593  c4ad9
recv from: 10.84.0.73:1067  805594  c4ada
recv from: 10.84.0.73:1067  805595  c4adb
recv from: 10.84.0.73:1067  805596  c4adc
recv from: 10.84.0.73:1067  805597  c4add

验证通过。

浮沉飘摇
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
UDP录制 支持单播和组播 支持保存文件分片
10-27
接收UDP组播流，适合TS录制用，支持分片
关于rtp组播丢包的问题分析
06-25 2031
今天在排查组播丢包的时候，发现相机在对准静态高细节图片的时候，会出现丢帧，排查发现调用sendto失败，返回EAGAIN错误，之前一直以为只有tcp发送才会出现EAGAIN错误，今天又仔细研究了一下，返回EAGAIN是发生在非阻塞操作，所有非阻塞操作都需要处理这个错误。应该是应该是限定码流下，p帧比较小，为了维持码率，i帧就会比较大，出现大i帧，导致udp的发送缓冲满了，而动态画面下，因为p帧平均...
UDP丢包原因
weixin_30588675的博客
10-04 474
一、主要丢包原因 1、接收端处理时间过长导致丢包：调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv。 2、发送的包巨大丢包：虽然send方法会帮你做大包切割成小包发送的事情，但包太大也不行。例如超过50K的一个udp包，不切割直接通过sen...
组播分片报文重组后丢包问题
09-29 1339
eth0和eth1在相同的广播域，且开启了混杂模式。业务组播分片报文，在两个接口都会收到。当同一个大包的多个分片在eth0和eth1上产生重组冲突，协议栈会丢包，导致业务收不到。
组播数据包丢失故障排除指南
sunny_98_98的博客
01-29 3554
介绍 本文档的目的是帮助找出丢失组播数据包的原因并进行一些调整以尽量减少此类丢失。 组播数据包丢失的原因有多种。 UDP 协议本身牺牲了性能的可靠性，并且不保证数据报的传递。 因此，数据包在网络传输过程中可能会丢失。 即使数据包到达网络节点，也并不总是意味着应用程序接收到它，因为在处理接收到的数据包时会经过几个级别，在每个级别上都可能会丢失。 网络数据包的典型路径如图 1 所示。 图1 首先，网络适配器（NIC）接收并处理网络数据包。 NIC 有自己的硬件环形缓冲区。当网络数据流高于 NIC 可以处理时，
linux 网卡丢弃多播包,linux多网卡接收组播丢失问题
weixin_32369749的博客
05-02 491
工作中曾遇到一个很奇怪的问题，我奉命调查。事情是这样的，有一台双网卡的机器，上面装有Fedora8，运行一个程序。该程序分别在两个网口上都接收多播数据，程序运行是正常的。但是，后来升级系统到Fedora13，发现就出问题了：在运行几秒钟后，第2个网口上就接收不到多播数据了。能不能收到多播，取决于交换机是不是往这个网口上转发多播数据。程序在起动的时候，会发一个IGMP的Add Membership的...
UDP丢包
Jasmine's Linux World
06-17 7917
UDP丢包 我们是后一个包丢掉了   最近在做一个项目,在这之前,做了个验证程序. 发现客户端连续发来1000个1024字节的包,服务器端出现了丢包现象. 纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了. 有没有成熟的解决方案来解决这个问题. 我用过sleep(1),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多,网络情况不太好的话,还是有可能
IPv6分片报文
07-21
IPv6分片报文，研究 IPv6协议扩展头部的时候可以使用。
rtp.rar_rtp_rtp session_rtp报文解析_rtp模块_丢包
09-23
rtp模块， 包括rtp协议报文组包，解析，功能独立，需要自行添加rtp的session管理
ip分片重组及tcp分段重组具体实现
01-31
tcp/ip协议中ip分片重组以及tcp分段重组具体实现原理
lvs 转发后端时丢包并返回icmp need fragment 报文
12-27
lvs 转发后端时丢包并返回icmp need fragment 报文，使用lvs + keepalived 套件实现高可用和负载均衡功能，读vip链路上有连接失败，链路超时等异常，原因是操作系统的RHEL6.3内核lvs组件与网络gro/gso机制配合存在...
windows下报文回放、抓包、分析工具
10-13
windows下好用的报文回放、抓包工具，非常简单好用，本人已经亲自试验过。不用再费劲去搞tcpreplay啦
[内存泄漏]docker使用cgroup memory导致的内存泄漏
03-30 5520
docker使用cgroup memory导致的内存泄漏1. 问题现象及分析1.1 问题现象1.2 问题分析2. 解决办法和尝试2.1 升级到修复后的版本。2.2 禁用cgroup的kmem属性。3. 方案无效及分析3.1 确认内核是否支持该选项3.2 新的解决方案太长不看版本 1. 问题现象及分析 1.1 问题现象 公司产品（centos 3.10.0-514）需要用频繁启动docker，每个docker的运行时间不固定，一段时间后设备内存不足。 使用内存泄漏分析工具（传送门https://blog.cs
[内存泄漏]kmalloc-128 slab内存泄漏定位过程
03-17 2892
kmalloc-128 slab内存泄漏定位过程问题现象进展受阻现网排查分析coredump后记 问题现象 前几天，技术团队告知，线上几台ARM CentOS设备内存占用高，比其他相同设备占用高约200M。 查看 free，meminfo和slabinfo后，怀疑是slab kmalloc-128存在内存泄漏。 进展受阻 我们发现正常设备和内存占用高设备的 kmalloc-128 占用已经超过177万，粗算下来200多M，刚好是多占用的内存大小。 //异常设备的slab kmalloc-128
Linux syslog换行符不生效问题
03-26 1506
项目中需要使用syslog打印带有换行符’\n’的字符串，期望能够在log里将其分行打印。结果打印出来全在一行内，换行符被以’#012’替代。 为了验证问题，简单写了个测试代码： #include <syslog.h> int main(int argc, char *argv[]) { openlog("testlog", LOG_PID, LOG_LOCAL2); syslog(LOG_INFO, "aaaa\nbbbb\n"); closelog();
项目中遇到的pthread_cond_signal/pthread_cond_timedwait使用问题
04-08 1203
问题现象 项目上遇到一个问题，报文交互经常延时过高，客户非常不满。 初步抓包分析 通过抓包发现问题出在从物理口收包到我们模块处理时。也就是说不是网络中异常导致的延时过高。是我们处理过程中产生的。但是但从抓包很难确认延时产生在什么位置。需要进一步确认。 报文打点确认 于是对报文进行了处理，使其记录timestamp，然后在各个关键位置判断当前时间和报文timestamp的差值，如果超过一定范围，则通过log打印出来。 通过打点，确认问题发生在 业务模块将 报文放入队列，到主线程从队列取包处理时。 这部分的简单
[内存泄漏]keepalived进程内存泄漏定位
08-28 805
缘起 公司部分项目在部署上通过keepalived实现了了双机热备，通过荣誉和接管，实现高可用性。 最近其中一个项目出现了内存耗尽问题，使用<内存问题快速定位工具>定位提示是keepalived进程的rarp socket收报队列挤压了太多数据包导致。 该工具可以快速定位大多数内存问题，详细介绍文档见《内存泄漏定位思路和方法》，在此不再赘述。 分析 keepalived我们用的是v2.0.10版本，...
linux meminfo VmallocUsed为0问题
06-08 740
为了便于定位内存问题，使用/proc/meminfo中的一些关键变量值，来计算用户态内存占用，内核态内存占用（包含slab占用和vmalloc占用等），以及黑洞内存占用。(详见内存泄漏定位思路与方法)。公司技术同事使用该方法定位了很多项目内存问题。 今天技术同事说有个设备内存占用很高，使用定位方法发现存在隐形内存。我登录设备初步排查了黑洞内存常见的几个怀疑点，没有发现问题。 随后我再次查看meminfo确认，发现了一个奇怪的现象。 [root@localhost ~]# cat /proc/meminfo
包过滤防火墙可以过滤的分片报文有
最新发布
06-07
包过滤防火墙可以过滤分片报文，通常会在IP层进行过滤。分片报文是指一个IP数据包被分成多个较小的数据包进行传输，这通常发生在源主机发送的数据包比网络MTU（最大传输单元）还要大时。分片报文的传输在网络层处理，因此包过滤防火墙可以通过检查IP分片的头部信息来控制其传输。常见的IP分片字段包括标识符、偏移量和标志位等，包过滤防火墙可以利用这些信息来过滤分片报文，例如根据标识符来匹配分片报文的片段，根据偏移量来判断分片报文是否完整等。通过对分片报文的过滤，包过滤防火墙可以有效地保护网络不受分片攻击的威胁，同时也可以提高网络性能和带宽利用率。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

浮沉飘摇

码字不易，打赏随意。

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值