Forums › Forums › dLive Forums › dLive troubleshooting › dLive 1.80 with DHCP issues
This topic contains 12 replies, has 4 voices, and was last updated by 
-
AuthorPosts
-
2019/04/26 at 1:29 am #83536
Noted an interesting issue today with our church C3500/CDM64. Upgrade to 1.80 last Sunday. No issues. Had a user attempt to use the system today and console would not find the MixRack. I tried all sorts of reboots and checks, including finding the IP addrest of the MixRack and connecting with an iPad, so I knew it was there.
Got to wondering if firmware was the issue, so I reflashed the console and the rack and lo and behold it connected. I had to flash the rack from the webpage. I shutdown and restarted the whole system and it wouldn’t talk again. Reflashed the rack and it worked again.
So I got to wondering maybe it was actually network. System was set to DHCP, so main router was handing out IPs. I changed the console and the rack to static IPS and the problem went away. Tried two restarts, both succeeded.
Anyone experienced anything similiar with DHCP and/or network discovery in 1.80? 1.71 was fine with it. I am totally cool with static IPs anyway, but just a quirk I wanted to note here.
Thoughts?
2019/04/26 at 8:53 am #83541there is a confirmed bug in 1.80 regarding the network, normally a restart of the Mixrack solves the problem
since the connections is established there are no issues reported so far
2019/04/26 at 12:45 pm #83548A restart would not do it for me. Literally only reflashing + reboot would work… and then only once. MixRack was up, but console would never see it again, unless static IP. Looks like a discovery issue of some sort.
iPad would see MixRack.
Just an interesting behavior. I am a programmer by trade and I wrote a custom DHCP server once for an application, so it intrigues me.
2019/04/27 at 3:06 pm #83566network settings please….
2019/04/27 at 6:38 pm #83567There is a big disadvantage in the user interface of the dLive regarding network problems. The displayed messages do not point you into the direction of your root cause. I am never using DHCP for devices like servers, printers,mixing consoles, control surfaces etc. so normally I know what IP addresses are used (I do not run hundredth of network devices at home;-) so it is not that problem to keep things in mind). But when I accidently used the same IP address for two devices (a C2500 and an IP8) I always had problems with lost connections of the C2500 and the IP8 was not found by the dLive system. If there would be message like on a Windows PC that clearly says „ duplicate IP address found“ everything would be clear. But „connection lost, try to reconnect“ is somehow poor imho.
So, long story told. Try to check for devices with the same IP addresses.2019/04/28 at 1:27 am #8357210.0.0.25 – Console (static) – network port
10.0.0.26 – MixRack (static) – via GigaACE port, nothing hooked up to network ports on MixRack
10.0.0.1 – Gateway* DHCP picks up at 10.0.0.50
Additionally a ME-U, hooked up from MixRack.
To be clear, it is working when statically configured. Just noting that it would not auto-discover when using DHCP-assigned IPs, except for one time after a flash and reboot of the MixRack.
2019/04/28 at 9:22 am #83575so what is the exact configuration of your DHCP?
wich subnet mask?2019/04/28 at 2:36 pm #83579255.255.255.0
Nothing special.
2019/04/28 at 3:58 pm #83581Wich adresses get the mixrack and the surface after enabling dhcp?
Are you shure that both get an adress in the correct range?did you enabled dhcp in both configurations and rebooted all components?
2019/04/28 at 6:03 pm #83582Yes, AH have confirmed discovery issue w/ DHCP. We had an IP8 that was having issues w/ DHCP, so switched to static, which immediately resolved the issue. I won’t rehash here, but see my other post regarding that if you’re curious about the circumstances.
I have to say though: setting Mixrack/Surface connections to anything *but* static seems like a really good way to have a bad day that *one* time your DHCP server bugs out before a show.
In my own *personal* experience, I’ve always, always used static IP’s for those critical components that must just work every time. About 7 months ago, our IT guy begged me to change our Mixrack/Surface to DHCP at our second campus. I reluctantly agreed, and guess who got a service call the third week that unit was on DHCP? We lost a good 20 minutes reconfiguring/rebooting everything during an already tight setup time. I… just wouldn’t risk DHCP for any reason again. (In my best Mr. Horse voice:) Nosir, I don’t like it.
2019/04/28 at 6:33 pm #83584Steffen R – Both addresses were something above 10.0.0.50. I cannot remember what the addresses were, but both were completely correct and an iPad on wireless on the same network could see the MixRack, so the point was and is that auto-discovery is broken in 1.80 with DHCP. Everything else was 100% correct because NOTHING else had changed from 1.71, when I flashed to 1.80, and yes, I did reboot everything at least once.
Since switching to static IPs, everything is more stable, which, as ThatComplicatedMidiGuy pointed out, is more stable anyway (and I agree). I didn’t really think it mattered at the time, but it does at least with this release, so no more DHCP for the board/rack, period.
Besides the other guy losing some practice time for an event, I had enough time to mess around and see the what was going on. System has been used since then, and has performed flawless on the static setup.
2019/04/28 at 6:51 pm #83585Steffen R – Both addresses were something above 10.0.0.50. I cannot remember what the addresses were, but both were completely correct and an iPad on wireless on the same network could see the MixRack, so the point was and is that auto-discovery is broken in 1.80 with DHCP. Everything else was 100% correct because NOTHING else had changed from 1.71, when I flashed to 1.80, and yes, I did reboot everything at least once.
another point is that there is no really autodiscovery involved… if it where, than the IP should not matter
the ip ranges of all components have to be in the same subnet, at least… that was what I tried to find out…the change from 1.71 to 1.80 is changing more tan you think… because it is resetting the whole configuration
to reassign your configuration it is needed that you apply a show recall (I think you did that)
but things not present in older shows are not recalled and maybe there is something that breaks things…to find out what happend we should collect as much information as possible
and I completly agree to setup static IP, always…
That is the only way to keep everything under controlThis will only change if the system is migrating to IP6, but I guess the audio industry is not ready yet 😉
2019/04/28 at 7:08 pm #83588Steffen – Auto-discovery would be the console looking for the MixRack on the network, which I think it has to be doing in case the IP of the MixRack changes due to DHCP leasing a new IP address. Case in point: when the installer finished the power sequencing in the room, it was slightly off (and I have been meaning to get back to them about) and the console would routinely time out at least once looking for the MixRack. We’d simply reboot the console after waiting a little longer and it’d sync. I know things changed with 1.80 but since moving to static IPs, it boots much quicker this way. Consequently at one point Director wasn’t finding the rack on the network during the whole mess. Again, when it went static, Director finds it every time.
And no, I have not put Wireshark on the network to sniff the broadcast traffic, but just my hunch. I could definitely be wrong about all this, just basing this on the circumstances.
-
AuthorPosts
You must be logged in to reply to this topic.
