I was doing some testing earlier, I had a static IP set because we were using our old router and it was still configured to 10.16.84.1 (which I reflashed using the bridge configuration utility)
I finished configuring it and went back to DHCP to view a ScreenSteps page. When I went back to the router, I didn’t switch to a static IP because it should be dhcp. It didn’t give me an ip address, I couldn’t talk to the router nor the mDNS roboRIO. If I switched back to 10.16.84.51, i could talk to both fine and operate the robot as intended.
The roboRIO networking page states “Driver Station PC: DHCP, assigned by the Robot Radio”
I’d check the web page for the DLink radio, check the web page for the roboRIO, and finally, check your PC’s settings for whatever interface you are using, wifi, or ethernet.
To answer the thread question, it is capable of using DHCP to get an IP, and that should be the default setting.
Try going into the Router Management console, log in. If you click the DHCP tab is it enabled and does it have the correct settings? (DHCP range 10.TE.AM.20 to 10.TE.AM.199 subnet 255.255.255.0)?
We ran into this very same problem today. Here are our current findings on the issue.
Once the bridge configuration utility is ran the roboRio has to be reset to release/renew IP. There might be another way to do this but the “turning it off and on again” strategy seemed like a good starting point.
The DLink will assign IPs to wired clients via DHCP but it will not assign IPs to wireless clients via DHCP.
Additionally the wireless NIC on the laptop never even received the standard 169.254.x.y IP address. It simply had no IP at all.
As a temporary fix we set a static IP on the laptop and planned on figuring it out later…later has yet to come.
The DLInk I’m using definitely allocates IPs when it is used as an AP. I did not use the config tool, but made minimal hand configurations. If you are using it as a bridge, the true AP will need to have DHCP enabled and may need to be configured as to the range of addresses it uses.
The 169.254.xx.yy IP number is self-assigned. I don’t believe that it involves the DHCP server. I’d suggest opening the control panel and repairing and/or enabling the wifi interface.
I have an old Rev A DLink that, while set for DHCP refuses to serve IP addresses up. Our other Rev B DLinks aren’t having that problem, so I think it’s something broken in the Rev A DLink we have. We have another Rev A that I’ll try just for comparison.
The DLink we are using is a rev B from a year or 2 ago. The switch is set to 2.4Ghz AP
Self-assigning is only used when a DHCP server doesn’t assign an IP. This has me thinking that the DHCP handshake starts but timeouts in a way such that the client doesn’t realize it is suppose to self-assign. We did try repairing the connection on the wireless nic of the laptop and that did not resolve the issue.
If time allows we will try to capture the DHCP request/response with Wireshark this evening.
We had a lot of issues with actually establishing comms as well. For example, we imaged the roboRIO, uploaded Java to it, then we used the Bridge Config tool, and got connected to the router via wifi. Upon plugging a lan cable into the router and roborio, everything seemed to go crazy. we couldn’t find anything: the router IP was nowhere to be found, and we could only access the roboRIO by going to roboRIO-2791.local in Chrome. Even on that roboRIO site, we could not access the networking options without getting an error about a corrupted installation. we reset everything 3 times before the meeting ended, and we had established comms a couple times. We power cycled the bot to make sure everything was working, and upon powering on, it stopped working and we had to start over.
IPv4 was on auto retrieve IP.
I found the router settings to be often, NOT ALL THE TIME, at 10.27.91.1. If I tried switching the router to DHCP, Chrome would crash and then we could no longer access 10.27.91.1.
cmd>ipconfig /all did not give any results, and neither did netstat or pathping. When we did get comms, I did a pathping, and it went from my computer directly to the roboRIO IP. (10.27.91.23 -> 10.27.91.21), but then both IPs yielded nothing after power cycle. The RIO is on DHCP, the router is not, and the computer is on auto-retrieve IP/DNS. i don’t know what is going on because i don’t know much about networking, but if anyone could lend some insight, that would be incredibly appreciated…
The basic procedure we’ve followed and have (so far) not had any problems with.
Start with a completely clean/reset router. (ie Do a reset using a paperclip into the button near the power connector), and plug in via Ethernet.
Set computer IP to 192.168.0.40*
Using a browser, log into DLink (192.168.0.50). Go to network settings and change IP to 10.TE.AM.1
Set computer DLink IP to 10.TE.AM.40*. After saving, the DLink will log you out.
Log back into DLink, go to advanced settings -> DHCP settings. Set the IP range to be 10.TE.AM.100 - 199*, netmask 255.255.255.0, default gateway 10.TE.AM.1
Last but not least, go back to wireless setup (ensure you go to manual, not automatic) and set the SSID to TEAM*, etc.
After you disconnect your computer, make sure you go change the Ethernet driver back to DHCP
Hopefully that will work for you.
all these need to be in a specific range to work, and can take on other values. I just picked a number that I know works.
As general info, a big thing to watch out for is a conflict between static and DHCP IP addresses. If, on one network, you have the DLink giving out ips in the range of 10.TE.AM.100-199, you CAN NOT set a static IP on your computer in that range (so 10.TE.AM.123 would be illegal) however, IPs out of that range (and on the same subnet) are allowed (for example, the cRIO at 10.TE.AM.2 would function fine with a DHCP server giving out 10.TE.AM.100-199)
Secondly, do all this with the roboRIO off. From the roboRIO manual:
The first time you power up the chassis, it attempts to initiate a DHCP network connection. If the chassis is unable to initiate a DHCP connection, it connects to the network with a link-local IP address with the form 169.254.x.x .
I’m not sure if the roboRIO keeps the IP, or for how many power cycles. Nonetheless I’ve made sure that I only power on a roboRIO with a network which has DHCP running, and haven’t had any problems (so far).