have you tried the input allow udp 69 rule? On Thu, Mar 24, 2022 at 11:33 AM <li...@gogebicrange.net> wrote:
> This one is really interesting to follow along with. Unfortunately, I am > willing to bet support will eventually issue and RMA on it and send you a > new unit with no real resolution. > > > > Brandon > > > > > > *From:* AF <af-boun...@af.afmug.com> *On Behalf Of *Nate Burke > *Sent:* Thursday, March 24, 2022 10:20 AM > *To:* AnimalFarm Microwave Users Group <af@af.afmug.com> > *Subject:* Re: [AFMUG] EPMP1000 and DHCP failures > > > > 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
