User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Mon Oct 17, 2016 4:38 pm

Died again this afternoon. Still one non-BCDC with 0x56.

Any idea how we get the RPF interested in this bug?

User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Tue Oct 18, 2016 10:37 pm

I've posted a bug to the firmware git repo, with a link back here. Hopefully someone will look at it.

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Thu Oct 20, 2016 3:03 pm

dickon wrote:I've posted a bug to the firmware git repo, with a link back here. Hopefully someone will look at it.
That'd be nice. Mine keeps on crashing, too. I have reverted to the regular raspbian kernel; did a clean install, just to make sure it's not the rpi-update causing probs but nothing changed. Keep on getting non-BCDC messages about every 60 seconds, flags 0x36 and 0x3e - and sometimes the dreaded "kevent 0". Also noticed this:

Code: Select all

brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
I have definitely set the region code correctly using raspi-config and also via "iw reg set". Seems like this firmware is seriously flawed.

User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Thu Oct 20, 2016 3:11 pm

Mine does that before hostapd starts. That then sets it correctly, via

Code: Select all

country_code=GB
in /etc/hostapd/hostapd.conf. Had endless problems with it until I realised it had to be in upper-case.

No noise on the bug yet.

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Fri Oct 21, 2016 11:50 am

I have such a line in my hostapd.conf but still get the error. Used upper-case.

Code: Select all

brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
cfg80211: World regulatory domain updated:
cfg80211:  DFS Master region: unset
I don't know what else to do?!

User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Fri Oct 21, 2016 11:54 am

What's it set to?

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Fri Oct 21, 2016 12:03 pm

dickon wrote:What's it set to?
Oh never mind, I had "country=" instead of "country_code=", apparently! Now it sets it correctly. Cheers!

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Tue Oct 25, 2016 2:18 pm

Since the new kernel update (4.4.26) things seem to have become even more unstable. I am therefore trying something new: Instead of bridging the interfaces, I am running a DHCP server on the pi's wlan0 with a different subnet, using it as a router. Access to eth0 subnet is established by adding a static route to the dhcpd config. So far, this hasn't produced a single "non-BCDC" message nor have I received a "kevent 0". I know, it's not as elegant as extending the existing wifi but it seems to be working a hell lot better.

@dickon: Might this be a solution for you as well?

User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Tue Oct 25, 2016 2:26 pm

No, because it breaks roaming and switching between wired and wireless (which is something I do less often, but still do).

Really, I want this bug fixed.

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Tue Oct 25, 2016 4:36 pm

dickon wrote:No, because it breaks roaming and switching between wired and wireless (which is something I do less often, but still do).

Really, I want this bug fixed.
Me too and I'd like to have these features as well, especially roaming. Client-side switching between the different networks doesn't work as seamlessly as I had hoped. Guess it's back to square one. :evil:

sail1943
Posts: 4
Joined: Fri Nov 04, 2016 3:35 am

Re: eth0: kevent 0 may have been dropped

Fri Nov 04, 2016 3:49 am

I have this problem too when I try to set my raspberry 3b up as an ap, even with an offical power supply.
And finally I found that the firmware version with 4.4.11 kernel is much more stable, maybe you can have a try.

Code: Select all

sudo PRUNE_MODULES=1 SKIP_KERNEL=0 rpi-update 6d8401e317b2d6bff8db15811edc4465d763ba3f
uname -a
Linux RaspberryPi3B 4.4.11-v7+ #891 SMP Tue May 31 12:30:26 BST 2016 armv7l GNU/Linux

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Sun Nov 06, 2016 1:52 pm

sail1943 wrote:I have this problem too when I try to set my raspberry 3b up as an ap, even with an offical power supply.
Simply using the Pi as an AP does not give me any trouble as long as I don't bridge ethernet and wifi. The problem only occurs when you do so but it's not a bridging problem in general, as it works fine when disabling the Pi3B's internal wifi and using an external adaptor...

User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Sun Nov 06, 2016 5:38 pm

Code: Select all

Linux tellypi 4.4.21-v7+ #911 SMP Thu Sep 15 14:22:38 BST 2016 armv7l GNU/Linux 
has been stable for me for

Code: Select all

 17:27:14 up 13 days, 21:15,  1 user,  load average: 0.46, 0.18, 0.06 
so far, bridged, although I haven't been using it much; it's mostly spent the last fortnight relaying temperature data from the greenhouse to the router. Your comment about it only occurring when using the internal interface is interesting: I'll experiment with ebtables and blocking of all non-IP / non-IPv6 frames out of the ethernet interface when I next have a problem.

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Mon Nov 07, 2016 12:47 pm

dickon wrote:so far, bridged, although I haven't been using it much; it's mostly spent the last fortnight relaying temperature data from the greenhouse to the router. Your comment about it only occurring when using the internal interface is interesting: I'll experiment with ebtables and blocking of all non-IP / non-IPv6 frames out of the ethernet interface when I next have a problem.
Nice uptime. But yeah, if you don't use it much, the odds are much better, I noticed.
Meanwhile, I've experimented with an old wifi USB dongle I had lying around and when using it instead of the internal wifi I get absolutely zero errors. Interesting approach with ebtables. Maybe it is just certain packets that the Broadcom firmware cannot handle, as suggested by the "non-BCDC packet" messages, however I'm not sure whether this is something that ebtables can actually catch or if it's some other lower layer 802.11-specific stuff?! Anyway, let me know if you find anything interesting. Would be nice to find at least a workaround...

User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Tue Nov 08, 2016 4:09 pm

Well, that uptime is now ruined...

Came in from a long weekend away, hit a key on the keyboard of my suspended desktop (I usually suspend it when I'm not using it, to save power), heard a loud bang, and the house went quiet. PSU seems to've taken out the fuse in the IEC cable (which I've never seen happen before), tripped two circuits on the consumer unit, and tripped the master breaker on same. I'm actually quite impressed; the machine seems OK (with a different PSU, obviously...).

Anyway, upon rebooting, the Pi3 immediately binned itself with the usual kevent 0 issue, and needed a reboot. I'm beginning to seriously believe that there's some packet in there it doesn't like that you don't get to see at the wired level usually. I'll experiment with ebtables once I've (physically) rebuilt my desktop.

fs007
Posts: 14
Joined: Mon Aug 18, 2014 6:34 am

Re: eth0: kevent 0 may have been dropped

Wed Nov 09, 2016 6:40 pm

I have this issue too. kevent 0
I'm using an industry grade 6 Amp power supply. This thing has nothing to do with the power supply.
kevent 0 happens when i activate wlan (which should be bridged). The wlan0 gets active and works by hostapd, but eth0 drops.

sail1943
Posts: 4
Joined: Fri Nov 04, 2016 3:35 am

Re: eth0: kevent 0 may have been dropped

Fri Nov 11, 2016 12:02 pm

fs007 wrote:I have this issue too. kevent 0
I'm using an industry grade 6 Amp power supply. This thing has nothing to do with the power supply.
kevent 0 happens when i activate wlan (which should be bridged). The wlan0 gets active and works by hostapd, but eth0 drops.
yeah, the wireless connection is ok, i can still ssh through wlan when the kevent 0 problem occurs, but the eth0 is break, and the value of TX packets errors keeps increasing.

User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Sun Nov 13, 2016 11:04 am

Unhappily, I can report that my initial attempts to fix the problem with ebtables has failed. I had hoped that by dropping all non-IPv4/IPv6/ARP frames at the bridge layer it would stop whatever is wedging the ethernet controller from getting through. Apparently not.

I've noticed that it's usually very unstable immediately after booting, but if it's been up an hour or so it's usually fine for a few days. Still no idea what is causing it, though.

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Tue Nov 15, 2016 11:29 am

dickon wrote:Unhappily, I can report that my initial attempts to fix the problem with ebtables has failed. I had hoped that by dropping all non-IPv4/IPv6/ARP frames at the bridge layer it would stop whatever is wedging the ethernet controller from getting through. Apparently not.

I've noticed that it's usually very unstable immediately after booting, but if it's been up an hour or so it's usually fine for a few days. Still no idea what is causing it, though.
Too bad. Would have been surprised if it had worked, though, to be honest. The problem seems to be low-level in the firmware / driver which is simply not sound. It's annoying that no fix has been made available thus far but lest we forget: the Pi was created as an affordable platform for children in order to learn about programming. Suppose that these kids are not bothered by this bug...

User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Tue Nov 15, 2016 11:41 am

That it doesn't occur under normal conditions, but only when in a bridge with the wireless device, suggested to me that there's some frame that's been tickling the hardware in such a way that it really doesn't like, and it only sees those frames when part of the bridge. By firewalling the non-IP / non-ARP frames at the bridge layer, such that they (in theory) should never get as far as the driver, let alone the hardware, it should be possible to avoid the problem.

But either I've got ebtables wrong, and I'm filtering the wrong things at the wrong time, or I'm simply flat-out wrong about the cause. Either (or both) is entirely possible.

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Tue Nov 15, 2016 11:55 am

dickon wrote:But either I've got ebtables wrong, and I'm filtering the wrong things at the wrong time, or I'm simply flat-out wrong about the cause. Either (or both) is entirely possible.
Well, how did you do it? Can you post the ebtables commands you used?

User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Tue Nov 15, 2016 12:07 pm

I have an initrd to setup the bridge before mounting / (over NFS). So in /etc/initramfs-tools/scripts/nfs-top/bridge I have (amongst other bits):

Code: Select all

ebtables -A FORWARD -p IPv6 -o eth0 -j ACCEPT
ebtables -A FORWARD -p IPv4 -o eth0 -j ACCEPT
ebtables -A FORWARD -p ARP -o eth0 -j ACCEPT
ebtables -A FORWARD -o eth0 -j DROP
ebtables -A OUTPUT -p IPv4 -o eth0 -j ACCEPT
ebtables -A OUTPUT -p IPv6 -o eth0 -j ACCEPT
ebtables -A OUTPUT -p ARP -o eth0 -j ACCEPT
ebtables -A OUTPUT -o eth0 -j DROP
(and there's an associated hook script to ensure all the correct binaries and modules are installed into the initrd; and I get it to drop to an interactive shell when debugging)
I've also experimented with blocking non-IP/ARP frames inbound to the bridge device from wlan0, but that didn't seem to help either.

I'm probably barking up the wrong tree.

User avatar
dickon
Posts: 1814
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: eth0: kevent 0 may have been dropped

Tue Nov 15, 2016 12:20 pm

The fully-comprehensive form, if you're interested, is:

Code: Select all

ebtables -A FORWARD -p IPv6 -i wlan0 -j ACCEPT
ebtables -A FORWARD -p IPv4 -i wlan0 -j ACCEPT
ebtables -A FORWARD -p ARP -i wlan0 -j ACCEPT
ebtables -A FORWARD -i wlan0 -j DROP
ebtables -A FORWARD -p IPv6 -i wlan0 -j ACCEPT
ebtables -A FORWARD -p IPv4 -o eth0 -j ACCEPT
ebtables -A FORWARD -p ARP -o eth0 -j ACCEPT
ebtables -A FORWARD -o eth0 -j DROP
ebtables -A OUTPUT -p IPv4 -o eth0 -j ACCEPT
ebtables -A OUTPUT -p IPv6 -o eth0 -j ACCEPT
ebtables -A OUTPUT -p ARP -o eth0 -j ACCEPT
ebtables -A OUTPUT -o eth0 -j DROP
ebtables -A INPUT -p IPv4 -i wlan0 -j ACCEPT
ebtables -A INPUT -p IPv6 -i wlan0 -j ACCEPT
ebtables -A INPUT -p ARP -i wlan0 -j ACCEPT
ebtables -A INPUT -i wlan0 -j DROP
ebtables -L
Blocks all non-IP/ARP frames in from wlan0, block all non-IP/ARP frames out to eth0.

The table ends up looking like:

Code: Select all

root@tellypi:~# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 4, policy: ACCEPT
-p IPv4 -i wlan0 -j ACCEPT 
-p IPv6 -i wlan0 -j ACCEPT 
-p ARP -i wlan0 -j ACCEPT 
-i wlan0 -j DROP 

Bridge chain: FORWARD, entries: 8, policy: ACCEPT
-p IPv6 -i wlan0 -j ACCEPT 
-p IPv4 -i wlan0 -j ACCEPT 
-p ARP -i wlan0 -j ACCEPT 
-i wlan0 -j DROP 
-p IPv6 -i wlan0 -j ACCEPT 
-p IPv4 -o eth0 -j ACCEPT 
-p ARP -o eth0 -j ACCEPT 
-o eth0 -j DROP 

Bridge chain: OUTPUT, entries: 4, policy: ACCEPT
-p IPv4 -o eth0 -j ACCEPT 
-p IPv6 -o eth0 -j ACCEPT 
-p ARP -o eth0 -j ACCEPT 
-o eth0 -j DROP 
root@tellypi:~# 

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Tue Nov 15, 2016 1:09 pm

Err, there is no DROP argument? Also, not sure whether specifying eth0 as interface is a good idea since everything should be handled by the bridge interface br0 of which it is a part and omitting this will let ebtables sort out the actual physical interfaces. I am definitely no expert but from my playing around with ebtables, in order to block all non-IP and ARP traffic, this should work:

Code: Select all

ebtables -P FORWARD DROP
ebtables -A FORWARD -p IPv4 -j ACCEPT
ebtables -A FORWARD -p IPv6 -j ACCEPT
ebtables -A FORWARD -p ARP -j ACCEPT
ebtables -A FORWARD -p 0x888e -j ACCEPT
ebtables -A FORWARD --log-level info --log-ip --log-arp --log-prefix EBTABLES
ebtables -P INPUT DROP
ebtables -A INPUT -p IPv4 -j ACCEPT
ebtables -A INPUT -p IPv6 -j ACCEPT
ebtables -A INPUT -p ARP -j ACCEPT
ebtables -A INPUT -p 0x888e -j ACCEPT
ebtables -A INPUT --log-level info --log-ip --log-arp --log-prefix EBTABLES
ebtables -P OUTPUT DROP
ebtables -A OUTPUT -p IPv4 -j ACCEPT
ebtables -A OUTPUT -p IPv6 -j ACCEPT
ebtables -A OUTPUT -p ARP -j ACCEPT
ebtables -A OUTPUT -p 0x888e -j ACCEPT
ebtables -A OUTPUT --log-level info --log-ip --log-arp --log-prefix EBTABLES -j DROP
I had to add the 0x888e protocol which is EAP (Extensible Authentication Protocol) required for WLAN. Without this, the wifi is useless as no clients can log on.
EDIT: Sorry there was just no DROP in your first post. (or I am blind)

pi-per-view
Posts: 22
Joined: Wed Oct 12, 2016 11:38 am

Re: eth0: kevent 0 may have been dropped

Tue Nov 15, 2016 1:27 pm

Now this is interesting: I've been running the ebtables script with my external wifi dongle and now with the internal wifi and noticed something very strange. As we know, 'b8:27:eb' is the MAC vendor prefix for the Raspberry Pi Foundation, however I keep getting log entries from source address ba:27:eb:xx:yy:zz to destination b8:27:eb:xx:yy:zz with the latter being the actual MAC address of the Pi's internal wlan0. The addresses are identical except for the first segment (ba instead of b8). Protocol is 0x886c which is 'Epigram' and apparently some Broadcom specific stuff. Could this be the bug? Can you confirm this behaviour on your Pi?

Return to “Troubleshooting”