Why is eth0 responding to ip-address assigned to ethernet gadget usb0?
We configure networking on an embedded Linux system by setting one static IP-Address(169.254.0.1/16=LLA) on an Ethernet-Gadget/usb0 while using DHCP on Ethernet/eth0(192.168./16).
To our surprise the embedded system responds on eth0 to the static ip-address. ifconfig on the embedded linux device shows:
eth0 Link encap:Ethernet HWaddr <snip>
inet addr:192.168.51.156 Bcast:192.168.55.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
<snip>
usb0 Link encap:Ethernet HWaddr <snip>
inet addr:169.254.0.1 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
<snip>
The routing table on the embedded linux device :
root@my_embedded_system01:~# ip route
default via 192.168.50.30 dev eth0 proto dhcp src 192.168.51.156 metric 1024
169.254.0.0/16 dev usb0 proto kernel scope link src 169.254.0.1 linkdown
192.168.48.0/21 dev eth0 proto kernel scope link src 192.168.51.156
192.168.50.30 dev eth0 proto dhcp scope link src 192.168.51.156 metric 1024
Is there a setting on the embedded device which can change that?
linux networking routing ip-address routing-table
edited Jan 4 at 10:07
Seth
6,16811128
asked Jan 3 at 15:57
ARiARi
62
|
show 1 more comment
We configure networking on an embedded Linux system by setting one static IP-Address(169.254.0.1/16=LLA) on an Ethernet-Gadget/usb0 while using DHCP on Ethernet/eth0(192.168./16).
To our surprise the embedded system responds on eth0 to the static ip-address. ifconfig on the embedded linux device shows:
eth0 Link encap:Ethernet HWaddr <snip>
inet addr:192.168.51.156 Bcast:192.168.55.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
<snip>
usb0 Link encap:Ethernet HWaddr <snip>
inet addr:169.254.0.1 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
<snip>
The routing table on the embedded linux device :
root@my_embedded_system01:~# ip route
default via 192.168.50.30 dev eth0 proto dhcp src 192.168.51.156 metric 1024
169.254.0.0/16 dev usb0 proto kernel scope link src 169.254.0.1 linkdown
192.168.48.0/21 dev eth0 proto kernel scope link src 192.168.51.156
192.168.50.30 dev eth0 proto dhcp scope link src 192.168.51.156 metric 1024
Is there a setting on the embedded device which can change that?
linux networking routing ip-address routing-table
edited Jan 4 at 10:07
Seth
6,16811128
asked Jan 3 at 15:57
ARiARi
62
It responded to which static address? How did you check which way the response was handled?
– Seth
Jan 4 at 10:09
Multiple of these embedded systems are connected via eth0 in our local network. I connect with ssh 169.254.0.1 to one of these systems. None is connected via USB.
– ARi
Jan 4 at 10:13
So neither is that particular one connected by USB? Maybe your embedded devices to have routing enabled and for some reason your local workstation has a route for them?
– Seth
Jan 4 at 10:27
Yes, I dont know how the routing table above would allow that. The ip-address assigned to the Ethernet Gadget is even a local-link address. To my understanding that should not be routed at all.
– ARi
Jan 4 at 11:16
And a problem only occurs when we connect one embedded system to USB and then try to connect with ssh. On a computer which is also connected to more of our systems via Ethernet the ssh 169.254.0.1 will get arbitrarily the response of any of the connected systems, not necessarily the one connected to USB.
– ARi
Jan 4 at 11:18
|
show 1 more comment
We configure networking on an embedded Linux system by setting one static IP-Address(169.254.0.1/16=LLA) on an Ethernet-Gadget/usb0 while using DHCP on Ethernet/eth0(192.168./16).
To our surprise the embedded system responds on eth0 to the static ip-address. ifconfig on the embedded linux device shows:
eth0 Link encap:Ethernet HWaddr <snip>
inet addr:192.168.51.156 Bcast:192.168.55.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
<snip>
usb0 Link encap:Ethernet HWaddr <snip>
inet addr:169.254.0.1 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
<snip>
The routing table on the embedded linux device :
root@my_embedded_system01:~# ip route
default via 192.168.50.30 dev eth0 proto dhcp src 192.168.51.156 metric 1024
169.254.0.0/16 dev usb0 proto kernel scope link src 169.254.0.1 linkdown
192.168.48.0/21 dev eth0 proto kernel scope link src 192.168.51.156
192.168.50.30 dev eth0 proto dhcp scope link src 192.168.51.156 metric 1024
Is there a setting on the embedded device which can change that?
linux networking routing ip-address routing-table
edited Jan 4 at 10:07
Seth
6,16811128
asked Jan 3 at 15:57
ARiARi
62
We configure networking on an embedded Linux system by setting one static IP-Address(169.254.0.1/16=LLA) on an Ethernet-Gadget/usb0 while using DHCP on Ethernet/eth0(192.168./16).
To our surprise the embedded system responds on eth0 to the static ip-address. ifconfig on the embedded linux device shows:
eth0 Link encap:Ethernet HWaddr <snip>
inet addr:192.168.51.156 Bcast:192.168.55.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
<snip>
usb0 Link encap:Ethernet HWaddr <snip>
inet addr:169.254.0.1 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
<snip>
The routing table on the embedded linux device :
root@my_embedded_system01:~# ip route
default via 192.168.50.30 dev eth0 proto dhcp src 192.168.51.156 metric 1024
169.254.0.0/16 dev usb0 proto kernel scope link src 169.254.0.1 linkdown
192.168.48.0/21 dev eth0 proto kernel scope link src 192.168.51.156
192.168.50.30 dev eth0 proto dhcp scope link src 192.168.51.156 metric 1024
Is there a setting on the embedded device which can change that?
linux networking routing ip-address routing-table
linux networking routing ip-address routing-table
edited Jan 4 at 10:07
Seth
6,16811128
asked Jan 3 at 15:57
ARiARi
62
edited Jan 4 at 10:07
Seth
6,16811128
asked Jan 3 at 15:57
ARiARi
62
edited Jan 4 at 10:07
Seth
6,16811128
edited Jan 4 at 10:07
Seth
6,16811128
edited Jan 4 at 10:07
Seth
6,16811128
6,16811128
asked Jan 3 at 15:57
ARiARi
62
asked Jan 3 at 15:57
ARiARi
62
asked Jan 3 at 15:57
ARiARi
62
62
It responded to which static address? How did you check which way the response was handled?
– Seth
Jan 4 at 10:09
Multiple of these embedded systems are connected via eth0 in our local network. I connect with ssh 169.254.0.1 to one of these systems. None is connected via USB.
– ARi
Jan 4 at 10:13
So neither is that particular one connected by USB? Maybe your embedded devices to have routing enabled and for some reason your local workstation has a route for them?
– Seth
Jan 4 at 10:27
Yes, I dont know how the routing table above would allow that. The ip-address assigned to the Ethernet Gadget is even a local-link address. To my understanding that should not be routed at all.
– ARi
Jan 4 at 11:16
And a problem only occurs when we connect one embedded system to USB and then try to connect with ssh. On a computer which is also connected to more of our systems via Ethernet the ssh 169.254.0.1 will get arbitrarily the response of any of the connected systems, not necessarily the one connected to USB.
– ARi
Jan 4 at 11:18
|
show 1 more comment
It responded to which static address? How did you check which way the response was handled?
– Seth
Jan 4 at 10:09
Multiple of these embedded systems are connected via eth0 in our local network. I connect with ssh 169.254.0.1 to one of these systems. None is connected via USB.
– ARi
Jan 4 at 10:13
So neither is that particular one connected by USB? Maybe your embedded devices to have routing enabled and for some reason your local workstation has a route for them?
– Seth
Jan 4 at 10:27
Yes, I dont know how the routing table above would allow that. The ip-address assigned to the Ethernet Gadget is even a local-link address. To my understanding that should not be routed at all.
– ARi
Jan 4 at 11:16
And a problem only occurs when we connect one embedded system to USB and then try to connect with ssh. On a computer which is also connected to more of our systems via Ethernet the ssh 169.254.0.1 will get arbitrarily the response of any of the connected systems, not necessarily the one connected to USB.
– ARi
Jan 4 at 11:18
It responded to which static address? How did you check which way the response was handled?
– Seth
Jan 4 at 10:09
It responded to which static address? How did you check which way the response was handled?
– Seth
Jan 4 at 10:09
Multiple of these embedded systems are connected via eth0 in our local network. I connect with ssh 169.254.0.1 to one of these systems. None is connected via USB.
– ARi
Jan 4 at 10:13
Multiple of these embedded systems are connected via eth0 in our local network. I connect with ssh 169.254.0.1 to one of these systems. None is connected via USB.
– ARi
Jan 4 at 10:13
So neither is that particular one connected by USB? Maybe your embedded devices to have routing enabled and for some reason your local workstation has a route for them?
– Seth
Jan 4 at 10:27
So neither is that particular one connected by USB? Maybe your embedded devices to have routing enabled and for some reason your local workstation has a route for them?
– Seth
Jan 4 at 10:27
Yes, I dont know how the routing table above would allow that. The ip-address assigned to the Ethernet Gadget is even a local-link address. To my understanding that should not be routed at all.
– ARi
Jan 4 at 11:16
Yes, I dont know how the routing table above would allow that. The ip-address assigned to the Ethernet Gadget is even a local-link address. To my understanding that should not be routed at all.
– ARi
Jan 4 at 11:16
And a problem only occurs when we connect one embedded system to USB and then try to connect with ssh. On a computer which is also connected to more of our systems via Ethernet the ssh 169.254.0.1 will get arbitrarily the response of any of the connected systems, not necessarily the one connected to USB.
– ARi
Jan 4 at 11:18
And a problem only occurs when we connect one embedded system to USB and then try to connect with ssh. On a computer which is also connected to more of our systems via Ethernet the ssh 169.254.0.1 will get arbitrarily the response of any of the connected systems, not necessarily the one connected to USB.
– ARi
Jan 4 at 11:18
|
show 1 more comment
1 Answer
1
active
oldest
votes
Use a firewall. One simple iptables rule will block all packets to usb0 address unless they actually enter through usb0:
-d 169.254.0.0/16 ! -i usb0 -j REJECT
Generally, tere are two separate issues here:
- Responding to ARP queries for an IP address that belongs to another interface.
- Accepting IP packets meant for IP addresses that belong to another interface.
The first part can be avoided easily by changing the net.ipv4.conf.all.arp_ignore sysctl to 1. Afaik, it defaults to 0 because on some operating systems, in IPv4, the addresses are considered to belong to the entire host instead of specific interfaces (weak host model), though it's a bit strange.
The second part (accepting IP packets through any interface) is normal for multi-network (multihomed) hosts. To prevent it, use firewall rules. Both iptables and nft support checking the inbound interface.
answered Jan 4 at 21:10
grawitygrawity
236k37500555
1. is no problem. For 2.: The embedded system has no iptables2 installed yet. Is there a way to have the tables set-up with "ip route" or "route"?
– ARi
Jan 7 at 13:43
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
});
}
});
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%2fsuperuser.com%2fquestions%2f1390224%2fwhy-is-eth0-responding-to-ip-address-assigned-to-ethernet-gadget-usb0%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
Use a firewall. One simple iptables rule will block all packets to usb0 address unless they actually enter through usb0:
-d 169.254.0.0/16 ! -i usb0 -j REJECT
Generally, tere are two separate issues here:
- Responding to ARP queries for an IP address that belongs to another interface.
- Accepting IP packets meant for IP addresses that belong to another interface.
The first part can be avoided easily by changing the net.ipv4.conf.all.arp_ignore sysctl to 1. Afaik, it defaults to 0 because on some operating systems, in IPv4, the addresses are considered to belong to the entire host instead of specific interfaces (weak host model), though it's a bit strange.
The second part (accepting IP packets through any interface) is normal for multi-network (multihomed) hosts. To prevent it, use firewall rules. Both iptables and nft support checking the inbound interface.
answered Jan 4 at 21:10
grawitygrawity
236k37500555
1. is no problem. For 2.: The embedded system has no iptables2 installed yet. Is there a way to have the tables set-up with "ip route" or "route"?
– ARi
Jan 7 at 13:43
add a comment |
Use a firewall. One simple iptables rule will block all packets to usb0 address unless they actually enter through usb0:
-d 169.254.0.0/16 ! -i usb0 -j REJECT
Generally, tere are two separate issues here:
- Responding to ARP queries for an IP address that belongs to another interface.
- Accepting IP packets meant for IP addresses that belong to another interface.
The first part can be avoided easily by changing the net.ipv4.conf.all.arp_ignore sysctl to 1. Afaik, it defaults to 0 because on some operating systems, in IPv4, the addresses are considered to belong to the entire host instead of specific interfaces (weak host model), though it's a bit strange.
The second part (accepting IP packets through any interface) is normal for multi-network (multihomed) hosts. To prevent it, use firewall rules. Both iptables and nft support checking the inbound interface.
answered Jan 4 at 21:10
grawitygrawity
236k37500555
1. is no problem. For 2.: The embedded system has no iptables2 installed yet. Is there a way to have the tables set-up with "ip route" or "route"?
– ARi
Jan 7 at 13:43
add a comment |
Use a firewall. One simple iptables rule will block all packets to usb0 address unless they actually enter through usb0:
-d 169.254.0.0/16 ! -i usb0 -j REJECT
Generally, tere are two separate issues here:
- Responding to ARP queries for an IP address that belongs to another interface.
- Accepting IP packets meant for IP addresses that belong to another interface.
The first part can be avoided easily by changing the net.ipv4.conf.all.arp_ignore sysctl to 1. Afaik, it defaults to 0 because on some operating systems, in IPv4, the addresses are considered to belong to the entire host instead of specific interfaces (weak host model), though it's a bit strange.
The second part (accepting IP packets through any interface) is normal for multi-network (multihomed) hosts. To prevent it, use firewall rules. Both iptables and nft support checking the inbound interface.
answered Jan 4 at 21:10
grawitygrawity
236k37500555
Use a firewall. One simple iptables rule will block all packets to usb0 address unless they actually enter through usb0:
-d 169.254.0.0/16 ! -i usb0 -j REJECT
Generally, tere are two separate issues here:
- Responding to ARP queries for an IP address that belongs to another interface.
- Accepting IP packets meant for IP addresses that belong to another interface.
The first part can be avoided easily by changing the net.ipv4.conf.all.arp_ignore sysctl to 1. Afaik, it defaults to 0 because on some operating systems, in IPv4, the addresses are considered to belong to the entire host instead of specific interfaces (weak host model), though it's a bit strange.
The second part (accepting IP packets through any interface) is normal for multi-network (multihomed) hosts. To prevent it, use firewall rules. Both iptables and nft support checking the inbound interface.
answered Jan 4 at 21:10
grawitygrawity
236k37500555
answered Jan 4 at 21:10
grawitygrawity
236k37500555
answered Jan 4 at 21:10
grawitygrawity
236k37500555
answered Jan 4 at 21:10
grawitygrawity
236k37500555
236k37500555
1. is no problem. For 2.: The embedded system has no iptables2 installed yet. Is there a way to have the tables set-up with "ip route" or "route"?
– ARi
Jan 7 at 13:43
add a comment |
1. is no problem. For 2.: The embedded system has no iptables2 installed yet. Is there a way to have the tables set-up with "ip route" or "route"?
– ARi
Jan 7 at 13:43
1. is no problem. For 2.: The embedded system has no iptables2 installed yet. Is there a way to have the tables set-up with "ip route" or "route"?
– ARi
Jan 7 at 13:43
1. is no problem. For 2.: The embedded system has no iptables2 installed yet. Is there a way to have the tables set-up with "ip route" or "route"?
– ARi
Jan 7 at 13:43
add a comment |
Thanks for contributing an answer to Super User!
- 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.
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%2fsuperuser.com%2fquestions%2f1390224%2fwhy-is-eth0-responding-to-ip-address-assigned-to-ethernet-gadget-usb0%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
It responded to which static address? How did you check which way the response was handled?
– Seth
Jan 4 at 10:09
Multiple of these embedded systems are connected via eth0 in our local network. I connect with ssh 169.254.0.1 to one of these systems. None is connected via USB.
– ARi
Jan 4 at 10:13
So neither is that particular one connected by USB? Maybe your embedded devices to have routing enabled and for some reason your local workstation has a route for them?
– Seth
Jan 4 at 10:27
Yes, I dont know how the routing table above would allow that. The ip-address assigned to the Ethernet Gadget is even a local-link address. To my understanding that should not be routed at all.
– ARi
Jan 4 at 11:16
And a problem only occurs when we connect one embedded system to USB and then try to connect with ssh. On a computer which is also connected to more of our systems via Ethernet the ssh 169.254.0.1 will get arbitrarily the response of any of the connected systems, not necessarily the one connected to USB.
– ARi
Jan 4 at 11:18