Go to LUCI, select Status > FIrewall and look for the rule regarding invalid packets, copy and paste that line here.
Also look for your igmp rule and copy and paste that line here.
the first two numbers on the line are of interest: number of packets that hit the rule, and the total number of bytes. That will tell you if the rules are actively doing things.
I will do that. But I must go there, maybe tomorrow. I don't have access remotely.
TIA
I don't see the igmp rule, but the invalid rule only blocked 2MB of packets compared to 200GB of real traffic. I don't think that's likely to be it. Unless there are special invalid packets that this kernel crashes on, but I don't think so.
You are right. Look at this:
0 0.00 B DROP 2 * * 0.0.0.0/0 0.0.0.0/0 /* !fw3: DIS-Allow-IGMP */
Now I'm very very lost...
Like I said, I think you are seeing a problem ORIGINATING on the LAN. It probably is caused by someone trying to use some program that generates traffic that causes issues such as LAN games or torrents, or physically creating a loop with cables or whatever.
Here are things I'd suggest you look at next:
Can you set the APs to only use basic rates at 16Mbps or greater? if they're enterprise type APs you can probably do this. If it causes too much trouble for people disconnecting, try adding 8Mbps to the set of rates. You want to make sure the APs aren't forced to use slow rates and take up airtime.
Assuming your main switch is a managed switch, enable storm control for broadcast and unicast packets exceeding say 2000 packets per second (or if in Kbps say 4000 Kbps, something less than half of the minimum AP rate, so you can never saturate the wifi airtime with multicast/broadcast packets)
Turn on IGMP snooping and IGMP querying in your managed switch, so that whatever multicast you get originating on your LAN doesn't get broadcast all over the place but only to the ports that are actually participating.
Consider placing bandwidth limits on some switch ports, for example ports with printers on them could have INGRESS (printer into the switch) rates limited to say 1Mbps, this prevents a hijacked or malfunctioning printer from spamming your network. But as long as egress is normal (egress = from the switch to the printer), it won't slow down sending print jobs to the printer. Think about other devices that might benefit from similar treatment: ip phones shouldn't be using more than a megabit (or even say 300Kbps) either direction, ip cameras shouldn't be using more than N megabits where N is something depending on the camera's abilities... think about what else you have on your network that should be using minimal bandwidth and place some kind of ceiling on those items. Remember some ports might have multiple devices (like 4 ip phones chaining off each other) so calculate bandwidth limits appropriately.
If you have mostly unmanaged switches, and need more switch management capabilities, i suggest getting Zyxel GS1900-24E switches for $100 each on Amazon. Boot them up on your desk, plug a laptop in, update the firmware, set up the switch, save the config, backup the config, and drop them in place of your existing dumb switches. They're a FANTASTIC deal in terms of dollar per port, and they have all those above abilities, and more. Probably 1 to 3 of them should handle an entire deployment for your school. Worth it to reduce headaches over the long term
Enable Spanning Tree Protocol on your smart switches, so people can't just plug in extra cables between multiple ports and create loops that crash your network.
EDIT:
Also consider adding some firewall rules in the LEDE router to DSCP mark your packets. Specifically, one rule should probably zero out the DSCP entirely, then several additional rules should do things like mark UDP packets for VOIP phones as CS6 (or EF), mark packets on connections that have transferred a large amount of data (say more than 25MBytes) as CS1 (usually used for bulk transfers), mark packets for important functions on your LAN as say CS5... etc. Have the switches remark DSCP on ports dedicated to ip phones.
Then enable QoS in your switches based on DSCP, and/or CoS. This will prioritize your phone traffic and down-prioritize people's bulk downloads, further improving your network performance for time-sensitive things like voice.
Consider blocking outbound connections to port 80 / 443 (HTTP and HTTPS), and running a squid proxy, use the squid proxy to limit the use of the web, and/or tag certain websites DSCP values low priority. You can limit bandwidth usage or prioritize traffic based on website/URL rather than IP using this technique. For example, if the school uses online services, you can prioritize those by setting DSCP values and then the switches will make sure they "go first"
