Kali Linux - Wired connection failing unless machine gets restarted

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












1















I am using the newest version of Kali Linux (2018.4) but I have the following unusual issue. If I boot my machine up with the ethernet cable plugged in, the eth0 interface works just fine. However, if I boot up with WiFi (no cable plugged in), and I try to plug the cable in after more than 30~ minutes of system uptime, the wired connection will fail.



It just says Wired connecting and then pops out Activation of network connection failed. The weirdest part is that it works successfully during the first 30 minutes, then I have to always restart the machine with the cable plugged in so I can use the wired connection.



I tried resetting the network manager:
/etc/init.d/network-manager restart



Also bringing eth0 interface down and then up, but no luck. Anyone has/had this issue?



  • Kali is not running in a VM;

  • System information: Linux kali 4.19.0-kali1-amd64 #1 SMP Debian 4.19.13-1kali1 (2019-01-03) x86_64 GNU/Linux


  • Network card info:



    02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
    03:00.0 Network controller: Intel Corporation Wireless 3165 (rev 79)


Here are the log entries from /var/log/syslog..



The moment I plug the cable in:



Jan 31 13:07:30 kali kernel: [ 9597.698217] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow control off
Jan 31 13:07:30 kali NetworkManager[15820]: <info> [1548936450.7691] device (eth0): carrier: link connected


After a minute:



Jan 31 13:08:08 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Jan 31 13:08:12 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Jan 31 13:08:19 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9965] device (eth0): DHCPv4: grace period expired
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9966] device (eth0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Jan 31 13:08:31 kali NetworkManager[15820]: <warn> [1548936511.9979] device (eth0): Activation: failed for connection 'Wired connection 1'
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9984] device (eth0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0206] dhcp4 (eth0): canceled DHCP transaction, DHCP client pid 16601
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0206] dhcp4 (eth0): state changed fail -> done
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0219] policy: auto-activating connection 'Wired connection 1' (dfe04dbc-7123-4a36-bf7b-6542c03b6c4c)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0230] device (eth0): Activation: starting connection 'Wired connection 1' (dfe04dbc-7123-4a36-bf7b-6542c03b6c4c)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0231] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0235] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0240] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0242] dhcp4 (eth0): activation: beginning transaction (timeout in 45 seconds)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0259] dhcp4 (eth0): dhclient started with pid 17015
Jan 31 13:08:32 kali gnome-shell[1118]: Object NM.ActiveConnection (0x55a06d19cc70), has been already finalized. Impossible to get any property from it.
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: == Stack trace for context 0x55a06bb70340 ==
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #0 0x55a06bf28610 i resource:///org/gnome/shell/ui/status/network.js:2045 (0x7f156c121890 @ 93)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #1 0x7ffc37d73840 b resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f15802b5de0 @ 71)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #2 0x55a06bf28580 i resource:///org/gnome/shell/ui/status/network.js:1854 (0x7f156c120e68 @ 138)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #3 0x7ffc37d74b80 b resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f15802b5de0 @ 71)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #4 0x7ffc37d75390 b self-hosted:918 (0x7f15802f1230 @ 394)
Jan 31 13:08:32 kali gnome-shell[1118]: Object NM.ActiveConnection (0x55a06d19cc70), has been already finalized. Impossible to get any property from it.









share|improve this question



















  • 1





    see related unix.stackexchange.com/questions/252210/…

    – Rui F Ribeiro
    Jan 31 at 12:44











  • Do you have a hot-plug on eth0 inside of the interfaces file, that'll definitely do what you're describing, or perhaps you need to enter a hot-plug for eth0 if you're going to attach/detach the ether net cable

    – hello moto
    Feb 1 at 10:46
















1















I am using the newest version of Kali Linux (2018.4) but I have the following unusual issue. If I boot my machine up with the ethernet cable plugged in, the eth0 interface works just fine. However, if I boot up with WiFi (no cable plugged in), and I try to plug the cable in after more than 30~ minutes of system uptime, the wired connection will fail.



It just says Wired connecting and then pops out Activation of network connection failed. The weirdest part is that it works successfully during the first 30 minutes, then I have to always restart the machine with the cable plugged in so I can use the wired connection.



I tried resetting the network manager:
/etc/init.d/network-manager restart



Also bringing eth0 interface down and then up, but no luck. Anyone has/had this issue?



  • Kali is not running in a VM;

  • System information: Linux kali 4.19.0-kali1-amd64 #1 SMP Debian 4.19.13-1kali1 (2019-01-03) x86_64 GNU/Linux


  • Network card info:



    02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
    03:00.0 Network controller: Intel Corporation Wireless 3165 (rev 79)


Here are the log entries from /var/log/syslog..



The moment I plug the cable in:



Jan 31 13:07:30 kali kernel: [ 9597.698217] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow control off
Jan 31 13:07:30 kali NetworkManager[15820]: <info> [1548936450.7691] device (eth0): carrier: link connected


After a minute:



Jan 31 13:08:08 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Jan 31 13:08:12 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Jan 31 13:08:19 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9965] device (eth0): DHCPv4: grace period expired
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9966] device (eth0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Jan 31 13:08:31 kali NetworkManager[15820]: <warn> [1548936511.9979] device (eth0): Activation: failed for connection 'Wired connection 1'
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9984] device (eth0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0206] dhcp4 (eth0): canceled DHCP transaction, DHCP client pid 16601
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0206] dhcp4 (eth0): state changed fail -> done
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0219] policy: auto-activating connection 'Wired connection 1' (dfe04dbc-7123-4a36-bf7b-6542c03b6c4c)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0230] device (eth0): Activation: starting connection 'Wired connection 1' (dfe04dbc-7123-4a36-bf7b-6542c03b6c4c)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0231] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0235] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0240] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0242] dhcp4 (eth0): activation: beginning transaction (timeout in 45 seconds)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0259] dhcp4 (eth0): dhclient started with pid 17015
Jan 31 13:08:32 kali gnome-shell[1118]: Object NM.ActiveConnection (0x55a06d19cc70), has been already finalized. Impossible to get any property from it.
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: == Stack trace for context 0x55a06bb70340 ==
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #0 0x55a06bf28610 i resource:///org/gnome/shell/ui/status/network.js:2045 (0x7f156c121890 @ 93)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #1 0x7ffc37d73840 b resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f15802b5de0 @ 71)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #2 0x55a06bf28580 i resource:///org/gnome/shell/ui/status/network.js:1854 (0x7f156c120e68 @ 138)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #3 0x7ffc37d74b80 b resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f15802b5de0 @ 71)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #4 0x7ffc37d75390 b self-hosted:918 (0x7f15802f1230 @ 394)
Jan 31 13:08:32 kali gnome-shell[1118]: Object NM.ActiveConnection (0x55a06d19cc70), has been already finalized. Impossible to get any property from it.









share|improve this question



















  • 1





    see related unix.stackexchange.com/questions/252210/…

    – Rui F Ribeiro
    Jan 31 at 12:44











  • Do you have a hot-plug on eth0 inside of the interfaces file, that'll definitely do what you're describing, or perhaps you need to enter a hot-plug for eth0 if you're going to attach/detach the ether net cable

    – hello moto
    Feb 1 at 10:46














1












1








1








I am using the newest version of Kali Linux (2018.4) but I have the following unusual issue. If I boot my machine up with the ethernet cable plugged in, the eth0 interface works just fine. However, if I boot up with WiFi (no cable plugged in), and I try to plug the cable in after more than 30~ minutes of system uptime, the wired connection will fail.



It just says Wired connecting and then pops out Activation of network connection failed. The weirdest part is that it works successfully during the first 30 minutes, then I have to always restart the machine with the cable plugged in so I can use the wired connection.



I tried resetting the network manager:
/etc/init.d/network-manager restart



Also bringing eth0 interface down and then up, but no luck. Anyone has/had this issue?



  • Kali is not running in a VM;

  • System information: Linux kali 4.19.0-kali1-amd64 #1 SMP Debian 4.19.13-1kali1 (2019-01-03) x86_64 GNU/Linux


  • Network card info:



    02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
    03:00.0 Network controller: Intel Corporation Wireless 3165 (rev 79)


Here are the log entries from /var/log/syslog..



The moment I plug the cable in:



Jan 31 13:07:30 kali kernel: [ 9597.698217] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow control off
Jan 31 13:07:30 kali NetworkManager[15820]: <info> [1548936450.7691] device (eth0): carrier: link connected


After a minute:



Jan 31 13:08:08 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Jan 31 13:08:12 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Jan 31 13:08:19 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9965] device (eth0): DHCPv4: grace period expired
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9966] device (eth0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Jan 31 13:08:31 kali NetworkManager[15820]: <warn> [1548936511.9979] device (eth0): Activation: failed for connection 'Wired connection 1'
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9984] device (eth0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0206] dhcp4 (eth0): canceled DHCP transaction, DHCP client pid 16601
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0206] dhcp4 (eth0): state changed fail -> done
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0219] policy: auto-activating connection 'Wired connection 1' (dfe04dbc-7123-4a36-bf7b-6542c03b6c4c)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0230] device (eth0): Activation: starting connection 'Wired connection 1' (dfe04dbc-7123-4a36-bf7b-6542c03b6c4c)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0231] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0235] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0240] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0242] dhcp4 (eth0): activation: beginning transaction (timeout in 45 seconds)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0259] dhcp4 (eth0): dhclient started with pid 17015
Jan 31 13:08:32 kali gnome-shell[1118]: Object NM.ActiveConnection (0x55a06d19cc70), has been already finalized. Impossible to get any property from it.
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: == Stack trace for context 0x55a06bb70340 ==
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #0 0x55a06bf28610 i resource:///org/gnome/shell/ui/status/network.js:2045 (0x7f156c121890 @ 93)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #1 0x7ffc37d73840 b resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f15802b5de0 @ 71)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #2 0x55a06bf28580 i resource:///org/gnome/shell/ui/status/network.js:1854 (0x7f156c120e68 @ 138)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #3 0x7ffc37d74b80 b resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f15802b5de0 @ 71)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #4 0x7ffc37d75390 b self-hosted:918 (0x7f15802f1230 @ 394)
Jan 31 13:08:32 kali gnome-shell[1118]: Object NM.ActiveConnection (0x55a06d19cc70), has been already finalized. Impossible to get any property from it.









share|improve this question
















I am using the newest version of Kali Linux (2018.4) but I have the following unusual issue. If I boot my machine up with the ethernet cable plugged in, the eth0 interface works just fine. However, if I boot up with WiFi (no cable plugged in), and I try to plug the cable in after more than 30~ minutes of system uptime, the wired connection will fail.



It just says Wired connecting and then pops out Activation of network connection failed. The weirdest part is that it works successfully during the first 30 minutes, then I have to always restart the machine with the cable plugged in so I can use the wired connection.



I tried resetting the network manager:
/etc/init.d/network-manager restart



Also bringing eth0 interface down and then up, but no luck. Anyone has/had this issue?



  • Kali is not running in a VM;

  • System information: Linux kali 4.19.0-kali1-amd64 #1 SMP Debian 4.19.13-1kali1 (2019-01-03) x86_64 GNU/Linux


  • Network card info:



    02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
    03:00.0 Network controller: Intel Corporation Wireless 3165 (rev 79)


Here are the log entries from /var/log/syslog..



The moment I plug the cable in:



Jan 31 13:07:30 kali kernel: [ 9597.698217] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow control off
Jan 31 13:07:30 kali NetworkManager[15820]: <info> [1548936450.7691] device (eth0): carrier: link connected


After a minute:



Jan 31 13:08:08 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Jan 31 13:08:12 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Jan 31 13:08:19 kali dhclient[16601]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9965] device (eth0): DHCPv4: grace period expired
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9966] device (eth0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Jan 31 13:08:31 kali NetworkManager[15820]: <warn> [1548936511.9979] device (eth0): Activation: failed for connection 'Wired connection 1'
Jan 31 13:08:31 kali NetworkManager[15820]: <info> [1548936511.9984] device (eth0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0206] dhcp4 (eth0): canceled DHCP transaction, DHCP client pid 16601
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0206] dhcp4 (eth0): state changed fail -> done
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0219] policy: auto-activating connection 'Wired connection 1' (dfe04dbc-7123-4a36-bf7b-6542c03b6c4c)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0230] device (eth0): Activation: starting connection 'Wired connection 1' (dfe04dbc-7123-4a36-bf7b-6542c03b6c4c)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0231] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0235] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0240] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0242] dhcp4 (eth0): activation: beginning transaction (timeout in 45 seconds)
Jan 31 13:08:32 kali NetworkManager[15820]: <info> [1548936512.0259] dhcp4 (eth0): dhclient started with pid 17015
Jan 31 13:08:32 kali gnome-shell[1118]: Object NM.ActiveConnection (0x55a06d19cc70), has been already finalized. Impossible to get any property from it.
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: == Stack trace for context 0x55a06bb70340 ==
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #0 0x55a06bf28610 i resource:///org/gnome/shell/ui/status/network.js:2045 (0x7f156c121890 @ 93)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #1 0x7ffc37d73840 b resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f15802b5de0 @ 71)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #2 0x55a06bf28580 i resource:///org/gnome/shell/ui/status/network.js:1854 (0x7f156c120e68 @ 138)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #3 0x7ffc37d74b80 b resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f15802b5de0 @ 71)
Jan 31 13:08:32 kali org.gnome.Shell.desktop[1118]: #4 0x7ffc37d75390 b self-hosted:918 (0x7f15802f1230 @ 394)
Jan 31 13:08:32 kali gnome-shell[1118]: Object NM.ActiveConnection (0x55a06d19cc70), has been already finalized. Impossible to get any property from it.






networking kali-linux networkmanager ethernet






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 31 at 12:18







anthony757618

















asked Jan 31 at 11:57









anthony757618anthony757618

62




62







  • 1





    see related unix.stackexchange.com/questions/252210/…

    – Rui F Ribeiro
    Jan 31 at 12:44











  • Do you have a hot-plug on eth0 inside of the interfaces file, that'll definitely do what you're describing, or perhaps you need to enter a hot-plug for eth0 if you're going to attach/detach the ether net cable

    – hello moto
    Feb 1 at 10:46













  • 1





    see related unix.stackexchange.com/questions/252210/…

    – Rui F Ribeiro
    Jan 31 at 12:44











  • Do you have a hot-plug on eth0 inside of the interfaces file, that'll definitely do what you're describing, or perhaps you need to enter a hot-plug for eth0 if you're going to attach/detach the ether net cable

    – hello moto
    Feb 1 at 10:46








1




1





see related unix.stackexchange.com/questions/252210/…

– Rui F Ribeiro
Jan 31 at 12:44





see related unix.stackexchange.com/questions/252210/…

– Rui F Ribeiro
Jan 31 at 12:44













Do you have a hot-plug on eth0 inside of the interfaces file, that'll definitely do what you're describing, or perhaps you need to enter a hot-plug for eth0 if you're going to attach/detach the ether net cable

– hello moto
Feb 1 at 10:46






Do you have a hot-plug on eth0 inside of the interfaces file, that'll definitely do what you're describing, or perhaps you need to enter a hot-plug for eth0 if you're going to attach/detach the ether net cable

– hello moto
Feb 1 at 10:46











1 Answer
1






active

oldest

votes


















1














I wasn't going to write this up as an answer, since it doesn't directly solve the problem as described, but I've decided I should, so that I can more easily expand on the information provided.



There are problems using the r8169 driver with Realtek 8168/8111 cards.



The guide at https://www.unixblogger.com/how-to-get-your-realtek-rtl8111rtl8168-working-updated-guide/ will show you how to resolve the issue for Debian and Ubuntu, where they write,




The r8169 is loaded when the r8168 is not found on your system. This will give you a network and internet connection, but with the r8169 driver your RTL8168 card will be very unstable._"




Essentially, on these platforms it's just a case of adding the non-free repository and installing the correct driver. Once it's present, the r8169 driver will be ignored.



On other platforms (which may or may not include Kali) you may have to use the manual process described there, which is pretty much about downloading the r8168 driver from Realtek and building it locally. Unfortunately I can't help you with precise instructions for Kali as I don't have that to hand, but you might find equivalent solutions in the Kali repositories.






share|improve this answer























  • I see, so the problem here is not DHCP at all? Because I was checking how the DHCPv4: grace period expired log message was being shown but this seems to be a driver problem. I'm always nervous when it comes to installing packets such as this r8168-dkms one, but I might give it a shot. Thanks for looking it up nevertheless.

    – anthony757618
    Jan 31 at 12:39












  • @anthony757618 the DKMS approach is a really good one, because it leaves the driver as a loadable module, so you don't need to rebuild the entire kernel and if there's a problem you can just unload and delete it.

    – roaima
    Jan 31 at 13:58










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


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f497918%2fkali-linux-wired-connection-failing-unless-machine-gets-restarted%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









1














I wasn't going to write this up as an answer, since it doesn't directly solve the problem as described, but I've decided I should, so that I can more easily expand on the information provided.



There are problems using the r8169 driver with Realtek 8168/8111 cards.



The guide at https://www.unixblogger.com/how-to-get-your-realtek-rtl8111rtl8168-working-updated-guide/ will show you how to resolve the issue for Debian and Ubuntu, where they write,




The r8169 is loaded when the r8168 is not found on your system. This will give you a network and internet connection, but with the r8169 driver your RTL8168 card will be very unstable._"




Essentially, on these platforms it's just a case of adding the non-free repository and installing the correct driver. Once it's present, the r8169 driver will be ignored.



On other platforms (which may or may not include Kali) you may have to use the manual process described there, which is pretty much about downloading the r8168 driver from Realtek and building it locally. Unfortunately I can't help you with precise instructions for Kali as I don't have that to hand, but you might find equivalent solutions in the Kali repositories.






share|improve this answer























  • I see, so the problem here is not DHCP at all? Because I was checking how the DHCPv4: grace period expired log message was being shown but this seems to be a driver problem. I'm always nervous when it comes to installing packets such as this r8168-dkms one, but I might give it a shot. Thanks for looking it up nevertheless.

    – anthony757618
    Jan 31 at 12:39












  • @anthony757618 the DKMS approach is a really good one, because it leaves the driver as a loadable module, so you don't need to rebuild the entire kernel and if there's a problem you can just unload and delete it.

    – roaima
    Jan 31 at 13:58















1














I wasn't going to write this up as an answer, since it doesn't directly solve the problem as described, but I've decided I should, so that I can more easily expand on the information provided.



There are problems using the r8169 driver with Realtek 8168/8111 cards.



The guide at https://www.unixblogger.com/how-to-get-your-realtek-rtl8111rtl8168-working-updated-guide/ will show you how to resolve the issue for Debian and Ubuntu, where they write,




The r8169 is loaded when the r8168 is not found on your system. This will give you a network and internet connection, but with the r8169 driver your RTL8168 card will be very unstable._"




Essentially, on these platforms it's just a case of adding the non-free repository and installing the correct driver. Once it's present, the r8169 driver will be ignored.



On other platforms (which may or may not include Kali) you may have to use the manual process described there, which is pretty much about downloading the r8168 driver from Realtek and building it locally. Unfortunately I can't help you with precise instructions for Kali as I don't have that to hand, but you might find equivalent solutions in the Kali repositories.






share|improve this answer























  • I see, so the problem here is not DHCP at all? Because I was checking how the DHCPv4: grace period expired log message was being shown but this seems to be a driver problem. I'm always nervous when it comes to installing packets such as this r8168-dkms one, but I might give it a shot. Thanks for looking it up nevertheless.

    – anthony757618
    Jan 31 at 12:39












  • @anthony757618 the DKMS approach is a really good one, because it leaves the driver as a loadable module, so you don't need to rebuild the entire kernel and if there's a problem you can just unload and delete it.

    – roaima
    Jan 31 at 13:58













1












1








1







I wasn't going to write this up as an answer, since it doesn't directly solve the problem as described, but I've decided I should, so that I can more easily expand on the information provided.



There are problems using the r8169 driver with Realtek 8168/8111 cards.



The guide at https://www.unixblogger.com/how-to-get-your-realtek-rtl8111rtl8168-working-updated-guide/ will show you how to resolve the issue for Debian and Ubuntu, where they write,




The r8169 is loaded when the r8168 is not found on your system. This will give you a network and internet connection, but with the r8169 driver your RTL8168 card will be very unstable._"




Essentially, on these platforms it's just a case of adding the non-free repository and installing the correct driver. Once it's present, the r8169 driver will be ignored.



On other platforms (which may or may not include Kali) you may have to use the manual process described there, which is pretty much about downloading the r8168 driver from Realtek and building it locally. Unfortunately I can't help you with precise instructions for Kali as I don't have that to hand, but you might find equivalent solutions in the Kali repositories.






share|improve this answer













I wasn't going to write this up as an answer, since it doesn't directly solve the problem as described, but I've decided I should, so that I can more easily expand on the information provided.



There are problems using the r8169 driver with Realtek 8168/8111 cards.



The guide at https://www.unixblogger.com/how-to-get-your-realtek-rtl8111rtl8168-working-updated-guide/ will show you how to resolve the issue for Debian and Ubuntu, where they write,




The r8169 is loaded when the r8168 is not found on your system. This will give you a network and internet connection, but with the r8169 driver your RTL8168 card will be very unstable._"




Essentially, on these platforms it's just a case of adding the non-free repository and installing the correct driver. Once it's present, the r8169 driver will be ignored.



On other platforms (which may or may not include Kali) you may have to use the manual process described there, which is pretty much about downloading the r8168 driver from Realtek and building it locally. Unfortunately I can't help you with precise instructions for Kali as I don't have that to hand, but you might find equivalent solutions in the Kali repositories.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 31 at 12:29









roaimaroaima

44.8k755121




44.8k755121












  • I see, so the problem here is not DHCP at all? Because I was checking how the DHCPv4: grace period expired log message was being shown but this seems to be a driver problem. I'm always nervous when it comes to installing packets such as this r8168-dkms one, but I might give it a shot. Thanks for looking it up nevertheless.

    – anthony757618
    Jan 31 at 12:39












  • @anthony757618 the DKMS approach is a really good one, because it leaves the driver as a loadable module, so you don't need to rebuild the entire kernel and if there's a problem you can just unload and delete it.

    – roaima
    Jan 31 at 13:58

















  • I see, so the problem here is not DHCP at all? Because I was checking how the DHCPv4: grace period expired log message was being shown but this seems to be a driver problem. I'm always nervous when it comes to installing packets such as this r8168-dkms one, but I might give it a shot. Thanks for looking it up nevertheless.

    – anthony757618
    Jan 31 at 12:39












  • @anthony757618 the DKMS approach is a really good one, because it leaves the driver as a loadable module, so you don't need to rebuild the entire kernel and if there's a problem you can just unload and delete it.

    – roaima
    Jan 31 at 13:58
















I see, so the problem here is not DHCP at all? Because I was checking how the DHCPv4: grace period expired log message was being shown but this seems to be a driver problem. I'm always nervous when it comes to installing packets such as this r8168-dkms one, but I might give it a shot. Thanks for looking it up nevertheless.

– anthony757618
Jan 31 at 12:39






I see, so the problem here is not DHCP at all? Because I was checking how the DHCPv4: grace period expired log message was being shown but this seems to be a driver problem. I'm always nervous when it comes to installing packets such as this r8168-dkms one, but I might give it a shot. Thanks for looking it up nevertheless.

– anthony757618
Jan 31 at 12:39














@anthony757618 the DKMS approach is a really good one, because it leaves the driver as a loadable module, so you don't need to rebuild the entire kernel and if there's a problem you can just unload and delete it.

– roaima
Jan 31 at 13:58





@anthony757618 the DKMS approach is a really good one, because it leaves the driver as a loadable module, so you don't need to rebuild the entire kernel and if there's a problem you can just unload and delete it.

– roaima
Jan 31 at 13:58

















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














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f497918%2fkali-linux-wired-connection-failing-unless-machine-gets-restarted%23new-answer', 'question_page');

);

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






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?