How to disable broadcasting on an IP-less Linux NIC
Clash Royale CLAN TAG#URR8PPP
2
Linux system with two NICs.
- eth0 connected to Co. LAN. DHCP configured. It is the main network
connection. - eth1 point-to-point connected to a network analyzer. No
IP on this interface. - Linux application sending L2 packets on eth1.
- The network analyzer gets the application packets PLUS all
broadcasts arrived on eth0.
Question: How can I stop broadcasts being forwarded on eth1 ?
Config:
eth0 Link encap:Ethernet HWaddr 10:98:36:af:9c:0f
inet addr:192.168.x.xx Bcast:192.168.3.255 Mask:255.255.252.0 UP
BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 10:98:36:af:9c:10
UP BROADCAST RUNNING MTU:1500 Metric:1
ip link:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
broadcast
edited Aug 9 '17 at 20:40
Hauke Laging
56.4k1285135
asked Aug 9 '17 at 19:30
papy muzopapy muzo
112
|
show 4 more comments
2
Linux system with two NICs.
- eth0 connected to Co. LAN. DHCP configured. It is the main network
connection. - eth1 point-to-point connected to a network analyzer. No
IP on this interface. - Linux application sending L2 packets on eth1.
- The network analyzer gets the application packets PLUS all
broadcasts arrived on eth0.
Question: How can I stop broadcasts being forwarded on eth1 ?
Config:
eth0 Link encap:Ethernet HWaddr 10:98:36:af:9c:0f
inet addr:192.168.x.xx Bcast:192.168.3.255 Mask:255.255.252.0 UP
BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 10:98:36:af:9c:10
UP BROADCAST RUNNING MTU:1500 Metric:1
ip link:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
broadcast
edited Aug 9 '17 at 20:40
Hauke Laging
56.4k1285135
asked Aug 9 '17 at 19:30
papy muzopapy muzo
112
What is the output ofip link? Does this happen when the application is not running, too?
– Hauke Laging
Aug 9 '17 at 20:02
It does happen permanently, app or noapp.
– papy muzo
Aug 9 '17 at 20:35
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
– papy muzo
Aug 9 '17 at 20:36
1
The HWaddr suggests that both eth IFs are part of the same hardware device. Maybe that device is bridging them internally? Can you add details about the ethernet hardware and the Linux system to the question?
– dirkt
Aug 10 '17 at 6:10
DELL PowerEdge T130. Linux 4.4.0-62-generic #83-Ubuntu SMP .
– papy muzo
Aug 10 '17 at 14:00
|
show 4 more comments
2
2
2
Linux system with two NICs.
- eth0 connected to Co. LAN. DHCP configured. It is the main network
connection. - eth1 point-to-point connected to a network analyzer. No
IP on this interface. - Linux application sending L2 packets on eth1.
- The network analyzer gets the application packets PLUS all
broadcasts arrived on eth0.
Question: How can I stop broadcasts being forwarded on eth1 ?
Config:
eth0 Link encap:Ethernet HWaddr 10:98:36:af:9c:0f
inet addr:192.168.x.xx Bcast:192.168.3.255 Mask:255.255.252.0 UP
BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 10:98:36:af:9c:10
UP BROADCAST RUNNING MTU:1500 Metric:1
ip link:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
broadcast
edited Aug 9 '17 at 20:40
Hauke Laging
56.4k1285135
asked Aug 9 '17 at 19:30
papy muzopapy muzo
112
Linux system with two NICs.
- eth0 connected to Co. LAN. DHCP configured. It is the main network
connection. - eth1 point-to-point connected to a network analyzer. No
IP on this interface. - Linux application sending L2 packets on eth1.
- The network analyzer gets the application packets PLUS all
broadcasts arrived on eth0.
Question: How can I stop broadcasts being forwarded on eth1 ?
Config:
eth0 Link encap:Ethernet HWaddr 10:98:36:af:9c:0f
inet addr:192.168.x.xx Bcast:192.168.3.255 Mask:255.255.252.0 UP
BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 10:98:36:af:9c:10
UP BROADCAST RUNNING MTU:1500 Metric:1
ip link:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
broadcast
broadcast
edited Aug 9 '17 at 20:40
Hauke Laging
56.4k1285135
asked Aug 9 '17 at 19:30
papy muzopapy muzo
112
edited Aug 9 '17 at 20:40
Hauke Laging
56.4k1285135
asked Aug 9 '17 at 19:30
papy muzopapy muzo
112
edited Aug 9 '17 at 20:40
Hauke Laging
56.4k1285135
edited Aug 9 '17 at 20:40
Hauke Laging
56.4k1285135
edited Aug 9 '17 at 20:40
Hauke Laging
56.4k1285135
56.4k1285135
asked Aug 9 '17 at 19:30
papy muzopapy muzo
112
asked Aug 9 '17 at 19:30
papy muzopapy muzo
112
asked Aug 9 '17 at 19:30
papy muzopapy muzo
112
112
What is the output ofip link? Does this happen when the application is not running, too?
– Hauke Laging
Aug 9 '17 at 20:02
It does happen permanently, app or noapp.
– papy muzo
Aug 9 '17 at 20:35
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
– papy muzo
Aug 9 '17 at 20:36
1
The HWaddr suggests that both eth IFs are part of the same hardware device. Maybe that device is bridging them internally? Can you add details about the ethernet hardware and the Linux system to the question?
– dirkt
Aug 10 '17 at 6:10
DELL PowerEdge T130. Linux 4.4.0-62-generic #83-Ubuntu SMP .
– papy muzo
Aug 10 '17 at 14:00
|
show 4 more comments
What is the output ofip link? Does this happen when the application is not running, too?
– Hauke Laging
Aug 9 '17 at 20:02
It does happen permanently, app or noapp.
– papy muzo
Aug 9 '17 at 20:35
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
– papy muzo
Aug 9 '17 at 20:36
1
The HWaddr suggests that both eth IFs are part of the same hardware device. Maybe that device is bridging them internally? Can you add details about the ethernet hardware and the Linux system to the question?
– dirkt
Aug 10 '17 at 6:10
DELL PowerEdge T130. Linux 4.4.0-62-generic #83-Ubuntu SMP .
– papy muzo
Aug 10 '17 at 14:00
What is the output of
ip link? Does this happen when the application is not running, too?– Hauke Laging
Aug 9 '17 at 20:02
What is the output of
ip link? Does this happen when the application is not running, too?– Hauke Laging
Aug 9 '17 at 20:02
It does happen permanently, app or noapp.
– papy muzo
Aug 9 '17 at 20:35
It does happen permanently, app or noapp.
– papy muzo
Aug 9 '17 at 20:35
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
– papy muzo
Aug 9 '17 at 20:36
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
– papy muzo
Aug 9 '17 at 20:36
1
1
The HWaddr suggests that both eth IFs are part of the same hardware device. Maybe that device is bridging them internally? Can you add details about the ethernet hardware and the Linux system to the question?
– dirkt
Aug 10 '17 at 6:10
The HWaddr suggests that both eth IFs are part of the same hardware device. Maybe that device is bridging them internally? Can you add details about the ethernet hardware and the Linux system to the question?
– dirkt
Aug 10 '17 at 6:10
DELL PowerEdge T130. Linux 4.4.0-62-generic #83-Ubuntu SMP .
– papy muzo
Aug 10 '17 at 14:00
DELL PowerEdge T130. Linux 4.4.0-62-generic #83-Ubuntu SMP .
– papy muzo
Aug 10 '17 at 14:00
|
show 4 more comments
1 Answer
1
active
oldest
votes
0
Fixed the problem by adding two rules to iptables:
iptables -A FORWARD -m pkttype --pkt-type broadcast -i eth1 -j DROP
iptables -A INPUT -m pkttype --pkt-type broadcast -i eth1 -j DROP
Iptables looks now:
$ iptables -L -v
Chain INPUT (policy ACCEPT 54446 packets, 5132K bytes)
pkts bytes target prot opt in out source destination
123 40344 DROP all -- eth1 any anywhere anywhere PKTTYPE = broadcast
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- eth1 any anywhere anywhere PKTTYPE = broadcast
Chain OUTPUT (policy ACCEPT 8072 packets, 3990K bytes)
pkts bytes target prot opt in out source destination
edited Aug 11 '17 at 0:20
Paolo
5,19772136
answered Aug 10 '17 at 23:24
papy muzopapy muzo
112
I'm still very much confused why broadcasts are forwarded in the first place - the default behaviour is that they aren't. The fact that you can disable it throughiptablesmeans the broadcasts are forwarded through the Linux kernel, which means you must run some software or have enabled something that does the forwarding in the first place. If you can find out what this is, you can disable it directly instead of usingiptables.
– dirkt
Aug 11 '17 at 5:02
Could you, please provide a pointer to some doc which describes the default behavior. I was not able to find any.
– papy muzo
Aug 11 '17 at 15:38
I don't think this is explicitely mentioned in any docs, but that's what happens on my system, and on any other system I've seen so far. Normally nothing is forwarded between different network interfaces unless they are bridged. There's plenty of questions how to enable forwarding broadcasts, e.g. here or here (google for more).
– dirkt
Aug 12 '17 at 5:31
Actually, the second answers mentionedebtables, so one idea is to check if something was configured usingebtables(likeiptables, but on OSI Level 2) on your system.
– dirkt
Aug 12 '17 at 5:32
Mainly what I saw were "bootp" or "dhcp" requests. They are pure L2 broadcasts supposed to be LAN wide. eth0 gets them as being LAN connected. eth1 does not have an IP - it is not in an IP broadcast domain but it is in a LAN. As long as eh1 is down you do not see these packets. Connecting eth1 to some other Ethernet port both link-up. I suppose the Linux network stack (won't say IP stack) assumes same LAN and in consequence will forward them. As soon as you attach a different LAN IP on eth1 this behavior stops. HW took the system to keep working on their stuff. I, no longer can experiment.
– papy muzo
Aug 14 '17 at 18:05
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f385044%2fhow-to-disable-broadcasting-on-an-ip-less-linux-nic%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
0
Fixed the problem by adding two rules to iptables:
iptables -A FORWARD -m pkttype --pkt-type broadcast -i eth1 -j DROP
iptables -A INPUT -m pkttype --pkt-type broadcast -i eth1 -j DROP
Iptables looks now:
$ iptables -L -v
Chain INPUT (policy ACCEPT 54446 packets, 5132K bytes)
pkts bytes target prot opt in out source destination
123 40344 DROP all -- eth1 any anywhere anywhere PKTTYPE = broadcast
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- eth1 any anywhere anywhere PKTTYPE = broadcast
Chain OUTPUT (policy ACCEPT 8072 packets, 3990K bytes)
pkts bytes target prot opt in out source destination
edited Aug 11 '17 at 0:20
Paolo
5,19772136
answered Aug 10 '17 at 23:24
papy muzopapy muzo
112
I'm still very much confused why broadcasts are forwarded in the first place - the default behaviour is that they aren't. The fact that you can disable it throughiptablesmeans the broadcasts are forwarded through the Linux kernel, which means you must run some software or have enabled something that does the forwarding in the first place. If you can find out what this is, you can disable it directly instead of usingiptables.
– dirkt
Aug 11 '17 at 5:02
Could you, please provide a pointer to some doc which describes the default behavior. I was not able to find any.
– papy muzo
Aug 11 '17 at 15:38
I don't think this is explicitely mentioned in any docs, but that's what happens on my system, and on any other system I've seen so far. Normally nothing is forwarded between different network interfaces unless they are bridged. There's plenty of questions how to enable forwarding broadcasts, e.g. here or here (google for more).
– dirkt
Aug 12 '17 at 5:31
Actually, the second answers mentionedebtables, so one idea is to check if something was configured usingebtables(likeiptables, but on OSI Level 2) on your system.
– dirkt
Aug 12 '17 at 5:32
Mainly what I saw were "bootp" or "dhcp" requests. They are pure L2 broadcasts supposed to be LAN wide. eth0 gets them as being LAN connected. eth1 does not have an IP - it is not in an IP broadcast domain but it is in a LAN. As long as eh1 is down you do not see these packets. Connecting eth1 to some other Ethernet port both link-up. I suppose the Linux network stack (won't say IP stack) assumes same LAN and in consequence will forward them. As soon as you attach a different LAN IP on eth1 this behavior stops. HW took the system to keep working on their stuff. I, no longer can experiment.
– papy muzo
Aug 14 '17 at 18:05
add a comment |
0
Fixed the problem by adding two rules to iptables:
iptables -A FORWARD -m pkttype --pkt-type broadcast -i eth1 -j DROP
iptables -A INPUT -m pkttype --pkt-type broadcast -i eth1 -j DROP
Iptables looks now:
$ iptables -L -v
Chain INPUT (policy ACCEPT 54446 packets, 5132K bytes)
pkts bytes target prot opt in out source destination
123 40344 DROP all -- eth1 any anywhere anywhere PKTTYPE = broadcast
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- eth1 any anywhere anywhere PKTTYPE = broadcast
Chain OUTPUT (policy ACCEPT 8072 packets, 3990K bytes)
pkts bytes target prot opt in out source destination
edited Aug 11 '17 at 0:20
Paolo
5,19772136
answered Aug 10 '17 at 23:24
papy muzopapy muzo
112
I'm still very much confused why broadcasts are forwarded in the first place - the default behaviour is that they aren't. The fact that you can disable it throughiptablesmeans the broadcasts are forwarded through the Linux kernel, which means you must run some software or have enabled something that does the forwarding in the first place. If you can find out what this is, you can disable it directly instead of usingiptables.
– dirkt
Aug 11 '17 at 5:02
Could you, please provide a pointer to some doc which describes the default behavior. I was not able to find any.
– papy muzo
Aug 11 '17 at 15:38
I don't think this is explicitely mentioned in any docs, but that's what happens on my system, and on any other system I've seen so far. Normally nothing is forwarded between different network interfaces unless they are bridged. There's plenty of questions how to enable forwarding broadcasts, e.g. here or here (google for more).
– dirkt
Aug 12 '17 at 5:31
Actually, the second answers mentionedebtables, so one idea is to check if something was configured usingebtables(likeiptables, but on OSI Level 2) on your system.
– dirkt
Aug 12 '17 at 5:32
Mainly what I saw were "bootp" or "dhcp" requests. They are pure L2 broadcasts supposed to be LAN wide. eth0 gets them as being LAN connected. eth1 does not have an IP - it is not in an IP broadcast domain but it is in a LAN. As long as eh1 is down you do not see these packets. Connecting eth1 to some other Ethernet port both link-up. I suppose the Linux network stack (won't say IP stack) assumes same LAN and in consequence will forward them. As soon as you attach a different LAN IP on eth1 this behavior stops. HW took the system to keep working on their stuff. I, no longer can experiment.
– papy muzo
Aug 14 '17 at 18:05
add a comment |
0
0
0
Fixed the problem by adding two rules to iptables:
iptables -A FORWARD -m pkttype --pkt-type broadcast -i eth1 -j DROP
iptables -A INPUT -m pkttype --pkt-type broadcast -i eth1 -j DROP
Iptables looks now:
$ iptables -L -v
Chain INPUT (policy ACCEPT 54446 packets, 5132K bytes)
pkts bytes target prot opt in out source destination
123 40344 DROP all -- eth1 any anywhere anywhere PKTTYPE = broadcast
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- eth1 any anywhere anywhere PKTTYPE = broadcast
Chain OUTPUT (policy ACCEPT 8072 packets, 3990K bytes)
pkts bytes target prot opt in out source destination
edited Aug 11 '17 at 0:20
Paolo
5,19772136
answered Aug 10 '17 at 23:24
papy muzopapy muzo
112
Fixed the problem by adding two rules to iptables:
iptables -A FORWARD -m pkttype --pkt-type broadcast -i eth1 -j DROP
iptables -A INPUT -m pkttype --pkt-type broadcast -i eth1 -j DROP
Iptables looks now:
$ iptables -L -v
Chain INPUT (policy ACCEPT 54446 packets, 5132K bytes)
pkts bytes target prot opt in out source destination
123 40344 DROP all -- eth1 any anywhere anywhere PKTTYPE = broadcast
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- eth1 any anywhere anywhere PKTTYPE = broadcast
Chain OUTPUT (policy ACCEPT 8072 packets, 3990K bytes)
pkts bytes target prot opt in out source destination
edited Aug 11 '17 at 0:20
Paolo
5,19772136
answered Aug 10 '17 at 23:24
papy muzopapy muzo
112
edited Aug 11 '17 at 0:20
Paolo
5,19772136
edited Aug 11 '17 at 0:20
Paolo
5,19772136
edited Aug 11 '17 at 0:20
Paolo
5,19772136
5,19772136
answered Aug 10 '17 at 23:24
papy muzopapy muzo
112
answered Aug 10 '17 at 23:24
papy muzopapy muzo
112
answered Aug 10 '17 at 23:24
papy muzopapy muzo
112
112
I'm still very much confused why broadcasts are forwarded in the first place - the default behaviour is that they aren't. The fact that you can disable it throughiptablesmeans the broadcasts are forwarded through the Linux kernel, which means you must run some software or have enabled something that does the forwarding in the first place. If you can find out what this is, you can disable it directly instead of usingiptables.
– dirkt
Aug 11 '17 at 5:02
Could you, please provide a pointer to some doc which describes the default behavior. I was not able to find any.
– papy muzo
Aug 11 '17 at 15:38
I don't think this is explicitely mentioned in any docs, but that's what happens on my system, and on any other system I've seen so far. Normally nothing is forwarded between different network interfaces unless they are bridged. There's plenty of questions how to enable forwarding broadcasts, e.g. here or here (google for more).
– dirkt
Aug 12 '17 at 5:31
Actually, the second answers mentionedebtables, so one idea is to check if something was configured usingebtables(likeiptables, but on OSI Level 2) on your system.
– dirkt
Aug 12 '17 at 5:32
Mainly what I saw were "bootp" or "dhcp" requests. They are pure L2 broadcasts supposed to be LAN wide. eth0 gets them as being LAN connected. eth1 does not have an IP - it is not in an IP broadcast domain but it is in a LAN. As long as eh1 is down you do not see these packets. Connecting eth1 to some other Ethernet port both link-up. I suppose the Linux network stack (won't say IP stack) assumes same LAN and in consequence will forward them. As soon as you attach a different LAN IP on eth1 this behavior stops. HW took the system to keep working on their stuff. I, no longer can experiment.
– papy muzo
Aug 14 '17 at 18:05
add a comment |
I'm still very much confused why broadcasts are forwarded in the first place - the default behaviour is that they aren't. The fact that you can disable it throughiptablesmeans the broadcasts are forwarded through the Linux kernel, which means you must run some software or have enabled something that does the forwarding in the first place. If you can find out what this is, you can disable it directly instead of usingiptables.
– dirkt
Aug 11 '17 at 5:02
Could you, please provide a pointer to some doc which describes the default behavior. I was not able to find any.
– papy muzo
Aug 11 '17 at 15:38
I don't think this is explicitely mentioned in any docs, but that's what happens on my system, and on any other system I've seen so far. Normally nothing is forwarded between different network interfaces unless they are bridged. There's plenty of questions how to enable forwarding broadcasts, e.g. here or here (google for more).
– dirkt
Aug 12 '17 at 5:31
Actually, the second answers mentionedebtables, so one idea is to check if something was configured usingebtables(likeiptables, but on OSI Level 2) on your system.
– dirkt
Aug 12 '17 at 5:32
Mainly what I saw were "bootp" or "dhcp" requests. They are pure L2 broadcasts supposed to be LAN wide. eth0 gets them as being LAN connected. eth1 does not have an IP - it is not in an IP broadcast domain but it is in a LAN. As long as eh1 is down you do not see these packets. Connecting eth1 to some other Ethernet port both link-up. I suppose the Linux network stack (won't say IP stack) assumes same LAN and in consequence will forward them. As soon as you attach a different LAN IP on eth1 this behavior stops. HW took the system to keep working on their stuff. I, no longer can experiment.
– papy muzo
Aug 14 '17 at 18:05
I'm still very much confused why broadcasts are forwarded in the first place - the default behaviour is that they aren't. The fact that you can disable it through
iptables means the broadcasts are forwarded through the Linux kernel, which means you must run some software or have enabled something that does the forwarding in the first place. If you can find out what this is, you can disable it directly instead of using iptables.– dirkt
Aug 11 '17 at 5:02
I'm still very much confused why broadcasts are forwarded in the first place - the default behaviour is that they aren't. The fact that you can disable it through
iptables means the broadcasts are forwarded through the Linux kernel, which means you must run some software or have enabled something that does the forwarding in the first place. If you can find out what this is, you can disable it directly instead of using iptables.– dirkt
Aug 11 '17 at 5:02
Could you, please provide a pointer to some doc which describes the default behavior. I was not able to find any.
– papy muzo
Aug 11 '17 at 15:38
Could you, please provide a pointer to some doc which describes the default behavior. I was not able to find any.
– papy muzo
Aug 11 '17 at 15:38
I don't think this is explicitely mentioned in any docs, but that's what happens on my system, and on any other system I've seen so far. Normally nothing is forwarded between different network interfaces unless they are bridged. There's plenty of questions how to enable forwarding broadcasts, e.g. here or here (google for more).
– dirkt
Aug 12 '17 at 5:31
I don't think this is explicitely mentioned in any docs, but that's what happens on my system, and on any other system I've seen so far. Normally nothing is forwarded between different network interfaces unless they are bridged. There's plenty of questions how to enable forwarding broadcasts, e.g. here or here (google for more).
– dirkt
Aug 12 '17 at 5:31
Actually, the second answers mentioned
ebtables, so one idea is to check if something was configured using ebtables (like iptables, but on OSI Level 2) on your system.– dirkt
Aug 12 '17 at 5:32
Actually, the second answers mentioned
ebtables, so one idea is to check if something was configured using ebtables (like iptables, but on OSI Level 2) on your system.– dirkt
Aug 12 '17 at 5:32
Mainly what I saw were "bootp" or "dhcp" requests. They are pure L2 broadcasts supposed to be LAN wide. eth0 gets them as being LAN connected. eth1 does not have an IP - it is not in an IP broadcast domain but it is in a LAN. As long as eh1 is down you do not see these packets. Connecting eth1 to some other Ethernet port both link-up. I suppose the Linux network stack (won't say IP stack) assumes same LAN and in consequence will forward them. As soon as you attach a different LAN IP on eth1 this behavior stops. HW took the system to keep working on their stuff. I, no longer can experiment.
– papy muzo
Aug 14 '17 at 18:05
Mainly what I saw were "bootp" or "dhcp" requests. They are pure L2 broadcasts supposed to be LAN wide. eth0 gets them as being LAN connected. eth1 does not have an IP - it is not in an IP broadcast domain but it is in a LAN. As long as eh1 is down you do not see these packets. Connecting eth1 to some other Ethernet port both link-up. I suppose the Linux network stack (won't say IP stack) assumes same LAN and in consequence will forward them. As soon as you attach a different LAN IP on eth1 this behavior stops. HW took the system to keep working on their stuff. I, no longer can experiment.
– papy muzo
Aug 14 '17 at 18:05
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f385044%2fhow-to-disable-broadcasting-on-an-ip-less-linux-nic%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What is the output of
ip link? Does this happen when the application is not running, too?– Hauke Laging
Aug 9 '17 at 20:02
It does happen permanently, app or noapp.
– papy muzo
Aug 9 '17 at 20:35
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:0f brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 10:98:36:af:9c:10 brd ff:ff:ff:ff:ff:ff
– papy muzo
Aug 9 '17 at 20:36
1
The HWaddr suggests that both eth IFs are part of the same hardware device. Maybe that device is bridging them internally? Can you add details about the ethernet hardware and the Linux system to the question?
– dirkt
Aug 10 '17 at 6:10
DELL PowerEdge T130. Linux 4.4.0-62-generic #83-Ubuntu SMP .
– papy muzo
Aug 10 '17 at 14:00