I'd agree with that. Are you able to provide the info from the low level shell?
On Mon, Apr 4, 2022 at 6:06 PM Nate Burke <n...@blastcomm.com> wrote: > I don't want to read into anything, but my Ticket at Cambium has been open > for a week an a half, and they have ask for no additional information, and > just keep updating me that's its being worked internally. That sounds like > they know the problem exists and haven't been able to track down the cause > yet. > On 3/24/2022 2:57 PM, Josh Luthman wrote: > > Did Cambium give you the back door key to troubleshoot these kinds of > issues? > > I worked with Dmitry to find an extremely weird bug on the 3000 light omni > - went as far as to solder an rs232 jack on it. > > On Thu, Mar 24, 2022 at 11:21 AM Nate Burke <n...@blastcomm.com> wrote: > >> Took 5 days for the issue to surface again. It seems that any change to >> the EPMP AP that causes a radio reset will clear the issue. But >> disassociating or rebooting the SM will not. The last time I changed the >> 'Reliable multicast' setting and it started working. This time I changed >> the frame size from 2.5ms to 5ms and it started working. But both of those >> changes caused the RF to reset, so I don't think that it's the setting so >> much as something in the AP network/rf stack getting reset. I'll open a >> ticket with Cambium, but as infrequent as it is, I'm not sure what they'll >> be able to find. >> >> On 3/22/2022 11:17 AM, Nate Burke wrote: >> >> It has not happened again since Saturday, but that's the only AP out of >> the hundred deployed that I set that 'reliable multicast' setting on. I >> think that it did cause an RF Drop when that setting was changed, so maybe >> just kicking the radio from the AP would be enough? Every other site with >> the issue had multiple sectors, so kicking the SM From one AP would have it >> attach to another AP at the site and it would start working. However >> rebooting the SM and it attaching back to the same AP does not fix it. >> Need to wait another couple days for it to happen again to do some more >> testing. >> >> On 3/22/2022 7:59 AM, dmmoff...@gmail.com wrote: >> >> Interesting. I think that initial offer is a broadcast packet…..maybe >> that “reliable multicast†setting affects broadcast as well? >> >>  >> >> *From:* AF <af-boun...@af.afmug.com> <af-boun...@af.afmug.com> *On >> Behalf Of *Nate Burke >> *Sent:* Saturday, March 19, 2022 7:38 AM >> *To:* AnimalFarm Microwave Users Group <af@af.afmug.com> >> <af@af.afmug.com> >> *Subject:* Re: [AFMUG] EPMP1000 and DHCP failures >> >>  >> >> I was able to get a packet capture while it while it was happening. >> Client had been running fine for about 3 days before it started erroring (3 >> hour DHCP Lease). Nothing was logged with the firewall rules on the >> Mikrotik doing the DHCP Server. >> >> I have a mikrotik between the 450SM an the EPMP AP, I was able to run a >> packet capture from there. I ran it on the interface of the EPMP radio. >> It was showing the DHCP Discover being sent to the Server, and the DHCP >> Offer being sent back to the client, but that was it, no DHCP Request >> Packet coming from the EPMP Interface. >> >> On the EPMP AP, I changed the 'Reliable Multicast' from Disabled to >> Enabled. And the client immediately got a DHCP lease after saving that >> (No AP Reboot). The DHCP Request Packet came back from the client as soon >> as the Discover/offer packets were sent. I'm not convinced that was the >> issue, as I don't have it enabled on ay other EPMP radio on the network. >> It seemed more like making a change in the AP reset something in the EPMP >> network stack. It's just strange that it happens so randomly. >> >> On 3/14/2022 7:24 PM, Steve Jones wrote: >> >> The mikrotik that handles the dhcp relay or dhcp, log any input firewall >> rules and see if its dropping the packets >> >>  >> >> On Mon, Mar 14, 2022, 7:03 PM Nate Burke <n...@blastcomm.com> wrote: >> >> Just had it happen on a newly installed EPMP1000<->EPMP1000 link. AP >> and SM are both 2.4 non-GPS radios. Feed to site is a 450B off a450M >> AP. Relay from barn to house using 2.4 EPMP 1000 radios. >> >> Was working fine when I left, 3 hours later, DHCP lease timed out >> (Mikrotik DHCP Lease time) and would not get new lease. Rebooting the >> 1000 Radio acting as the AP fixed it. If it happens again, I'll try to >> get a packetcapture off it. >> >> On 3/9/2022 10:14 AM, Steve Jones wrote: >> >> the mikrotik is dhcp relay, BMI is the dhcp server >> >>  >> >> On Wed, Mar 9, 2022 at 10:07 AM Josh Luthman <j...@imaginenetworksllc.com> >> wrote: >> >> Oh this is on the DHCP server, sorry. >> >>  >> >> On Wed, Mar 9, 2022 at 10:31 AM Steve Jones <thatoneguyst...@gmail.com> >> wrote: >> >> we have to have it for dhcp relay to keep functioning. otherwise it >> periodically stops working from EPMP APs, I never knew why, mikrotik had no >> answer, but it would suddenly get caught up in non ACL drops add >> action=accept chain=input comment="ALLOW DHCP UDP 67" dst-port=67 >> log-prefix=dhcp protocol=udp >> >>  >> >> On Wed, Mar 9, 2022 at 8:12 AM Josh Luthman <j...@imaginenetworksllc.com> >> wrote: >> >> The input chain is to the Mikrotik itself, ie the IP address that it >> would theoretically get from the DHCP server. I was thinking of a managed >> Mikrotik as a demarc to the customer's stuff (so forward chain). >> >>  >> >> On Tue, Mar 8, 2022 at 7:57 PM Steve Jones <thatoneguyst...@gmail.com> >> wrote: >> >> I had this issue a long time ago, id like to think that it was a firmware >> revision that resolved the issue, but it was a long time ago and im >> partially retarded. >> >> If you have a mikrotik, add an input rule allow udp 67. Just for kicks. >> It might be this issue that i have that policy for. >> >>  >> >> On Tue, Mar 8, 2022, 4:22 PM Josh Luthman <j...@imaginenetworksllc.com> >> wrote: >> >> Raise a ticket with Cambium and explain the situation? If you could get >> pcap that would show what's missing. Do you have a Tik behind any SM with >> the issue by chance? >> >>  >> >> On Tue, Mar 8, 2022 at 4:05 PM Nate Burke <n...@blastcomm.com> wrote: >> >> No DHCP Relay, just local DHCP Server on the mikrotik on the bridge that >> all the AP's are part of. >> >> No MAC limit on the SM's >> >> When it exhibits itself, a customer who has been running for weeks will >> timeout their lease, and the mikrotik will just go to 'offered' Rebooting >> the AP always fixes it. >> >> On 3/8/2022 1:18 PM, dmmoff...@gmail.com wrote: >> >> I was wondering about broadcast rate limit. That would apply to a DHCP >> discover, but not to a renewal. ….but either the MAC limit or broadcast >> limit would clear when rebooting the SM, and he says rebooting the SM has >> no effect. >> >>  >> >> Is DHCP running on the port that the AP is plugged into, or is there a >> DHCP relay involved? >> >>  >> >>  >> >> *From:* AF <af-boun...@af.afmug.com> <af-boun...@af.afmug.com> *On >> Behalf Of *Josh Luthman >> *Sent:* Tuesday, March 08, 2022 12:43 PM >> *To:* AnimalFarm Microwave Users Group <af@af.afmug.com> >> <af@af.afmug.com> >> *Subject:* Re: [AFMUG] EPMP1000 and DHCP failures >> >>  >> >> Do you have the SM limited on MACs? Look at Ethernet Port Security on >> config > network. >> >>  >> >> On Tue, Mar 8, 2022 at 12:32 PM Nate Burke <n...@blastcomm.com> wrote: >> >> I've experienced this issue randomly, and haven't been able to track >> down a cause. Wondering if anyone else has come across something >> similar. >> >> Mikrotik DHCP Server. EPMP1000 GPS AP, Force 300 SM. >> >> At a random time, one or More Force 300 SM's on the AP will lose the >> ability to hand out a DHCP Address to the client. The Mikrotik just >> shows 'Offered' >> >> Rebooting or powercycling the SM has no effect. If the SM Connects to a >> different sector, then DHCP is immediately handed out. If the AP >> reboots, and the SM reconnects, then DHCP is immediately handed out. If >> the SM is set for NAT mode, it can get a DHCP Address just fine, but >> switching back to bridge, the Customer router will not get DHCP. >> >> I've experienced this from 4.4.3 all the way up to 4.6.3. It always >> seems to be an EPMP1000 AP with a Foce300 SM, but does not affect every >> Force300 SM at the same time. >> >> At least now I know when I start having this problem to go reboot the AP. >> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> >> >>  >> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> >> >>  >> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> >> >>  >> >> >> >> >> >> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> > > -- > AF mailing list > AF@af.afmug.com > http://af.afmug.com/mailman/listinfo/af_af.afmug.com >
-- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com
