| View previous topic :: View next topic |
| Author |
Message |
EliasJonsson
n00b
Joined: 18 Oct 2017
Posts: 53
|
 Posted: Wed Mar 31, 2021 1:37 pm Post subject: both NICs stops working if one is disconnected |
 |
|
There are two NICs, one wired (10.0.0.5) and one wireless (10.0.0.55)
Both NICs are connected. If a peer computer starts pinging the wireless interface, 10.0.0.55, it responds and continuously does so . However, if the network cable is pulled from the wired NIC, the wireless NIC stops responding. Now why is that? Is there some remedy to fix this? |
|
| Back to top |
|
 |
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Wed Mar 31, 2021 3:21 pm Post subject: |
|
|
- Are 10.0.0.5 and 10.0.0.55 on the same network?
- Please post the output of
It looks like some of the ping packets travel through your wired interface. Activate both interfaces and send pings to 10.0.0.55. Use tcpdump to monitor traffic on your wired interface as well as on your wireless interface. Make sure that incoming and outgoing ping packets travel through your wireless interface.
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Wed Mar 31, 2021 4:31 pm Post subject: |
|
|
EliasJonsson,
What is the output of
What setting do you have in /etc/rc.conf for rc_depend_strict= ?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
EliasJonsson
n00b
Joined: 18 Oct 2017
Posts: 53
|
| Posted: Thu Apr 01, 2021 6:23 am Post subject: |
|
|
mike155,
1. Yes.
2.
five ~ # ifconfig -a
| Code: |
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.5 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::dea6:32ff:fe05:7d90 prefixlen 64 scopeid 0x20<link>
ether dc:a6:32:05:7d:90 txqueuelen 1000 (Ethernet)
RX packets 10854428 bytes 15452600391 (14.3 GiB)
RX errors 0 dropped 41 overruns 0 frame 0
TX packets 1148656 bytes 88233353 (84.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 9 bytes 720 (720.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9 bytes 720 (720.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.55 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::dea6:32ff:fe05:7d91 prefixlen 64 scopeid 0x20<link>
ether dc:a6:32:05:7d:91 txqueuelen 1000 (Ethernet)
RX packets 10470 bytes 564849 (551.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 14 bytes 1376 (1.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 |
3.
on maching 10.0.0.34: ping 10.0.0.55
on machine five: tcpdump icmp -i wlan0
[no output.]
however, if I run tcpdump icmp, then:
| Code: | dropped privs to pcap
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:18:08.927930 IP zen > 10.0.0.55: ICMP echo request, id 1, seq 129, length 64
08:18:08.928027 IP 10.0.0.55 > zen: ICMP echo reply, id 1, seq 129, length 64
08:18:09.929396 IP zen > 10.0.0.55: ICMP echo request, id 1, seq 130, length 64
08:18:09.929473 IP 10.0.0.55 > zen: ICMP echo reply, id 1, seq 130, length 64
08:18:10.930892 IP zen > 10.0.0.55: ICMP echo request, id 1, seq 131, length 64
08:18:10.930949 IP 10.0.0.55 > zen: ICMP echo reply, id 1, seq 131, length 64
08:18:11.932366 IP zen > 10.0.0.55: ICMP echo request, id 1, seq 132, length 64
08:18:11.932415 IP 10.0.0.55 > zen: ICMP echo reply, id 1, seq 132, length 64
08:18:12.933588 IP zen > 10.0.0.55: ICMP echo request, id 1, seq 133, length 64
08:18:12.933647 IP 10.0.0.55 > zen: ICMP echo reply, id 1, seq 133, length 64
08:18:13.935066 IP zen > 10.0.0.55: ICMP echo request, id 1, seq 134, length 64
08:18:13.935118 IP 10.0.0.55 > zen: ICMP echo reply, id 1, seq 134, length 64
08:18:14.936807 IP zen > 10.0.0.55: ICMP echo request, id 1, seq 135, length 64
08:18:14.936862 IP 10.0.0.55 > zen: ICMP echo reply, id 1, seq 135, length 64
08:18:15.938399 IP zen > 10.0.0.55: ICMP echo request, id 1, seq 136, length 64
08:18:15.938455 IP 10.0.0.55 > zen: ICMP echo reply, id 1, seq 136, length 64
08:18:16.939883 IP zen > 10.0.0.55: ICMP echo request, id 1, seq 137, length 64
08:18:16.939937 IP 10.0.0.55 > zen: ICMP echo reply, id 1, seq 137, length 64
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel
|
NeddySeagoon,
five ~ # route
| Code: | Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default RT-AC66U_B1-A8D 0.0.0.0 UG 0 0 0 wlan0
default RT-AC66U_B1-A8D 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
|
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Thu Apr 01, 2021 2:57 pm Post subject: |
|
|
EliasJonsson,
| Code: | Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 |
Is wrong as you have two interfaces in the same subnet.
Packets to 10.0.0.0/24 will always go via wlan0 as its the first route to match.
Rules are tested from the bottom of the routing table upwards until a match is found.
If you want to have two interfaces in the same subnet, they must have different Metrics.
Think of metric as cost. The interface with the lowest metric will be used.
| Code: | Destination Gateway Genmask Flags Metric Ref Use Iface
default RT-AC66U_B1-A8D 0.0.0.0 UG 0 0 0 wlan0
default RT-AC66U_B1-A8D 0.0.0.0 UG 0 0 0 eth0 |
You should only have one default route.
Everything not going to 10.0.0.0/24 will go out of eth0.
Again a metric can be used to prefer one interface over the other.
What is it your really want so achieve?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
EliasJonsson
n00b
Joined: 18 Oct 2017
Posts: 53
|
| Posted: Fri Apr 02, 2021 4:56 am Post subject: |
|
|
NeddySeagoon,
Thank you for pointing out my mistakes!
The machine 'five' is not always plugged in and running since it is more or less a clone of another live production Linux system; machine 'gen'. If there are big changes to be made on gen, I first plug in five and commit the changes to five, making sure nothing breaks. If successful, the changes will be made to the production environment, gen.
What I really want to achieve is the ability to not having to plug in the network cable as it is a little troublesome to do so. Sometimes though, I need the extra network speed that the network cable brings so I plug in the network cable to gain more speed. In the best of worlds, the transition between using a wireless connection and a wired one would be seamless. I think I can achieve that by creating a bridge and attach both network interfaces to that bridge, I;m not sure yet but I will give it a try sometime in the near future. |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Sun Apr 04, 2021 3:05 pm Post subject: |
|
|
| EliasJonsson wrote: | | What I really want to achieve is the ability to not having to plug in the network cable as it is a little troublesome to do so. Sometimes though, I need the extra network speed that the network cable brings so I plug in the network cable to gain more speed. In the best of worlds, the transition between using a wireless connection and a wired one would be seamless. I think I can achieve that by creating a bridge and attach both network interfaces to that bridge, I;m not sure yet but I will give it a try sometime in the near future. |
You can achieve this by using dhcpcd to manage both interfaces.
It not only facilitates having the same subnet on different interfaces but it also allows the same IP address on both interfaces.
Now there are some caveats with this on Linux thanks to route metrics - the transition from one interface to the other may take a little time and if both interfaces are up only new connections will use the preferred interface - old/current connections *may* stay as they are (this is app dependant). If one interface goes down then it will change fine.
The same setup using NetBSD instead works flawlessly, but that's because I made some kernel changes to facilitate this.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3135
|
| Posted: Sun Apr 04, 2021 3:39 pm Post subject: |
|
|
| Quote: | | Code: | Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default RT-AC66U_B1-A8D 0.0.0.0 UG 0 0 0 wlan0
default RT-AC66U_B1-A8D 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 |
|
Assuming that your masks are correct (And so both interfaces are on the same network):
Set a metric. Metric represents cost of using the particular route, the typical value for wifi is 600.
Exact value doesn't matter, as long as the values for different routes are in the right order though.
Setting metric for wifi to a higher value than eth0 will make eth0 the preferred interface (will be used wheneveer possible) and wifi when you unplug the wire.
Enabling ipv4 forwarding may be necessary to maintain connections started with the "wrong" interface. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
