Greetings all,
This is just a preliminary question - is anyone else suddenly having problems getting an ip from dhcp?
In Ottawa, we have the start of a network with about a dozen nodes, some on-site, some off-site. The network is almost all Ubiquiti hardware - all older XM, NanoStation M2's, NanoBridge M5's, Loco M2, Bullet M2. Since deploying beta 4, we have suddenly not been able to get an ip from dhcp. We were even locked out of the dhcp server for a while. We thought it was somethign we did. We rebooted everything at once and it seemed to start working, now we have problems again. Our dhcp server was the bullet M2 at first. We just switched over to the Loco M2 and still no go. We noticed that our ip cam did not get an ip. We also have an off-site link using non-bbhn-firmware NanoBeam M5's, They suddenly stopped working and do not seem to be getting an ip. Not sure yet what we are chasing.
Please do not misunderstand, this is just a question to see if the problem is unique to our system or anyone else has similar suspicions.
Thanks and 73
Rick (VE3CVG)
Hi Rick,
Would you please forward a support file dump to us from a couple of nodes exhibiting the problem? You can use my callsign at arrl dot net.
Thanks,
Andre, K6AH
Do you have DHCP servers disabled except one on the bullet node?
It almost sounds like you have another dhcp server on the network that is causing your node server to shutdown.
Yes,
We do have dhcp turned on in multiple wired nodes subtended by the same switch. I am trying to appreciate all of the implications of that. I thought that there was a hierarchy of responses to a request for an ip so that only one of several dhcp servers would respond but I am probably mistaken. We did have them all off, except one ..... but that got polluted along the way. Could that be our problem? Not getting any ip, seems to conflict with too many servers. OR does it ....
I just had a thought (probably not a good one) ... our original dhcp server was set for 13 nodes because we have 5 nodes + nanobeam link + camera + server + local test access computer all on the same switch. Could it be that the dhcp server job is being taken over by one of the other dhcp servers in the chain, and it is only set to 5? Oh oh. Gotta do some checking.
73.
Rick (VE3CVG)
Per my earlier request, if you would send the support dump we could confirm this. We are getting ready for a production release of this code and would like to confirm there is no new bug here. Please send to me at callsign at arrl dot net as soon as you can.
Thanks,
Andre, K6AH
Sorry Andre,
I meant to reply yesterday but was late heading off to a Christmas concert last night. I personally do not have easy access to the site and am not on the mesh yet. We're trying to extend it out this far. My co-conspirator, Ying (VA3YH) was working on this last evening and I see that he has the system back up but I am not sure of what has been done. I don't think that we can capture a meaningful diagnostic at this time. It's gone.
I am almost 100% sure that this was my fault and not a software bug. Not only that - I made the same mistake in my own home (test) network, earlier but corrected it without realizing what I had done. Very embarassed and sorry to bother everyone with this. As soon as we can, we will report back.
73. Rick (VE3CVG)
Rick, this does sound highly suspect. It is significant to design in which node is issuing the IP addresses:
1) all other nodes, if sharing and plugged into a dump switch, need to have DHCP on the LAN turned off.
2) Recommended option: implement with a VLAN 802.1q capable switch so that the device port is only assigned to a specific mesh node port. Label the switch accordingly. There's no unique settings on the mesh nodes (all have DHCP default on) to be re-purposed and not cause havoc later because we forgot DHCP was turned off.
There's no guarantee which mesh node will start assigning the IP addresses using a dumb switch and default settings on all the mesh nodes--which causes havoc with advertising services on the mesh.
Joe AE6XE
Joe,
It all makes sense now. Thankyou for your answer. We will turn off dhcp in all nodes except 1 per dumb switch and move to VLAN capable switches as soon as we can. I'm glad it's a hobby and not a business. :-) since I learn almost everything the hard way.
73. Rick (VE3CVG)
Rick, The only other reported and possibly related issue is symptoms I saw a week ago in setting up ipCams for an event. We had trouble with 3 ipCams and 2 NanoStation nodes--tried swamping out a cam on one of them. At one point I had an operational ipCam and NSM2, then half way through the event for other reasons, I had rebooted the NS and could not get back the ipCam with the reserved IP address. Power cycling the ipCam independently seemed to get it going--but unknown if repeatable. Unfortunately, I didn't have time to capture a lot of data in the middle of the event, so given your report, there is added weight to determine what's go on, if anything.
If anyone else has experienced this issue, please report. This is unusual for something like this to suddenly show up after all this beta time.
Joe AE6XE
Any luck reproducing in your lab Joe?
No, I have several other live nodes, some remote, and my own portable ipCam-NSM2. None have demonstrated these symptoms on any version of 3.15.1.0b*. The ipCams that demonstrated symptoms (different than mine) were from vendors "anran" and "sricam", however.