UDP广播接收问题与Ubuntu9.04但不8.04
https://stackoverflow.com/questions/2130563
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
更新
- 01-27ter:rp_filter信息加入
- 01-27bis:注意9.04框工作在一个不同的接口。
- 01-27:加入接口结构的信息和分析的一个分组。
原来的职位
我有两个非常类似的硬件配置(SuperMicro1U系统与双强Cpu和两个以太网端口上的板)、一个运行Ubuntu8.04(Linux2.6.24-26-服务器)和一个办Ubuntu9.04(Linux2.6.28-17-服务器)。这些都有eth1连到同一个网络在其各种其他服务器发送广播UDP组到各个港口。在两台主机，用tcpdump在eth1，我可以看到这些广播UDP包抵达。
然而，虽然在8.04框我可以有一个简单的程序，听取他们的只是现，在9.04框相同的程序永远不会接收他们。作为一个高级别的概述，这样品Haskell的程序，适用于一个但不在其他(采用完全相同版本的GHC两):
import Network.Socket
port = 5515
main :: IO ()
main = do
do sock <- socket AF_INET Datagram defaultProtocol
bindSocket sock $ SockAddrInet (fromIntegral port) iNADDR_ANY
loop sock
where
loop sock =
do msg <- recv sock 2048
print msg
loop sock
在情况的问题发生了什么东西非常奇怪的GHC(虽然这是一个相同的建立两)，我写了一C节目做同样的事情：
#include <arpa/inet.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
#define BUFLEN 512
#define NPACK 10
#define PORT 5515
void diep(char *s)
{
perror(s);
exit(1);
}
void showb(int s) {
int val, len, retval;
len = sizeof(val);
retval = getsockopt(s, SOL_SOCKET, SO_BROADCAST, &val, &len);
printf("showb retval=%d val=%d\n", retval, val);
}
int main(int argc, char **argv)
{
struct sockaddr_in si_me, si_other;
int s, i, slen=sizeof(si_other);
char buf[BUFLEN];
if ((s=socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP))==-1)
diep("socket");
showb(s);
i = 1;
if (setsockopt(s, SOL_SOCKET, SO_BROADCAST, &i, sizeof(i))==-1)
diep("setsockopt");
showb(s);
memset((char *) &si_me, 0, sizeof(si_me));
si_me.sin_family = AF_INET;
si_me.sin_port = htons(PORT);
si_me.sin_addr.s_addr = htonl(INADDR_ANY);
if (bind(s, &si_me, sizeof(si_me))==-1)
diep("bind");
puts("Listening.");
for (i=0; i<NPACK; i++) {
if (recvfrom(s, buf, BUFLEN, 0, &si_other, &slen)==-1)
diep("recvfrom()");
printf("Received packet from %s:%d\nData: %s\n\n",
inet_ntoa(si_other.sin_addr), ntohs(si_other.sin_port), buf);
}
close(s);
return 0;
}
你会注意，只是为了好玩，在这种情况下，我还打开SO_BROADCAST标志上插座，并确认它被打开，虽然它没有差别的行为的节目，这是同样的。甚至如果我拷贝二进制建立在8.04的9.04箱中，或反之亦然，在所有情况下运行的程序上的8.04框看到UDP广播报和9.04箱没有。
我做错了什么？
更新01-27:
这里的输出的ip链接和ip醚的工作(8.04)主办：
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1362 qdisc pfifo_fast qlen 1000
link/ether 00:30:48:d3:4b:06 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:30:48:d3:4b:07 brd ff:ff:ff:ff:ff:ff
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1362 qdisc pfifo_fast qlen 1000
link/ether 00:30:48:d3:4b:06 brd ff:ff:ff:ff:ff:ff
inet 192.168.228.130/28 brd 192.168.228.143 scope global eth0
inet6 fe80::230:48ff:fed3:4b06/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:30:48:d3:4b:07 brd ff:ff:ff:ff:ff:ff
inet 172.40.4.130/24 brd 172.40.4.255 scope global eth1
inet6 fe80::230:48ff:fed3:4b07/64 scope link
valid_lft forever preferred_lft forever
并为非工作(9.04)服务器：
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1362 qdisc pfifo_fast state UP qlen 1000
link/ether 00:30:48:d9:38:da brd ff:ff:ff:ff:ff:ff
3: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:1b:21:36:19:fd brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100
link/ether 00:30:48:d9:38:db brd ff:ff:ff:ff:ff:ff
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1362 qdisc pfifo_fast state UP qlen 1000
link/ether 00:30:48:d9:38:da brd ff:ff:ff:ff:ff:ff
inet 192.168.228.132/28 brd 192.168.228.143 scope global eth0
inet6 fe80::230:48ff:fed9:38da/64 scope link
valid_lft forever preferred_lft forever
3: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:1b:21:36:19:fd brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100
link/ether 00:30:48:d9:38:db brd ff:ff:ff:ff:ff:ff
inet 172.40.4.132/24 brd 172.40.4.255 scope global eth1
inet6 fe80::230:48ff:fed9:38db/64 scope link
valid_lft forever preferred_lft forever
请注意，对于这两种情况下，eth1是口上的广播节目是抵达。
这里是一个完整的解码(从tshark在非工作9.04服务器)的样本的广播分组，该程序不是接收：
Frame 193555 (271 bytes on wire, 271 bytes captured)
Arrival Time: Jan 25, 2010 08:00:00.535345000
[Time delta from previous captured frame: 0.001508000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 6590.956186000 seconds]
Frame Number: 193555
Frame Length: 271 bytes
Capture Length: 271 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:data]
Ethernet II, Src: Cisco_aa:c0:28 (00:d0:bb:aa:c0:28), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Source: Cisco_aa:c0:28 (00:d0:bb:aa:c0:28)
Address: Cisco_aa:c0:28 (00:d0:bb:aa:c0:28)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 192.166.1.120 (192.166.1.120), Dst: 255.255.255.255 (255.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 257
Identification: 0xfad3 (64211)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 252
Protocol: UDP (0x11)
Header checksum: 0xc0f9 [correct]
[Good: True]
[Bad : False]
Source: 192.166.1.120 (192.166.1.120)
Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 56172 (56172), Dst Port: 5515 (5515)
Source port: 56172 (56172)
Destination port: 5515 (5515)
Length: 237
Checksum: 0x01ba [correct]
[Good Checksum: True]
[Bad Checksum: False]
Data (229 bytes)
0000 41 37 30 33 34 30 38 30 30 30 30 30 30 31 31 30 A703408000000110
0010 4b 52 53 50 49 4f 50 4b 32 49 4b 52 34 32 30 31 KRSPIOPK2IKR4201
0020 45 32 32 32 35 33 30 30 32 31 30 30 30 30 30 30 E222530021000000
0030 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0040 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0050 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0060 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0070 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0080 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0090 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
00a0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
00b0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
00c0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
00d0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
00e0 30 30 30 30 ff 0000.
Data: 413730333430383030303030303131304B525350494F504B...
我比较这个针对同一分组由一个垃圾场采取的工作8.04服务器，而该组本身identicial;唯一的区别是在框架的数量(内pcap文件)和时间分组收到了(为1.224毫秒差别，这似乎高给予这两个主机使用同一NTP服务器，但不是完全不合理).
更新01-27bis
我已经试验了一步，产生我自己的广播报上8.04主机并将它们发送到9.04主和9.04主机接收的数据包就好了当8.04主机送他们和他们抵达上eth0或eth1.
更新01-27ter
输出 sp 3; sysctl -a 2>/dev/null | grep '\.rp_filter' | sort 在8.04主是：
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 1
和9.04主是：
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.eth2.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 0
解决方案
所以问题是网。ipv4。conf.eth1.rp_filter则设置的。它设定为0的8.04框我在做松散的反路径检查，这意味着一个分组可以来自任何目的，我可以路线上的任何接口。在9.04盒子，我是这样做严格的检查，这意味着它将拒绝接受包抵达在一个接口，如果答复这些分组会走出去的一个不同的接口。
该组抵达eth1到255.255.255.255是那些我不应该收下了一切都能正常运行，因为255.255.255.255是的 本地 网络广播地址，但来源的那些分组并不是在本地网络。所以基本上，事情是错误配置在网络上我在那里接收一个饲料，并且我必须处理这个错误配置。
不隶属于 StackOverflow
