SmartSDR cant access Internet after upgrade to 3.2.31

I had the same issue when I upgraded but still can use SmartLink. I have set my router to fix the address of the radio based on its MAC address as suggested. Smartlink shows green. It sees the radio now but if I try to access the radio via smartlink it causes the local user to lose connection and the radio to lock up to where I can't see it on the network or shut it down.

Removing power and doing a factory rest gets it back to functioning normally on the local LAN only. I do not beleieve its a bad profile as I get the same issue using only the profile in the radio after a factory reset. Help ticket submitted

A couple of comments for Flex - #1 You did not catch the static IP issue? -- Come on Man.... Does not speak well of your testing. #2 Please put api changes like meter indices in the release notes. That is not asking for too much.

Regards.

Thanks, we know what regression testing is.

@Mike-VA3MW I never said you don' know what testing is. Dan confirmed my opinion that your testing procedure has issues. Apparently you have no alpha users using static IP's.

The bottom line is, if you have set a static IP address for your radio, and use SmartLink, please review the actual need for a static IP and migrate to a reserved IP address in your DHCP service.

@Dan-N7HQ This reads like SmarLlink will no longer support static IP addresses. Can you advise. Let me explain why static IP's may be necessary. Lets say you have a remote station that you want to control with node red. Let say you want to enable a TCP client on the Flex to read meter data. You will find you need to use a IP address to configure Node Red. Now if your on DHCP all is well until the router decides to renew the IP lease with a different IP address. Your Node Red flow is now broke. As Dan pointed out DHCP reservations looks to be the answer if Flex drops support for SmartLink static IP support. This was a major change and no where was it documented It looks to me like the whole issue was overlooked by everyone, Flex and alpha, beta testers.

Please advise if you plan to address the static IP issue with a new release or require everyone who uses SmartLink to reconfigure their radios.

First, ask SSDR for a list of meters from the radio, then select the meter(s) you want based on the source and name parameters, not the index. Temporarily preserve the index (and other values) so you can decode the data as it arrives.

I have no problem of querying the radio for the list of meters. Yes they change. Would have been nice to know before I loaded the code and found that the meters did not work. I did not ask you to provide the list. All I requested was a note saying meters were enhanced, changed, what ever you want to call it. Give me a heads up please. Once again that is not asking to much.

There are very good reasons to change to using DHCP reservations instead of static IP address in the radio.

Depending on what Dan advises regarding the future of static IP address support, this may be the time to do that. The folks who maintain our router understand networking. We work with Cisco, Juniper routers on a daily basis. If the release notes had indicated such, we would not be having this discussion now. SmartSDR 3.1.12 supports static ip address and SmartLink works. SmartSDR 3.2.31 does not. There was no indication that support was being dropped. So who has the problem here?

Last comment to Flex on this.

I am still a big Flex fan. However it's seems you are your own worst enemy at times. You enable a lot of Flex bashing by making mistakes like this. There was no rush to get 3.2.31 out the door. Everyone knew the pandemic put updates on hold. You could have spent another couple months testing and documenting the changes so this release would have went much smoother.

Hello,

A factory reset every day so that the LAN connection works again. This is very frustrating, but I'm used to the wait ... The quality control for this release failed or did not take place. In my case I would have lost my job but it is ONLY HAM RADIO ...

73 & good health - Uwe

In regard to Dan, N7HQ's comments regarding DHCP -

" ...when the radio wakes up, the radio follows the current DHCP RFC specs and will periodically look for and apply a proper DHCP response..."

I have evidence that indicates otherwise. I am now seeing absolutely zero DHCP packets coming from the radio, as indicated by a lack of attempts for DHCP negotiation in /var/log/messages on the CentOS 7 server that serves DHCP on that subnet. Other hosts on the same subnet are working just fine on the same subnet served by the one DHCP daemon serving that subnet. I have the skills, ability, and a little bit of time I can dedicate to configure my network to do Wireshark traces if someone wants to see what the radio is sending on the connected Ethernet port.

then Dan says-

"There are a few routers we are aware of, where static port-forwarding is not available to devices that have reserved IP addresses, but in all cases I am aware of, UPnP port-forwarding is available and can be used instead. Submit a helpdesk ticket if you need help with this."

Please help me understand - maybe, since I use commercial-market firewalls to protect things here at the house that will never support uPNP (i.e. my Juniper SRX firewall). I suspect since uPNP is not a service on the DMZ network to which my firewall is attached, that perhaps the DHCP client is not even being triggered to attempt anything? What is that relationship? There's a lot to consider with your assumptions around the availability of uPNP. I have configured static NAT to do what uPNP cannot do because it does not exist on my network.

"There are very good reasons to change to using DHCP reservations instead of static IP address in the radio."

Perhaps there are as many very good reasons not to do this. I suspect I am in the minority here, but as a seasoned veteran in network and cybersecurity engineering, all the consumer-level features in the average ham's home router are not available in the commercial firewall I run at my home (Juniper SRX). Sure, I am the exception to the rule here, but if I cannot trust you to do static configuration right, what happens when you break DHCP like appears to have happened in my case? The static options should work like they do on any other legitimate, configurable network device. It used to work, and needs to keep working the way it used to work.

If you made it this far, thank you for your time and attention. Feel free to reach out to me privately if you would like to accept my offer of providing packet captures and work things that way.

73

Mike Wolff, CISSP

AKA - KG4Y