I love SonicPoints! They are one of my favorite local wireless solutions and I’ve found them to be pretty darned reliable over time. But like anything, issues can creep in causing problems with your setup. Having said that, here’s my picklist of typical fixes for Sonicpoint issues.
- PoE Issues: The older Sonicpoint devices are 802.3af/PoE/15.4w devices, whereas the newer Sonicpoint devices are 802.3at/PoE+/25.5w compliant. This is often overlooked and they’ll power up on a lower-powered port anyway, but often will reset frequently as the power draw approaches the switch maximum. Make sure you’re using the proper injector/switch for the device. Also – remember that longer runs means more voltage drop.
- Spanning Tree: When a switch port becomes active, the spanning tree protocol will discard traffic until it determines the STP state of the connected device. For some switches, this can mean a fifteen second delay (or more) between when the device sees the link active and when traffic actually passes over it. Sometimes, the SonicPoint doesn’t get a reply from the Sonicwall fast enough and fails. Put the port in portfast mode (or turn off spanning tree for that port).
- EEE/Energy Efficient Ethernet: I know this is an odd mention, but many switches have EEE turned on by default when shipped and it’s not something many people think about, but the switch will scale the transmit voltages to what it thinks is the minimum required to work. Sometimes, it guesses wrong and you end up losing carrier.
- L2/L3 Issues: The L2/L3 network available to the Sonicpoint at boot-time should be dedicated to SonicPoint management (i.e. there should be nothing else on the network). On my devices, I dedicate a physical port to the SonicPoint traffic (to avoid bandwidth competition with the LAN), carry the untagged traffic on that interface to the SonicPoints and VLAN off each SSID. That way, devices aren’t messing around with the SonicPoint management traffic on either an L2 or L3 level.
- WAN Management: Don’t forget your SonicPoint management network will need internet access – including functional DNS – to update their firmware.
- Firewall Rules: There are some hidden assumptions in the Sonicwall firmware, like preventing wireless devices from talking to one another. When in doubt, check the Packet Monitor to ensure traffic is not being blocked by a firewall rule.
- DHCP: Twice encountered, it’s best to let the Sonicwall do any DHCP relaying over your network switch(es). I’ve seen issues with traffic not generated by the Sonicwall not making it to the client (which is configurable in the Sonicwall but a caveat nevertheless).
- Don’t be afraid to factory default. I’ve had SonicPoints go awry and after numerous power-cycles, a factory default left it resolved.