Is this normal behavior ?

I have 3 sites deployed across 5 counties now. Three of the sites have multiple radios and I have deployed switches to connect the radios at each site.

On one site the radios are not running the same version of code. i.e. 1.1.2 on one radio 3.0.0b2 on the other. The 1.1.2 is connecting to another site running 1.1.1 and the 3.0.0b2 is linked to another site running 3.0.0b2. from the 1.1.x side I can't see past the first 3.0.0 node and the same coming back in the other direction.  The sites are all running 3.0 code with the exception of the one site.

Site 0 AE4ML500 Linked 0.5miles to AE4ML501 ( Both 3.0.0b2)

Site 1 AE4ML501 (3.0.0b2)

Site 1  AE4ML510 linked 36 miles to AE4ML509

site 2 first link AE4ML509 linked to AE4ML510( Both 3.0.0b2)

site 2 second link AE4ML502 1.1.2 linked 18 miles to KO2F505 1.1.1

site 2 third link  AE4ML509 linked 8 miles to W4LAN500 (Both 3.0.0b2)

Site 3 KO2F505 linked to KO2F502 1.1.1

Local Switch site 2

fa0/14 AE4ML509 (3.0.0b2)

fa0/15 AE4ML502 (1.1.2)

fa0/16 AE4ML202 (3.0.0b2)

As seen from AE4ML509

AE4ML502 shows up as an IP address only and not a name. I'm unable to hop over to that IP address of AE4ML502. 

The question becomes is this normal behavior for the two versions of code ? If so I only need verification to go to that operator to get him to upgrade.  

site 3 W4LAN500 linked 7 miles away to AE4ML509

Yep this (well any anomalous behavior) is expected when two networks of different protocol versions come together.

RF and DTDLink does not bridge between versions, 1.1.X was protocol version 2, starting with protocol version 3 the protocol is the first number of the release so you can more easily see compatibility. Upgrading the 1.1.x nodes to 3.0.0rc1 should solve the issue you are seeing.

Thank you Conrad for confirming what I was seeing.