have you tried the input allow udp 69 rule?
On Thu, Mar 24, 2022 at 11:33 AM <li...@gogebicrange.net
<mailto: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
<mailto: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
<mailto: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
<mailto: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>
<mailto: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>
<mailto: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 <mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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>
<mailto: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>
<mailto: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
<mailto: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
<mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
Â
--
AF mailing list
AF@af.afmug.com
<mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
--
AF mailing list
AF@af.afmug.com
<mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
--
AF mailing list
AF@af.afmug.com
<mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
--
AF mailing list
AF@af.afmug.com
<mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
--
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
--
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
Â
--
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
Â
--
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
