Securifi Community Forum
Securifi Products => Almond+ => Topic started by: Fire69 on October 05, 2014, 03:25:16 pm
-
So... I've been cursing at the A+ for 2 days now because of the dhcp-bug. >:(
I want to use 192.168.1.x-range because that is how my network was configured up until now.
I didn't know about the bug before getting the A+ so I configured DHCP and everything just stopped working...
Now I have set the IP to 192.168.1.1 and didn't touch the start-end range and it's working.
But I had a lot of static addresses starting from .2 to .25 which I can't use anymore now.
Can I keep the dhcp-leases at the 100-150 range and define the static leases at 2-25?
Or do the static leases have to be in the 100-150 range?
Thanks
-
So... I've been cursing at the A+ for 2 days now because of the dhcp-bug. >:(
I want to use 192.168.1.x-range because that is how my network was configured up until now.
I didn't know about the bug before getting the A+ so I configured DHCP and everything just stopped working...
Now I have set the IP to 192.168.1.1 and didn't touch the start-end range and it's working.
But I had a lot of static addresses starting from .2 to .25 which I can't use anymore now.
Can I keep the dhcp-leases at the 100-150 range and define the static leases at 2-25?
Or do the static leases have to be in the 100-150 range?
Thanks
I'm on R065, but yes, I have static leases outside my dhcp range.
-
It's not a bug, it's simply poor wording and we've corrected it in R066.
It should be start and end address, not lease count.
-
Not a bug? So why does it stop giving out addresses then when I change anything?
When I set the ip to 192.168.1.1, start at 2, end at 150 everything stops working.
I read several posts from users who had the same problem.
I only changed the ip now and didn't touch the range, and it appeared to work. But I'll have to wait until the 12h run out to see if it's renewing correctly.
All in all, I'm finding the sofware unstable as bunny... :-\
1 example:
I'm at work now, I log in at connect.securifi.com.
Everything appears to be working, but my laptop is still shown as connected at home.
I do a refresh, thinking maybe it's not up to date
Result: 'Could not retrieve router data'
Great... >:(
-
Uhm, ok, this might be different, what people tried to do before was to put in 100 and then something like 50 for 50 leases due to the text description being wrong. It's supposed to be start and end address and that works just fine in R065. So that's not the same issue you're having.
As to why you're having an issue, I'm not sure. I know we've had some issues if you change the IP range, but I'm not sure if this was addressed in R066 or not.
We never said that we don't have work to do on the software side and yes, it's really frustrating. We're working on solving the issues everyone's having though, it's just taking a bit of time to try and figure what's going on in many of the cases.
-
I'm on R066, so the translation is OK, no problem there.
I don't know what's going on actually, I'm at work and I can't reach anything at home anymore...
Website and app both show the sensors as they should, they update when motion is detected or doors are opened.
But when I go to the router-tab, it says 'fetching router info' and nothig happens.
I understand that there is still (lots) of work on the software, but basic stuff should be working out of the box.
Do you know why the default ip has been changed to 10.x?
-
Hmmm, not sure what's going on with the cloud side of things. that's really odd.
What do you mean by the default IP address has changed to 10.x?
The Almond has always shipped with its default IP being 10.10.10.254 and so will all of our future products, including the Almond+.
Yes, the beta/dev units used 192.168.1.1, but that's not how we'd sell any of our products, so it's not as if the "default" IP was changed, it is what it's supposed to be.
The fact that there are issues changing it something else is another matter and if that's still not working properly, then it's something that needs to be addressed.
-
Hmm, you want to tell the DHCP server to assign IP's outside the range that you define?
That does not make sense...
Either you want the DHCP server to assign an address or not.
You can combine static IP addresses with DHCP. For example if you want your static addresses in the range of 2-25 then you would tell it to assign for example 26-150 and then you configure each client to wahtever IP you want it to have. You don't need to tell the router about the static addresses, as long as your IP's are in the routers subnet, it will route the traffic correctly.
But if you want static leases(DHCP reservations), so in the sense that you have the DHCP server on the router always assign the same address to a certain client, then it should be included in the range that you configure on the DHCP server so in the above example you would tell it to assign in the range of 2-150, and you should add the clients to the list of static leases that should always get the same address.
-
I have actually configured it very similar to what you want.
My previous network was also in the 192.168.1.0/24 subnet, so I wanted to keep this, I also had a few computers that I always wanted to get the same IP due to port mapping, so I reconfigured the DHCP server as I described. with starting at 2 and ending at 150, and then I added 4 devices that always get the same IP.
I had this setup running for about a week now with a lease time of 12 hours, and it works great.
-
Hmmm, not sure what's going on with the cloud side of things. that's really odd.
What do you mean by the default IP address has changed to 10.x?
The Almond has always shipped with its default IP being 10.10.10.254 and so will all of our future products, including the Almond+.
Yes, the beta/dev units used 192.168.1.1, but that's not how we'd sell any of our products, so it's not as if the "default" IP was changed, it is what it's supposed to be.
The fact that there are issues changing it something else is another matter and if that's still not working properly, then it's something that needs to be addressed.
It's probably not the cloud side of things. My wife just called me from home to say that the internet wasn't working. I made her switch over to the 'backup' wifi from my isp-router.
Weird that the sensor-data is still working though...
Ok, so you always use 10.x for your products? I wonder why your beta-testers get a device configured with 192.x then :D
Hmm, you want to tell the DHCP server to assign IP's outside the range that you define?
That does not make sense...
[...]
That's why I came here to ask if I had to include them in the range or not. ;)
I've had routers before where you had to separare the dhcp-leases from the dhcp-reservations.
Not with the A+ apparently. :)
Although it does work, because my range is set to the default 100-150, and I set a static lease for my server at 192.168.1.20 and it did get that IP.
Portforwarding worked, I could reach it through my domain-name.
However, this morning, nothing worked anymore...
I have actually configured it very similar to what you want.
My previous network was also in the 192.168.1.0/24 subnet, so I wanted to keep this, I also had a few computers that I always wanted to get the same IP due to port mapping, so I reconfigured the DHCP server as I described. with starting at 2 and ending at 150, and then I added 4 devices that always get the same IP.
I had this setup running for about a week now with a lease time of 12 hours, and it works great.
Thanks for the info!
That's how I've been trying to set it up from the start, but it just stops working after a couple of hours.
I'll give it another try this evening... :-\
-
I wonder why your beta-testers get a device configured with 192.x then :D
Well I think what he meant was that earlier firmwares, (those that were included with the Dev and Beta units) had 192.168.1.0/24 as default. But in later firmwares this was changed to 10.10.10.0/24
stops working after a couple of hours.
Well if it happens exactly 12 hours (or whatever lease time you have) after the device get the IP, then it might be DHCP, but if it happens as you say after a couple of hours, it might be something completely different.
-
It's probably not the cloud side of things. My wife just called me from home to say that the internet wasn't working. I made her switch over to the 'backup' wifi from my isp-router.
Weird that the sensor-data is still working though...
Ok, so you always use 10.x for your products? I wonder why your beta-testers get a device configured with 192.x then :D
That's really odd, I wonder what's going on there.
As for the IP address, it was the default of the SDK we got, we simply changed it to our default range some time back.
-
I asked my wife to reboot the A+ a couple of hours ago.
After that, I could reach it again through the app and website.
Last reboot: 2h48min ago
Devices & User: 0 connected
So again, no ip's are being distributed anymore.
Maybe it stops working because my dhcp reservations are outside the dhcp range?
For troubleshouting, I'll do these steps
- Do a full reset (again) tonight and leave everything as default (10.x)
- If it keeps working like that, I'll change the IP to 192. without touching anything else.
- If that's OK, I'll set the dhcp-range from 2 to 150
- After that, I can put in the reservations
Seems OK for troubeshooting, right?
If I still have problems then, you can send me a new one ;)
-
But if you want static leases(DHCP reservations), so in the sense that you have the DHCP server on the router always assign the same address to a certain client, then it should be included in the range that you configure on the DHCP server so in the above example you would tell it to assign in the range of 2-150, and you should add the clients to the list of static leases that should always get the same address.
Does it really not make sense to want dynamic addresses clearly separated from static ones? BTW, it's possible in dd-wrt and generic dhcpd.conf.
I expected to be asked for the dynamic addresses range. Let the computer compute the aggregate range if it needs to.
-
Does it really not make sense to want dynamic addresses clearly separated from static ones? BTW, it's possible in dd-wrt and generic dhcpd.conf.
I expected to be asked for the dynamic addresses range. Let the computer compute the aggregate range if it needs to.
Static lease is not the same as Static address.
A static address is one you set on the client and has nothing to do with DHCP, when you use a static address you tell the client NOT to use DHCP.
A static lease is one you set on the DHCP server, and you leave the client on DHCP so that the server can assign it.
In Almond+ you tell what range you want to DHCP server to give out, so if you want to use Static Leases, they need to be included in that range. But you should not include your static addresses.
-
Static lease is not the same as Static address.
So I should've said 'static leases'. The question remains.
In Almond+ you tell what range you want to DHCP server to give out, so if you want to use Static Leases, they need to be included in that range.
The notion of range is only applicable to dynamic addresses leases so putting static leases there is forced and counterintuitive. I get that the Almond's dhcp server configuration syntax may be limited but "it is what it is" is no justification in itself.
-
So I should've said 'static leases'. The question remains.
The notion of range is applicable only to dynamic addresses so putting static leases there is forced and counterintuitive. I get that the Almond's dhcp server configuration syntax may be limited but this is no justification in itself.
Not really.
In a static lease setup with DHCP you still get other information such as Network Mask, gateway, dns servers, boottp, etc. sent to the client, something you do not get in a Static address setup where you would have to set all those things manually on the client. And in some cases this is not even possible or very difficult, for example when you have a computer that boots over the network.
So in most cases you want to make sure that a certain device always get the same IP even if they been gone from the network a longer time, but do not want or can't even set them on the client manually.
In this case you use DHCP leases.
-
ok, just to give you an example.
I have an SIP phone, I also have a Wireless printer/scanner.
Both of these have a Web interface, so I need to know that they are always on the same IP.
However it is difficult to configure them to use a static IP with all the settings that come with it, so in this case I use a static lease.
I also have a Linux server that I can connect to in various ways, and although it is easy to configure the IP settings on it, why would I when I have a DHCP server on the network that can provide all the settings?
-
Here are some examples of the advantages of using static DHCP reservation - http://lifehacker.com/5822605/how-to-set-up-dhcp-reservations-so-you-never-have-to-check-an-ip-address-again
The reason why they're inside the DHCP range is simple, as eldaria explained, there are devices that are auto configured when added to a network, like printers, media streamers, IP cameras, light bulbs, tablets, phones etc. and many of these don't have an option to set a static IP address. Being able to lock them to that specific IP address is really handy and you can technically force them to use a different IP address from the router this way, something you couldn't do any other way on a device that doesn't allow you to set the IP address manually. It's also easier to manage the connected devices on the network and you'll never have an IP address conflicts this way. Someone might not know the DHCP lease range when they set a static IP address on a device and it can cause IP conflicts on the network.
Static DHCP reservations is the recommended way of giving a device a static IP address these days and there really are no advantages of setting a static IP address on the device side.
-
Thanks for explaining why it's useful to have static DHCP leases/reservations/whatever. I agree and I do use them.
And that is why I stumbled upon an inconvenience of current way of configuring DHCP. I'm used to be able to put dynamic addresses in a range, say 192.168.0.100-199 and static leases in another one, say 192.168.1-9. I don't want dynamic addresses in the 1-99 range. That's what dd-wrt and isc-dhcpd allow me to do. The dynamic addresses pool is the only range I see myself care about. It's surprising to be asked for a range but not that one. It's bad UI when a perfectly valid configuration is rejected because static allocations don't fall inside the dynamic DHCP range -- they can actually be anywhere in the subnet.
-
Well, complain to OpenWRT, we're simply following the way they're doing it. Every router I've used over the past 13 years or so have had a different way of doing something or the other, it's usually quite easy to adapt, if one wants too.
That said, it doesn't mean we won't be improving on things, but the base platform has some limitations we can't get away from.
-
That's understandable. It's the "doesn't make sense" assertion from eldaria that seemed weird. And it's still bad UI (UX? something user-centric) in my opinion. openwrt might not care about that but Almond web UI is too nice to have such issues ;)
-
I was updating/adding my static leases just now, and to my surprise I got this message!!
Number of Static Lease Entries shall not exceed 20
Wut?? WTF??
I went to OpenWRT and could add extra leases without any problems, so why not in NutsOS?
-
I've notified the software team about this and reported it as a bug.
-
Thanks :)
Any indication about when an update is coming, a week, a month, this year? :)
-
Weeks, we've decided to split the next release as the new Wi-Fi drivers caused some problems with the range extender mode and it's taking us longer to fix this than we'd hoped for, so the next firmware won't have the new Wi-Fi drivers, but it'll fix hopefully most of the other issues people are having, such as the garbled data over the WAN port etc.