Do not use APIPA when programming an IP address!

Can't talk to your radio? This is the place to ask!
dl1ycf
Posts: 10
Joined: Fri May 17, 2019 7:16 am

Do not use APIPA when programming an IP address!

Postby dl1ycf » Fri May 17, 2019 11:58 am

Dear all,

If you "program" a new IP address into an ANAN-7000 (this probably is also true for all other devices), the netmask is tacitly kept (left unchanged). This means it is not possible to "program" an IP adress, say, 192.168.1.12 with netmask 255.255.255.0, by simply connecting an out-of-the-box ANAN with a PC through a direct ethernet cable and using the HPSDRBootloader utility.

In this case, PC and ANAN communicat using a "private" APIPA address of form 169.254.xxx.yyy with netmask 255.255.0.0, and this mask is then retained and the ANAN will not work in a DHCP-less network 192.168.1.xxx (with netmask 255.255.255.0).

This is really true, changing the mask to 255.255.0.0 in my local 192.168 net did the job.

So you see, you MUST connect PC, Anan and a DHCP server to a switch, such that both PC and ANAN get an IP address in a local net with mask 255.255.255.0, and ONLY THEN you should program the new IP address to the ANAN.

This is nowhere documented, but (as I discussed with W1AEX) explains some other "strange problems" observed in the past quite well.

Yours, Chris DL1YCF
User avatar
W1AEX
Posts: 249
Joined: Sun Apr 09, 2017 6:17 pm
Location: Connecticut, USA
Contact:

Re: Do not use APIPA when programming an IP address!

Postby W1AEX » Fri May 17, 2019 12:45 pm

The advice posted by Chris is excellent and it is a good explanation for why some users are unable to make a static IP assignment work with a direct connection between their computer and their ANAN. I was not aware of the "sticky" netmask assignment of 255.255.0.0 that exists when an IP is derived through APIPA but a quick check at my favorite go-to network resource (Wireshark) confirms this.

https://wiki.wireshark.org/APIPA

Obviously, if you are directly connecting to any ANAN that has an APIPA 169.x.x.x address and you have created a NIC address of 192.168.x.x for the computer's second NIC, windows will assign a default netmask of 255.255.255.0 to your computer's NIC. This will not connect to any IP address that is assigned to the ANAN with HPSDRProgrammer or Bootloader if it has a 169.x.x.x APIPA address because the netmask assigned to your ANAN through APIPA will have the 255.255.0.0 mask address. To get this working you should connect the ANAN to a router so it receives an IP through DHCP where it will receive an IP with a netmask of 255.255.255.0, and then use HPSDRProgrammer or Bootloader to make your static IP assignment to the ANAN, or change the netmask address of your computer's second NIC to match the APIPA netmask of 255.255.0.0 that is in the ANAN.

Thanks for sharing what you found Chris. I think this will help a lot of people who were unable to establish a working direct connection with a static IP assignment on a second NIC port.

73,

Rob W1AEX
"One thing I am certain of is that there is too much certainty in the world."
User avatar
w-u-2-o
Posts: 1880
Joined: Fri Mar 10, 2017 1:47 pm

Re: Do not use APIPA when programming an IP address!

Postby w-u-2-o » Fri May 17, 2019 2:06 pm

What is described doesn't seem to be a problem. It is the normal functioning of APIPA. Since APIPA will randomly assign an IP of form 169.254.x.x using the last two octets the APIPA subnet mask MUST be 255.255.0.0 on any interface that uses APIPA, PC or radio. If it is not then there is a good chance you will be disappointed.

Similarly, one cannot have a static IP set on a PC NIC and expect APIPA to work. It needs to be set for DHCP.

Also, if the radio should have a subnet mask of 255.255.0.0 that really has no bearing on the situation even when it is using a static IP or DHCP IP. The radio will respond to more IP addresses, not less.

None of what is described changes the fact that to change the radio IP address with HPSDR Programmer the PC must have access to the radio subnet by an appropriate combination of IP address and subnet mask. Of course, none of this matters if one uses HPSDR Bootloader to change the radio's IP address, because HPSDR Bootloader uses raw Ethernet frames to do this and doesn't care about IP addresses or subnet masks, only the MAC of the radio. One oddity: in Bootloader mode the radio artificially changes its MAC to 00-11-22-33-44-55-66, which is an illegal MAC and it will not be passed by any Layer 2 or Layer 3 managed Ethernet switch.

So what am I missing? Where is the problem? It all seems to be working as expected according to the Ethernet networking standards, except for the aberrant MAC address that Bootloader uses.
User avatar
W1AEX
Posts: 249
Joined: Sun Apr 09, 2017 6:17 pm
Location: Connecticut, USA
Contact:

Re: Do not use APIPA when programming an IP address!

Postby W1AEX » Fri May 17, 2019 7:44 pm

The problem is that if you set the IP address of the ANAN with HPSDRProgrammer or Bootloader while the ANAN is directly connected and using the self-assigned 169.xxx.xxx.xxx APIPA address it will take whatever 192.168.x.x or 10.x.x.x IP address you program it with but it will retain the 255.255.0.0 mask used by APIPA. When configured like that It may not talk to your computer's NIC which presumably is in the same subnet as the ANAN's manually assigned IP but will have the windows assigned 255.255.255.0 mask.
"One thing I am certain of is that there is too much certainty in the world."
User avatar
w-u-2-o
Posts: 1880
Joined: Fri Mar 10, 2017 1:47 pm

Re: Do not use APIPA when programming an IP address!

Postby w-u-2-o » Fri May 17, 2019 9:37 pm

Again, if, hypothetically speaking, if the radio has an IP of 192.168.1.5, and the PC is 192.168.1.4, then it should not matter if the radio subnet mask is 255.255.0.0. With that subnet mask the radio should happily communicate with any IP in the range of 192.168.x.x.

I just took a look through the P1 firmware code and don't see where the subnet mask is used or assigned at all.

Also, there is no way that I know of to know what the subnet mask of the radio is. Ping will not reveal this information, nor will any arp command.
User avatar
W1AEX
Posts: 249
Joined: Sun Apr 09, 2017 6:17 pm
Location: Connecticut, USA
Contact:

Re: Do not use APIPA when programming an IP address!

Postby W1AEX » Sat May 18, 2019 12:04 am

Scott,

As you said, who knows what mask assignment the ANAN actually has? Watching my ANAN subnet with Wireshark simply shows UDP packets happily going back and forth from 192.168.5.1 (the NIC) and 192.168.5.2 (the ANAN) with no cares at all. My guess is that if the ANAN and the NIC it is directly connected to are in different class subnets (B and C) the reliability of the connection may depend on what two IP assignments are chosen by the user who is setting up the static assignments.

Being curious, with the protocol 1 firmware installed in my 200D the HPSDRProgrammer would not find my 200D when the NIC mask was changed to (class B) 255.255.0.0 and didn't match the presumed (class C) 255.255.255.0 mask of the ANAN. OpenHPSDR didn't seem to care and found the ANAN right away with the mismatch. After I closed down OpenHPSDR I tried the HPSDRProgrammer again and it found the ANAN, however, it was hit or miss with several more attempts. I didn't check, but I'm sure the Bootloader would have no problem with the mask mismatch.

There have been probably a dozen people who have contacted me over the past 4 years because they could not get a static assignment to work and I am wondering now if they tried to set the IP while directly connected with the ANAN sitting there with its APIPA self configuration assignment and ran into what Cristoph did where he was unable to connect until he changed his NIC mask to match the presumed class B mask assignment given by APIPA to his ANAN.

It's cloudy enough for me to suggest that it's wiser to assign a static IP through a router!
"One thing I am certain of is that there is too much certainty in the world."
User avatar
w-u-2-o
Posts: 1880
Joined: Fri Mar 10, 2017 1:47 pm

Re: Do not use APIPA when programming an IP address!

Postby w-u-2-o » Sat May 18, 2019 12:14 pm

W1AEX wrote:There have been probably a dozen people who have contacted me over the past 4 years because they could not get a static assignment to work and I am wondering now if they tried to set the IP while directly connected with the ANAN sitting there with its APIPA self configuration assignment and ran into what Cristoph did where he was unable to connect until he changed his NIC mask to match the presumed class B mask assignment given by APIPA to his ANAN.
Again, the NIC subnet mask on the PC side should not need to change from 255.255.255.0 except when using APIPA.

I'm not in a position to try this, because I'm not going to perturb my setup, but I'm pretty sure the following will work fine:

1. Obtain a correct APIPA connection to the radio (PC NIC set for DHCP and 255.255.0.0, radio set to 0.0.0.0).
2. With a correct APIPA connection established, use HPSDR Programmer to set the radio IP to 192.168.1.5.
3. Power cycle radio.
4. Change PC NIC to a proper static IP of 192.168.1.4 and subnet mask of 255.255.255.0.

At this point you should be able to communicate with the radio.

The above example assumes no IP address conflicts on the network with 192.168.1.4 and 5 addresses. Adjust as required for the experiment.
dl1ycf
Posts: 10
Joined: Fri May 17, 2019 7:16 am

Re: Do not use APIPA when programming an IP address!

Postby dl1ycf » Mon Aug 05, 2019 10:25 am

w-u-2-o wrote:Again, if, hypothetically speaking, if the radio has an IP of 192.168.1.5, and the PC is 192.168.1.4, then it should not matter if the radio subnet mask is 255.255.0.0. With that subnet mask the radio should happily communicate with any IP in the range of 192.168.x.x.

I just took a look through the P1 firmware code and don't see where the subnet mask is used or assigned at all.

Also, there is no way that I know of to know what the subnet mask of the radio is. Ping will not reveal this information, nor will any arp command.


This is plainly wrong. The subnet mask implicitly determines the broadcast address.

DL1YCF Christoph.
dl1ycf
Posts: 10
Joined: Fri May 17, 2019 7:16 am

Re: Do not use APIPA when programming an IP address!

Postby dl1ycf » Mon Aug 05, 2019 10:31 am

W1AEX wrote:Scott,

It's cloudy enough for me to suggest that it's wiser to assign a static IP through a router!


The main reason for assigning a static IP address is (at least for me) that I can use the gear both in my lab (connected to a switch)
and for doing QSOs (where I have a direct wire between the SDR and my Laptop, no router, no switch).

Having a fixed IP address, say, 192.168.1.98, is just working fine also when connected to a DHCP router for the 192.168.1.xxx
subnet, because these routers usually assign addresses from the "low end". Sometimes I replace the switch by a router
(for doing OS updates on the Raspberry and TinkerBoard). But normally 192.168.1.x is a "local subnet" in my lab.

So my fixed-IP-ANAN just plays well, no matter whether it is connected to a router, to a switch, or directly to the PC.

DL1YCF Christoph.
User avatar
w-u-2-o
Posts: 1880
Joined: Fri Mar 10, 2017 1:47 pm

Re: Do not use APIPA when programming an IP address!

Postby w-u-2-o » Mon Aug 05, 2019 11:22 am

dl1ycf wrote:
w-u-2-o wrote:Again, if, hypothetically speaking, if the radio has an IP of 192.168.1.5, and the PC is 192.168.1.4, then it should not matter if the radio subnet mask is 255.255.0.0. With that subnet mask the radio should happily communicate with any IP in the range of 192.168.x.x.

I just took a look through the P1 firmware code and don't see where the subnet mask is used or assigned at all.

Also, there is no way that I know of to know what the subnet mask of the radio is. Ping will not reveal this information, nor will any arp command.


This is plainly wrong. The subnet mask implicitly determines the broadcast address.

DL1YCF Christoph.
It is not wrong. And the broadcast address, which, while you are certainly correct about how it will change based on the subnet mask, has absolutely nothing to do with this issue. Any discussion of broadcast address is not relevant to this issue.

Return to “Network Connections & Network Hardware”