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> *On Behalf Of *Nate Burke
*Sent:* Saturday, March 19, 2022 7:38 AM
*To:* AnimalFarm Microwave Users Group <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
