SmartSDR cant access Internet after upgrade to 3.2.31

Christopher Platt

I have upgraded Smart SDR on a previously working Flex 6600. Post upgrade I can operate the Flex via the LAN, I cannot access it via the Internet. The Smartlink setup test fails. The 6600 has a fixed IP, the fixed IP is routed via a Microtek Router with port forwarding UDP 22000 - 4993 and TCP 21000 to 4994. I have not changed the Router setup post Smart SDR upgrade and it appears intact.  

As part of the upgrade process I got a BSOD and the unit hang on the purple button phase and then hung on the second firmware upgrade requiring a power reset. After it was complete I did a factory reset.

I think SmartSDR does not have the port forwarding right (I don't use upnp for security reasons as my net work is open to the web) BUT we can't find the screen (that used to exist) to manually tell SmartSDR which port goes where.

Any suggestions as to how to check the port settings

I am with the radio for the next 4 days but will need remote access after that

David Decoons, wo2x

Change the radio to use DHCP then set a DHCP reservation in the router to have the router assign he desired IP to the radio.

I have heard of this issue before with 3.2.31.

Dave wo2x

Christopher Platt

Have now set SmartSDR as DCHP with the router setting the same IP address as before based on MAC address. Had to manually return SmartSDR settings for ports to 21000 and 22000 respectively. SmartLink now Tests OK.

Watts - K4QJZ

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

Watts - K4QJZ

Should say Can't use Smartlink, sorry for the typo.

Mike-VA3MW

This issue is a bug we introduced in 3.2 and we are so sorry about that.

We have a fix coded for it and there will be an update available once it goes through program review and QA.

The work around is:

Set the radio to DHCP for an IP request (automatic)

If the IP address is critical, do a DHCP Reservation (if possible)

Review your Port Forwarding rules on the radio and then also check the uPNP rules in your Router

If you do not see your uPNP rules match what they should be, power cycle the radio and that should send the uPNP commands to the router.

If still stuck, please open a support case so we can isolate it.

*** BTW, if you have no idea what I am talking about, you don't have to worry and just leave everything at the default settings and the radio will do the right thing *** 😁

Mike-VA3MW

This issue is a bug we introduced in 3.2 and we are so sorry about that.

We have a fix coded for it and there will be an update available once it goes through program review and QA.

The work around is:

Set the radio to DHCP for an IP request (automatic)

If the IP address is critical, do a DHCP Reservation (if possible)

Review your Port Forwarding rules on the radio and then also check the uPNP rules in your Router

If you do not see your uPNP rules match what they should be, power cycle the radio and that should send the uPNP commands to the router.

If still stuck, please open a support case so we can isolate it.

*** BTW, if you have no idea what I am talking about, you don't have to worry and just leave everything at the default settings and the radio will do the right thing *** 😁

Roli_HB9BAS

I operate two remote sites. One has a Flex-6700 and the other a Flex-6600, which has always worked relatively well.
On Sunday I updated both Flex to the new version 3.2.31.
Now SmartLink no longer works on both stations :( . Locally they work. I have changed absolutely nothing in the settings (router, IP addresses, port forwarding).
Other devices (Rotor, Linear etc.) work fine.
SmartLink login works and the SmartLink window shows my data. But SmartLink does not see the Flex.

Workaround: You mean I need to switch uPNP on?

I am using fixed IP addresses and port forwarding.

Alan

Mike

Just so I am clear, the current need is for the Flex to be on router DHCP assigned IP and not static IP...correct?

I ask, because some may be thinking the public IP address cannot be static....perhaps?

In my case, I have a static public IP and a router DHCP assigned Flex Radio IP with port forwarding thru the router for ports 4993 and 4994. My Smart Link also, and recently after upgrade to 3.2, will not give a good test.....so I was looking in other directions. Or have you had reports of static public IP addresses being a problem too?

Alan

WA9WUD

Mick W8BE

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.

John KB4DU

Regression testing?

Mike-VA3MW

@Mick W8BE

Thanks, we know what regression testing is. :)

Turns out that the large population of testers don't use Fixed Static IP addresses at all and SmartLink. The tests have been updated, and, sadly, sometimes this happens in a product lifecycle.

Sorry about that. It wasn't intentional.

David Decoons, wo2x

I'm an alpha tester.

I have been using DHCP reservations for equipment on the network for years. The reason is this, if I bring the radio to Field Day and they are using a different subnet than I use at home I cannot have my laptop talking to the radio and have it talking to the N1MM+ master computer on the network. Also for troubleshooting or testing by connecting the radio direct to the computer it would not be able to use the link local IP 169.254.x.x if set to static IP.

There are very good reasons to change to using DHCP reservations instead of static IP address in the radio. Once you set up the reservation in the router for the radio you then can set the port forwarding to the reserved IP. You do not need to use a static IP to do port forwarding.

This should be a good time for those using static IPs to make the change. Again, several benefits of using DHCP reservation vs static. One more point, down the road you get a new router and it uses a different subnet than your old router. Unless you remember to change the radio first you will not be able to easily communicate to the radio.

Most manufacturers have information readily available on how to set up DHCP reservations for their routers.

Now in a data center (commercial world) there are valid reasons to use static IPs instead of DHCP reservations.

Food for thought.

Dave wo2x

Dan-N7HQ

#1 You did not catch the static IP issue? -- Come on Man.... Does not speak well of your testing.

Yes, we definitely should have caught that one. There is no excuse for missing it. The changes that caused the static IP issue are among a large number of internal changes to the firmware, designed to be transparent to you and prepare the platform for upcoming things.

In this specific case:

1) We now require DNS to locate NTP and SmartLink services on the internet. This was not the case in earlier versions.

2) DHCP now runs as a daemon in the radio OS and behaves like other network devices. For example, if a LLIPv4 (link local IPv4) address is negotiated due to the lack of a discoverable DHCP service, when the radio wakes up, the radio follows the current DHCP RFC specs and will periodically look for and apply a proper DHCP response. In the static case, our GUI does not allow users to specify specific DNS servers, so the radio it has no way to resolve the URIs used for NTP and SmartLink services. This is why SmartLink is broken for customers using a true static IP.

RESERVED IP addresses are not the same, are not impacted because the radio will receive DNS server addresses in the DHCP handshake. 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.

We've had several customers report that some other device now occupies the same IP address they had set as static. If you are in that camp, please review the range of IP addresses configured in the DHCP scope. You may have inadvertently allocated a static IP address inside the DHCP address range without reserving it first. Again, a DHCP reserved IP address is the answer.

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.

#2 Please put api changes like meter indices in the release notes.

If you are using the meter API, you cannot write code that treats the meter identifier (index) as a value that will not change. The order in which meters are created is not guaranteed and they can also be created by components external to a radio. The PGXL for example creates five meters.

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.

73,

Dan

Erik Carling EI4KF

On the (very) plus side: there has been no shortage of support from Flex for this and the other rare issues arising, even through the Easter break for some users. It has not been a case of 'here's your update, get on with it', more like 'we're on standby to get all issues resolved'.

Mick W8BE

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.

Jonas

Hi, when do you have the update ready? and how, install SmartSDR again or what?

/ Jonas

Mike-VA3MW

When the fix is released, it will be a similar process.

Download SmartSDR and run the installer.

Mike

Arve

Ran into the same problem at the remote QTH where I rely on Static IP. Up and running after having switched to DHCP and changed port forwarding accordingly. However, I will have to update port forwarding with every IP address change.

My rural area ISP provides a “proven” fiber modem/firewall/switch without fancy mechanisms like UPNP or DHCP Reservations, so I have to rely on good old Static IP and port forwarding.

So, to FlexRadio: It is nice having the more modern alternatives, but please keep forever (and always test) Static IP as a fallback alternative for the many users that have to rely on the ISP’s choice of equipment.

Arve/LA3HM

David Decoons, wo2x

Arve

ask your ISP if they can do a DHCP reservation if you give them the MAC address of the radio.

some of the rural ISPs use a single public IP then provide local LAN IPs to their customers. This can also cause double batting if you add your own router.

Dave wo2x

N8EMA_Jeff

*****
> @Dan-N7HQ said:

> RESERVED IP addresses are not the same, are not impacted because the radio will receive DNS server addresses in the DHCP handshake. 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.
> We've had several customers report that some other device now occupies the same IP address they had set as static. If you are in that camp, please review the range of IP addresses configured in the DHCP scope. You may have inadvertently allocated a static IP address inside the DHCP address range without reserving it first. Again, a DHCP reserved IP address is the answer.
*****
I run my flex with a Static IP of 192.168.1.125 this address is RESERVED for the Mac address of the flex...due to the latest update I had to switch to DHCP "all works with SmartLink, even though I have a reservation for the Flex Mac address DHCP still assigns what ever address it wants??? currently the radio is showing 192.168.1.111

Uwe - DK3WW

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

Mike-VA3MW

This might help explain a few things (and, maybe not)

Part of the reason we recommend DHCP and uPNP is that (and I say this a lot) about 90% of the customer install base (and even more support cases) are related to LAN and IP addressing.

Even I find that surprising and that is why we keep doing videos on it. In most cases, you can have a customer reboot the radio and the router if need be and the Router updates its uPNP tables with the proper Radio IP and SmartLink functions. While disabling uPNP may be more secure, it comes at a performance price for those applications that require specialized port forwards (skype, voip phones, cameras and more). The uPNP security risk is pretty low if not non-existent. I don't know a single person who has suffered from a uPNP based hack. I'm not saying they are out there, but they are pretty rare.

This is why we recommend DHCP or DHCP reservation from a long term supportability. Again it falls apart when someone sells their radio or takes their radio to another network and it doesn't function. This turns into a support call.

If a customer just plugs the radio in to his commercial ISP provided router and the ISP provides a WAN address, the radio and SmartLink are almost flawless. I actually does 'just work'. When it works then we get less post sales support calls, which is a goal as those actually cost money to deal with (paid staff, etc). This is also why ISPs are locking down their modems/routers and that is to reduce support calls. (me... I want it in bridge mode, thank you -- Rogers Canada does do that, which is nice. Bell Canada, not so much).

It is part of the 'if it ain't broke, don't fix it' rule.

It gets ugly when people tell their friends to do something (or they do it for them) and then then call in 11 months later saying it is broken and then Tim, Ken and others have to spend time on the phone trying to figure it out. The time adds up.

There is a much smaller subset of customers who do their own thing, like Static IP address and DHCP reservations and that is ok, as you know what you are doing. Just don't forget what you did and make sure you have a diagram of your network topology (some of you have no idea how you wired your LAN -- you just plugged stuff in until it worked and then moved on).

It gets really tough with Range Extenders (a bad idea-they really don't work that well and 2 subnets), Mesh's that aren't in bridge mode (2 different sub nets) and ISP's who do Carrier Grade NAT (SmartLink failure).

Now, back to the issue with 3.2. Yes, we missed the fact that SmartLink broke with a static IP address. It turns out that we have no Alpha Testers that use a Static IP and Smartlink at the same time. That issue is now resolved. (I think I have said that before). When the new version of 3.2 is released, you can go back to using a Static IP address. Again, we apologize for the hit this might have caused to you. Trust me, it wasn't intentional.

If you read this far, I am pretty sure I know what you are going to say! :)

If you have ever been part of a design meeting for a product, or maybe in a club meeting on how the repeater system should be assembled you may understand part of the bigger design picture. You have to consider the longer term supportability

We have considered all the other ways to do a network connection to the radio but the design was to make it work for most if not all over the counter networks/customers (plug in the black box my ISP gave me with the modem/router/firewall/wifi in and be online).

73, Mike va3mw

Michael Wolff

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

Uwe - DK3WW

Using UPnP and DHCP, the LAN connection does not always work after restarting the radio. And then a factory reset has to be used. That cannot be a permanent solution! I very much hope that it won't be long before the necessary update.

73! Uwe

DK3WW