IPv6 addresses on LAN but disabled in settings

[vandriver]

Morning,

I have several devices on my network that seem to have IPv6 addresses and those devices are also dropping Rx packets on the Lan and sometimes on the WAN. Well when I say dropping packets, I'm still very early days with wireshark so can't confirm if the packets are actually dropped or not but in the devices setting pages they show an IPv6 address and a lot of dropped Rx packets.
The router is an ac86u running the latest merlin and I have several ac86u access points running the latest stock firmware. IPv6 is switched off and firewall left on.

Hopefully I will get to the bottom off it over the coming weeks after learning wireshark but was just wondering if anyone had any ideas what could be going on in my network?

I did have IPv6 enabled on some PC's and disabled that but it made no difference.

I have another 20 of the same devices on my network and they all have IPv4 addresses with no dropped Rx packets showing.

 

[vandriver]

running /sbin/ifconfigbr0
Link encap:Ethernet HWaddr 94:9F:3E:72:E8:7A inet addr:192.168.1.17 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::969f:3eff:fe72:e87a%1995899440/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:505413 errors:0 dropped:421 overruns:0 frame:0 TX packets:16141 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:96689349 (92.2 MiB) TX bytes:5922791 (5.6 MiB)

 

[Ripshod]

Addresses starting with fe80 are link-local. These are assigned the same as 192.168 addresses and have no direct access to the web.

 

[vandriver]

Addresses starting with fe80 are link-local. These are assigned the same as 192.168 addresses and have no direct access to the web.

I am understanding this correctly? The devices starting with fe80 are link-local and instead of those devices using the router to get their IPv4 address, they are using some other device on my network that has IPv6 enabled to get that fe80 address and I need to find that device, disabled IPv6, reboot the problem devices and they should then have the IPv4 address again?

 

[Crimliar]

On Windows at least, you can turn off the WiFi and unplug any ethernet cable in a machine, and if it has IPv6 enabled on the WiFi adapter it'll still create its own link-local IPv6 address!
Wireshark can be a great tool if you are looking to solve an issue and understand how things work or even look up how things work, but if you are not sure then it can get you worried for no good reason!

 

[vandriver]

On Windows at least, you can turn off the WiFi and unplug any ethernet cable in a machine, and if it has IPv6 enabled on the WiFi adapter it'll still create its own link-local IPv6 address!
Wireshark can be a great tool if you are looking to solve an issue and understand how things work or even look up how things work, but if you are not sure then it can get you worried for no good reason!

I have a couple of plug and play ethernet to usb devices on my network that have IPv6 enabled I'm sure, although they are not connected to the devices I don't want to have link-local addresses, could the ethernet to usb adaptors be causing the problem devices to get the link-local addresses do you think?

 

[Crimliar]

I am understanding this correctly? The devices starting with fe80 are link-local and instead of those devices using the router to get their IPv4 address, they are using some other device on my network that has IPv6 enabled to get that fe80 address and I need to find that device, disabled IPv6, reboot the problem devices and they should then have the IPv4 address again?

Mostly on a local device IPv4 and IPv6 will "dual stack". This means that devices will have both an IPv4 address and probably multiple (4 is common on an IPv6 compliant network) IPv6 addresses. You don't need to turn off IPv6 as your IPv4 connections are still working, and the available bandwidth on many home networks can mean that doing so is pointless in performance terms.
*If you believe you have a problem, then describe the problem rather than how you believe you need to deal with it!

 

[vandriver]

*If you believe you have a problem, then describe the problem rather than how you believe you need to deal with it!

Sorry I did describe the problem in my first post, but not very well obviously.

Some devices in my network are dropping Rx packets on the Lan and wan, all of the problem devices have local-link addresses and I believe this is somehow related to the Rx packets being dropped. Why do I think that? Because I have 20 of the same devices elsewhere on my network and they are not dropping packets and don't have local-link addresses.

 

[Crimliar]

What is the result of devices on your network dropping packets - what is going wrong? And are you only "aware" of the dropped packets because of Wireshark? I'm sorry if I'm sounding pedantic, but it's not uncommon to find people trying to fix problems that don't really exist! If your IOT is not performing correctly what is it doing?
*Not all data on your network is "broadcast", so data exchanges on any kind of switched route (WiFi or Ethernet) may not be visible, or only partially visible to Wireshark!

 

[vandriver]

From what you guys are saying, it doesn't sound like there is a problem.

What is the result of devices on your network dropping packets - what is going wrong? And are you only "aware" of the dropped packets because of Wireshark? I'm sorry if I'm sounding pedantic, but it's not uncommon to find people trying to fix problems that don't really exist! If your IOT is not performing correctly what is it doing?

No worries, I totally get it and what your sayings, it's important for me to try and be as specific as possible as you guys probably don't have a crystal ball, but I'm not really understanding what is going on myself to be fair.

All I have noticed is 5 of 25 devices are dropping Rx packets on the Lan and wan and those 5 devices have local-link addresses.

From and end user perspective, when one of all 5 of those devices are connected to the network them in sure there is a couple of second lag introduced to the whole 25 devices when trying to use them.

Honestly I don't want to wait anyone's time, it's maybe not an problem from what you guys are saying, it was one of those ones I thought well if I could find out how to get those 5 devices back to having an IPv4 address I could see if the Rx errors stopped.

 

[vandriver]

What is the result of devices on your network dropping packets - what is going wrong? And are you only "aware" of the dropped packets because of Wireshark? I'm sorry if I'm sounding pedantic, but it's not uncommon to find people trying to fix problems that don't really exist! If your IOT is not performing correctly what is it doing?
*Not all data on your network is "broadcast", so data exchanges on any kind of switched route (WiFi or Ethernet) may not be visible, or only partially visible to Wireshark!

The devices have their own interface which can be accessed via a browser. The interface is saying that device is dropping packets.
I went to learn wireshark to try and verify if what the interface was accurate but then thought maybe someone on the forums would know lol

The devices work okay and don't drop off the network, only some lag is noticeable.

 

[vandriver]

On the back of your posts and advice I found this too:

In IPv4, link-local addresses are normally only used when no external, stateful mechanism of address configuration exists, such as the Dynamic Host Configuration Protocol (DHCP), or when another primary configuration method has failed.

So I'll start by checking my configuration. Thanks again for the replys, much appreciated. Have a good one.

 

[Crimliar]

One final heads up. My experience with IoT devices and poor connections has mostly come down to their being shielded. I no longer have any Shelly devices because I have UK metal backboxes which is almost the same as putting them in a Faraday cage, but I wouldn't want to put them in plastic backboxes because the Shellys get way too warm for my liking. And my Netatmo heating valve controllers I use an AiMesh node to take the signal to them around a metal cabinet door!