I have (2) Bullet M2's flashed with version 3.15.1.0b2.
Using a Mac, one of the Bullets will never provide an IP to the laptop.
If I perform a 15 second reset on this node, it will assign a 192 address.
Once setting the call sign, and using the 10. addresses it will not issue IP address. Otherwise the node appears to operate file, I can even pass-thru internet with no issue.
Any suggestions ?
First thought would be are you checking "Disable DHCP" ? if so that would disable the DHCP server.
I don't have a MAC and haven't heard anyone report this yet but I have seen sometimes some systems based on *nix will keep requesting their old IP address (EG the 192 address) and fail to honor the DHCP server saying "That address is not available use this 10.x address instead" Usually this can be solved by forcing the system to purge its old lease which can often be done just by unplugging the Ethernet cable.
Failing that grabbing a support data file (from the admin page) and attaching it here may help.
I think this is allowed, at least for some reasonable number of retries.
DHCP is designed to allow more than one server on a single LAN, which is one reason the requests and responses are generally sent as unacknowledged broadcasts. When a host tries to reuse a previously granted lease, it broadcasts a DHCP-Request for that address. All DHCP servers hear this. Those not prepared to grant the request answer with a DHCP-NAK, but if one or more is prepared to grant the request it will answer with a DHCP-ACK and all is well.
You might think that the client should immediately give up when it gets a DHCP-NAK and fall back to broadcasting a DHCP-Discover to get a fresh IP address, but suppose there's a DHCP server that is prepared to grant the request but simply didn't hear it, or its DHCP-ACK was lost or delayed? Then the client would give up too soon. Multiple DHCP servers on the same network are not always configured to give the same answers; different ones might assign from different address blocks so it'd be perfectly normal to receive a DHCP-ACK from one and DHCP-NAKs from the others.
RFC 2131 designates a client must give up when it receives a NAK.
DHCPNAK has a specific meaning as defined in 3.1.2
"DHCPNAK - Server to client indicating client's notion of network
address is incorrect (e.g., client has moved to new
subnet) or client's lease as expired"
3.2.3 (Client-server interaction - reusing a previously allocated network address)
"If the client receives a DHCPNAK message, it cannot reuse its
remembered network address. It must instead request a new
address by restarting the configuration process, this time
using the (non-abbreviated) procedure described in section
Most systems don't have a problem with it and do adhere to it without issue, I've just seen a few here and there that do not.
Yes, but this doesn't address the case of there being several DHCP servers on a network (which is permitted) with one issuing a DHCP-NAK just before another issues a DHCP-ACK to the same DHCP-REQUEST. It seems reasonable to wait a short time for all the servers to respond before dropping back to DHCP-DISCOVER.
This topic is getting very off topic. However I'll end with a suggestion you re-read RFC 2131. The DHCPNAK (no hyphen) is not negotiable, the client is mandated to restart the process using procedure outlined in 3.1 without exception if it receives the DHCPNAK.
In addition your "multiple server" example is not valid per 3.2.2:
3.2.2
" If the client's request is invalid (e.g., the client has moved
to a new subnet), servers SHOULD respond with a DHCPNAK message to
the client. Servers SHOULD NOT respond if their information is not
guaranteed to be accurate. For example, a server that identifies a
request for an expired binding that is owned by another server SHOULD
NOT respond with a DHCPNAK unless the servers are using an explicit
mechanism to maintain coherency among the servers."
It is also further confirmed under 4.3.2 INIT-REBOOT stage for DHCPREQUEST
The only area that I can see is maybe a little fuzzy is "should the server send the NAK in the first place" but this is why DHCP servers have a way to list a subnet but not issue leases (dnsmasq uses the ignore parameter to configure a subnet, ISC uses the "not authoritative" parameter etc so the server can know when a subnet could of possibly been issued by another DHCP and as such it will stay quiet and not issue a DHCPNAK)
If this needs to be discussed more I would suggest we start a new thread for it.
I am a Mac OS X user, and I dont' see this issue. I suspect it is an envrionmental issue. I think a wireshark trace or tcpdump would be the place to start troubleshooting.
Thanks all for the replies. I still have no idea what is going on with this node. The DHCP on the node is enabled.
The only reason I wonder about the DHCP operation in the node is, plugging another network device on a switch it is not assigning IP addresses.
The other Bullet Node, I can plug into the same computer and it pickups a IP address almost instantly. The 2nd bullet put on a switch with a Raspberry Pi or network camera, assigns those devices an address.
Attached is the support data from the node that will not issue the IP's.
Thank you for the support dump.
In the log files it says "Thu Oct 8 03:32:25 2015 user.notice dnsmasq: found already running DHCP-server on interface 'eth0' refusing to start,"
What this means is the node detected another DHCP server on the same network it was plugged into and therefor refused to issue IP addresses. This is by design to make sure the node doesn't mess up your existing local network.
This can happen under the following circumstances:
1) The node "LAN" port was plugged into another node that had DHCP enabled and was started, it would detect the other nodes DHCP server and refuse to start
2) VLAN Configuration is incorrect on a smart switch
3) The node was plugged into your local home network at the time it was started and detected your home router DHCP server.
This is easy to fix: All you need to do is remove the connection to a network with an existing DHCP server (make sure DHCP is disabled on other node, or that the node is booted disconnected from the network) and than remove and apply power to the node.
The simple text is to have the LAN cable pluged into the node 100% disconnected and wait untill it boots (and the STATUS 1 LED [Green] ) is on solid and than. plug your laptop into it
Hope this helps!
Many thanks KG6JEI !
Sorry to waste anybody's time on this issue. I guess one of those hard lessons learned are the ones you won't forget.
I have the Netgear switch setup as instructions here on this site. And the correct port is the only port that passes internet, but is also fed from a router with DHCP enabled. The internet helped alot with speed testing thru the mesh finding the sweet distance / power settings.
The issue came from power cycling the Node while it was connected to the Switch and disabling the DHCP in the Node. Then when trying to connect directly to the ethernet port of several computers, nothing changes as the DHCP was disabled upon bootup.... DUH - why didn't I think of that LOL
Leaving the ethernet cable off of the node and powering up, and then returning to the smart switch, everything came up fine.
Any recommendations / changes to the Netgear switch that could have prevented this besides not using a Wan Port would be great.
All of this is still quite new to me.
73 N4LDR
Woohoo! Glad you got it sorted! congrats.
You may want to look at Software > Network Switch Configs as it contains some pre-made config files that may help you setup your vlans as it sounds like you may have not mapped the vlans to fully isolate the node.