Is the customer complaining about problems, or just that you saw it and
are trying to avoid issues? Dish makes an Ethernet to MoCA Adapter, so
they should be able to put that in at the router, and get rid of the
Wifi to the units entirely. I'm wondering if it's something with the
Wifi Connection.
On 10/13/2018 1:21 PM, Ken Hohhof wrote:
I noticed that a customer with DISH and a leased Mikrotik router from
us had some strange DHCP stuff going on. There is a lease for
Hopper2-WiFi near the top of the pool as is normal given the way
Mikrotik hands out addresses. Then there are 3 different Joey-MoCA
leases in sequence near the bottom of the pool but otherwise acting
normally. The weird one is Hopper2-br which started out near the
bottom with the Joeys but every minute or two sends a DHCP release and
then immediately a discover requesting the same IP address.
Apparently it’s too soon and the Mikrotik offers the next higher IP
address. But in another minute or two there is another release and
request, and the IP address increments again. I have the lease time
set to 1 day, so at this rate, it is going to consume the entire
address pool within a few hours.
I set the DHCP lease to static and gave it 192.168.88.9 so it is
outside the .10-.254 pool just to be safe. The hopper is still doing
the release/request every 1-2 minutes, but at least now it gets the
same address again.
Anybody else seen this? Is this normal Hopper behavior? Is something
configured wrong on the router, or on the DISH receiver? Maybe it
doesn’t like the 1 day lease time and wants something shorter?
I don’t see any wired interfaces active on the Mikrotik except the WAN
port, so I assume the Hopper is connecting via WiFi and then bridging
the connecting via MoCA to the Joeys. And that Hopper2-WiFi is the
WiFi connection, and Hopper2-br is the bridge to the Joeys. Not sure
why the Hopper needs 2 IP addresses, but apparently that is normal.
The aggressive DHCP lease behavior doesn’t seem right though.
I set DHCP logging to memory, I can include logfile entries if that
helps, but the tl;dr is a release request followed by a discover
requesting the same IP again, so quick the timestamp hh:mm:ss is the
same. Then in 1-2 minutes the cycle repeats.
I don’t know exactly why the Mikrotik was offering the next IP up from
the one requested, I assume because it had just been released
milliseconds before. I don’t know if this could be criticized as a
bug or not. It seems like the Hopper doing a release/renew at 1-2
minute intervals is the real problem. If it helps, the Mikrotik is
running 6.40.8 FW.
(I see that 6.42.9 is out now as “long term” which I assume is the new
name for “bugfix only”, and that 6.43.2 is out as “stable” which is
assume is the new name for “current”. The changelog for 6.43 has a
ton of stuff, but I have always been conservative and only used
“bugfix only” releases. Either 6.40.8 or 6.43.x should have the patch
for the dreaded winbox vulnerability, and that’s my main concern. With
the number of changes made in 6.43, hopefully there will be a newer
“long term” release soon.)
--
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
