DHCP Issues

Mark Erbaugh

This is with a 6300 and SSDR 1.3.8.  More often than not, the first time I power on mt Flex after it (and the DC power supply) have been off for a while (overnight), the radio fails to get an IP address and comes up with an address in the 169.x.x.x range.  I haven't found any way other than a power cycle to get it to eventually find an IP address. None of the other devices on my network have ever had a problem getting an IP address, including a computer connected to the same switch as the Flex (the computer I use with the Flex).

This afternoon, the radio came up with the invalid IP address. I pushed the power button, the green light flashed and the radio shut down properly. I powered it up again and again in invalid IP address.  This time when I pushed the power button, the the green light stayed solid and the radio took many seconds to shut down..

Lately, I have been working with the FlexLib API and have had cases where in the radio suddenly goes away. FlexLib fires a radio removed event.  If I shut down my program and fire up SSDR, it doesn't see any radios, but the radio does respond to a ping and it's IP address. I have to cycle the power to get it to come back and sometimes it comes back up with an invalid IP address. In the cases where I have to cycle the power, the green light usually stays solid green and the radio takes a long time to shut down (which is quite frustrating when I am in the middle of development).

I

Robert -- N5IKD

You should probably be using an IP in the range of 192.168.x.x.

Private addresses are typically in one of these ranges.
Class A: 10.0.0.0 - 10.255.255.255
Class B: 172.16.0.0 - 172.31.255.255
Class C: 192.168.0.0 - 192.168.255.255

George KF2T

Have you tried giving the Flex a DHCP assignment in your router? That usually fixes most issues. As long as the LAN is up when you power the rig.

Tim - W4TME

First off this is not related to DNS which is the facility that maps a fully qualified domain name to an IP host address.  I think you want to change the title to "DHCP issues".

Second, from where are you getting the error message that you have an invalid IP address and what if any additional information is being provided?

DrTeeth

The 169.x.x.x series is like an error code. It is what appears when a device is looking for a DHCP server but cannot find one.

Tim - W4TME

It isn't an error code, it is a link-local or APIPA IP address.  These IP addresses are fail-back IP addresses when the device cannot acquire one form a DHCP server.

DrTeeth

"These IP addresses are fail-back IP addresses when the device cannot acquire one form a DHCP server." You mean it is like an error code :-)))?

Lee - N2LEE

You might want to get a copy of Wireshark (https://www.wireshark.org/) so you can see what is really going on. This is the best way to determine if its the router or the 6300.

Tim - W4TME

Agreed.

Jay Nation

Hey Thanks!

I know I intended to get my 6500 off it's link-local IP back in august. But since nothing had forced me to act on the intention, I never got around to it. Now it's on 192.168.137.###, I can now resume forgetting about it again. Like I do everything else. I'm lazily procrastinating my way towards the perfection of avoidance, mostly by doing less, excessively. 

73, Jay - NO5J

NX6D Dave

I run a 6300 on a GB switch on which my computer is also connected. DHCP is provided by an old WRT-54G. I do as you do ... I switch off the radio power supply when I switch off the radio for any length of time. I've never seen the radio fail to get a good IP address for my LAN on restart , and I've never seen SSDR fail to connect.

I have seen, however, the long shutdown you describe. I see it about every third time I shutdown the radio. I **think** it is more likely to do this if I've shut down Windows first. This suggests to me that I'm waiting for a protocol timeout. I would like to know what this is and how it can be avoided.

I recently ran this radio off of a Surface tablet. I simply connected the radio directly to a Surface Ethernet dongle. No switch, no DHCP, no LAN. The radio used the link-local protocol and made a good connection every time.

Mark Erbaugh

A couple of comments on my setup. The router is an Apple Time Capsule. When the Flex gets a good IP address, it is always the same, 10.0.1.3. Unless there is a problem with my individual radio, it sounds like the DHCP negotiation might be timed differently with the Time Capsule. As I mentioned, none of my other device connected ever seem to have a problem with the DHCP. That being said, I've noticed that if Iunplug a device and reconnect it, I don't have to reboot it to get it to get an address, with the Flex, unplugging the network cable and reconnecting has never cured the bad IP address issue, so I assume that it only does DHCP negotiation at startup. I have downloaded Wireshark, but really don't know how to use it. If someone could tell me exactly what to look dor, I could capture network traffic during a Flex boot that fails to get DHCP.

Tim - W4TME

"I have seen, however, the long shutdown you describe. I see it about every third time I shutdown the radio. I **think** it is more likely to do this if I've shut down Windows first. This suggests to me that I'm waiting for a protocol timeout. I would like to know what this is and how it can be avoided."

This has been covered elsewhere on the Community in detail, but in summery the Linux OS in the radio has to shut down processes and do some file system housekeeping on shut down.  Sometimes it takes a little longer that others.  On other rare occasions, a process may hang too.  The long shutdown is nothing to worry about.  But, we have worked on reducing process hangs on shutdown for SmartSDR v1.4, so there should be come improvement in this area.

Dan -- KC4GO

I was running my system via DHCP from my local network  with all devices that can be are set with static IP addresses. My entire system is 1 Gigabit -- the local network connections was 6500 and operating PC on the same switch and both of those connected to the Router/Firewall/DHCP server. I went in to the Router and reserved the IP address was to be assigned to my 6500 this is done based on the MAC address. (first 6 digits D0:39:72) 


 Currently I run it via link-local the IP that the radio comes up on i s 196.254.7.19
The radio (a 6500) is directly connected to the PC via a USB 3 to 1 Gigabit Ethernet Dongle.  This seems to work much smother for me. 

I have not had issues with connecting but I do have a loss of link that almost always occurs during the change of profiles and mostly those that involve more than one pan-adapter/slice. 

As a useful tool from Wireshark will help ID the MAC addresses to vendor https://www.wireshark.org/tools/oui-lookup.html enter the MAC address in the box and press find.  In the case of D0:39:72 it will come back as: D0:39:72 Texas Instruments this is the hardware FRS uses for it's network device.

For those of us that are trying to keep up with Networking as well as Ham Radio you can go to YouTube and put this in the search box "network 101 cisco". For Wireshark put in "Wireshark 101" in the search box. 

Dan --- KC4GO

 

Tim - W4TME

Mark - in regards to the question:

"I have downloaded Wireshark, but really don't know how to use it. If someone could tell me exactly what to look for, I could capture network traffic during a Flex boot that fails to get DHCP."

It is easy.  Power off the radio.  Start Wireshark. Power on the radio and wait until it completely boots up and then stop the Wireshark trace and save it.

The open a HelpDesk ticket and I'll do the analysis.  You have to know how the protocol negotiates and sift through the hundreds of packets to quell out the sequence and determine the timing deltas.  I have been doing this for years so it is second nature now.

Robert -- N5IKD

Tim's idea to call the help desk is the best, but if you want to dig into it yourself, This Wireshark page details what you are looking for and what filters to set. You still need to know something about getting around Wireshark.

Also, If you have a router, is the DHCP server in the router disabled?

Mark Erbaugh

Thanks for the reply. I have collected the data and will open the help desk ticket. You are correct, I should have titled the thread DHCP not DNS. Also, when I referred to invalid IP address, I meant the 169.x.x.x ones.

Paolo Reda

Dear Tim,
me to with a brand new Flex 6500 have the same DHCP issues.
Net ready, MAC address reserved, 1Gb to the switch. Many time on startup and always on shutdown and restart the Flex do not get the NET IP, strange...
IZ2AMW Paolo

Mark Erbaugh

I've got some more info. Tim at Flex reviewed my Wireshark log and couldn't find any solution. In May, I replaced the 6300 with a 6700 and the problem of not getting as IP address continues. I would say that over half the time when I turn on the 6700, it fails to get an IP address. The only solution I have found is to power cycle the 6700. Usually it gets an IP address the second time, although the other day it took three restarts. This weekend, I tried setting up a computer with Ubunu 14.04 on the same network. Whenever I boot the computer, it reports that the network is unavailable. After several minutes, sometimes 15, it eventually finds the network. Since, I believe, the Flex is running Linux, I wonder if there is an incompatibility between the Linux DHCP client and the Apple Time Capsule DHCP server?

Mark Erbaugh

Also, rebooting the Ububtu box does NOT seem to make the network discovery any faster. In fact, if I restart or reboot after it has found the network, I have to go through another long time wait to find the network.

Mike KD2CJJ

I would suggest/some insight that can help track your issues down:

1.  Use a DHCP reservation if its available on the Apple Time Capsule.  This will store the MAC address or device ID of the device and always assign the same IP.  This will speed up assignment.

2.  Increase DHCP lease time for your clients - this will speed up assignment.

3.  Force the link speed to what ever you want it to be.  This some times alleviates link and/or dhcp issues.

4.  Turn off IPv6 - if your not using it, turn it off.  its  a known culprit of Linux networking issues for the older kernel versions of Linux

5.  Test your cables - especially those that have longer runs that are Gigabit.

6.  Make sure your time capsule has the proper time - too far off and DHCP lease will not be established.

7.  Remove any other switches that may be in between your time capsule and end point devices.

8.  Try turning off any Multi Cast devices on your network if you have.   These can cause havoc with DHCP.

In general, DHCP is more sensitive to issues in your network infrastructure communication paths because its based on UDP.

Hope one of these points helps.

Let me know if you want detail on any one point.

Mike

Mark Erbaugh

Mike,

Thanks for the suggestions.  I will try them out when I get a chance. 

I need details:

7. The Time Capsule has 3 downstream ports. I have more than three devices on my network. There is at most one switch between the Time Capsule and the end device. Would a temporary experiment of connecting the Flex and the SSDR computer directly to the Time Capsule be worthwhile?

8. How do I determine if a device is Multi Cast?  On the wired network, I currently have two computers (a PC for SSDR and a Mac Mini), a HP Officejet printer, a HD HomeRun (a device that streams TV received over the air - the Mac Mini serves as a DVR) and the Flex.

Thanks,
Mark

Mike KD2CJJ

7.  Yes.. experiment by removing the switch.  you would be surprised how switches (mostly low end / low quality) can cause reliability issues with DHCP.

8.  Multi Cast is typically used for devices that stream video or audio.  Your HD HomeRun device most likely uses Multicast - most likely over UDP.  However, most software implements loss detection and re-transmission rather than relying on TCP (makes sense due to the size of the packet of TCP).    This implementation may cause DHCP to fail if not properly implemented.     Turn this off for now also as an experiment.  Turn off all the clients also as they will be send out a "I am here" packet (if its a many to many Multicast implementation - I am not sure so just being safe). 

Mark Erbaugh

Mike,

I think you nailed it. It turns out that one of my switches was preventing Linux from connecting to the network. I replaced that switch and Linux is happy. I haven't had a chance to try the Flex, but I'm hoping that the switch change fixed my DHCP problem.

Tim - W4TME

If the FLEX-6000 works with the new switch, I would like to know the make the model of the switch that caused the issue.

Mark Erbaugh

I've started the Flex 6700 several times and it has never failed as before. It looks like the switch was the issue.

The switch is a D-LInk DGS-2205 5 port 10/100/1000 switch.

Mike KD2CJJ

Mark some times its the auto-negotiate mechanisms between the switch and the router cause the failure.. If you want to try, force on the Capsule highest supported link speed  that the switch supports and force Full duplex (if its even an option).  One other note, all switches, routers, etc. need to have the same link speed and duplex mode.  If not, that can also cause DHCP failures.  

Its just a try - however, it may not help as the switch just may be flaky.

One other note, daisy chaining switches can also potentially cause an issue (again typically due to the negotiating mechanisms - mostly due to timing). Ideally you want to have all switches/hubs come back to your router rather than daisy chain them.

Glad it help!

Peter K1PGV

(Excellent advice in this thread by Mike KD2CJJ!  It'd make a good KB article on debugging connectivity and DHCP problems.)

General Advice:

A good quality switch is *very* important to your network infrastructure.  And it's effectively impossible to evaluate the quality of a switch without sitting down to specifically do so, capturing dozens of network traces, and putting it through its paces.

Unfortunately, I haven't had the time to do a proper evaluation of switches in a very long time. However, if personal experience means anything, I can *strongly* recommend the HP Procurve 1410-8G.  It's an unmanaged, 8 port, 10/100/1000 switch.  The normal price is about $100, but it currently sells for $55 on Amazon. I've used these small switches in critical infrastructure at work (for example, to connect an active/passive firewall pair to our border router) as well as at home for several years, without any problems. Get 'em while you can: This 8-port version has been discontinued, in favor of a 16-port version that's twice as expensive.

Whatever you buy, you definitely want an unmanaged switch, unless you intend to actually actively manage the switch (and maintain its security, by changing the default username and password).

I'd love to hear other people's experience with reasonable cost 10/100/1000 switches that have exceeded expectations in long-term, high traffic, use.

Peter
K1PGV

Mike KD2CJJ

I generally have purchased all the major brands.  All of them work well.  None of them do more than another when your dealing with an un-managed switch.  When you venture into routers or managed switches than there are major difference in features - however, not much in terms of performance.  The amount of data you push within your home network typically 100 Mbs is sufficient - When you venture into NAS,  high bit rate streaming,  then I see Gigabit being a necessity.  Now a days its a commodity so I only run Gigabit in my home.  More often than not the issues one has with their network is due to poor cabling.  Most skimp on the quality of cables and/or heads.  When dealing with Gigabit you should have high quality cable and is a must have when dealing with runs greater than 20 feet.

The next number of issues are due to the way the network is designed.  Daisy chaining switches is NOT a good practice - even though it is a widely used practice with little to no issues.  Most will typically see 10 - 20% reducing in performance above 100 Mbs - below you wont notice the difference, except for intermittent DHCP issues.

Peter K1PGV

That's very interesting. Thanks for the reply. My experience has been very different. In my experience most lower-end switches do not support high line utilization on multiple ports simultaneously, often drop packets, and very often suffer weird protocol issues (even 100mbps protocol is complex). Latency can be very different also, depending on whether the switch does cut-through or store-forward. What's weird is that, aside from HP and the business grade Cisco switches (not the Cisco switches for home office use) which ALWAYS perform admirably, the models within a given brand seem to vary widely. Some Linksys bad... Some good. Some DLink bad.... Some good. But I've definitely seen very different behaviors among switches even at 100mbps. But my experience is just anecdotal. I have worked on networking professionally for more than 10 years. Peter K1PGV