If you can figure out why it works, id love to know, assuming it solves your issue like it did for me. It made no sense to me, but it worked. Id prefer to know the root cause so I can have a correctly configured network rather than cobbled stuff
On Thu, Mar 24, 2022 at 12:15 PM Nate Burke <n...@blastcomm.com> wrote: > I just added it, but not sure why it would be a Mikrotik rule if the only > change I make is to the EPMP AP and it starts working. Unless the EPMP is > somehow modifying the packet in a way the mikrotik doesn't like? But why > does it decide to suddenly start modifying it. > > On 3/24/2022 11:59 AM, Steve Jones wrote: > > 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>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>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> >> <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> >> <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> >> 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>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>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> >> 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> >> 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> >> 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>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> >> <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> >> <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> >> 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>AF@af.afmug.com >> <http://af.afmug.com/mailman/listinfo/af_af.afmug.com> >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> >> >>  >> >> -- >> AF mailing list >> <AF@af.afmug.com>AF@af.afmug.com >> <http://af.afmug.com/mailman/listinfo/af_af.afmug.com> >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> -- >> AF mailing list >> <AF@af.afmug.com>AF@af.afmug.com >> <http://af.afmug.com/mailman/listinfo/af_af.afmug.com> >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> -- >> AF mailing list >> <AF@af.afmug.com>AF@af.afmug.com >> <http://af.afmug.com/mailman/listinfo/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
