I have seen conflicting statements about communication between two ID-1 sites that are served by the same RP-2D "repeater" + RP-2C controller. QuestionS:

When an RP-2D receives an Ethernet DD packet via DD, does it "repeat" (actually, store and forward) the packet to the same frequency?

Or, if the RP-2D doesn't do that, does the RP-2C?

In other words, can two ID-1 sites communicate w/ each other via a local RP-2D site?

No and No

If you put a router behind the RP-2C (or behind the 2c and gateway server) with the right routes (I do not know details but the guys in the Twin Cities area know this) then those at different ID-1 sites can communicate between each other. Otherwise the RP-2C/gateway server just boots the packets over to the default gateway and out to the Internet (or Intranet in my case)

We put servers behind the RP-2C and all just go there for our user here
in the National Capital Region. Like for the Marine Corps Marathon these
past 4-5 years.

73, tom n4zpt

On 2010-Sep-30 13:08 , dean_ae7q wrote:

I have seen conflicting statements about communication between two ID-1
sites that are served by the same RP-2D "repeater" + RP-2C controller.
QuestionS:

When an RP-2D receives an Ethernet DD packet via DD, does it "repeat"
(actually, store and forward) the packet to the same frequency?

Or, if the RP-2D doesn't do that, does the RP-2C?

In other words, can two ID-1 sites communicate w/ each other via a local
RP-2D site?

Yes and no. The RP-2D/RP-2C combo isn't an Ethernet bridge, and doesn't
seem to maintain an ARP table or TCAM or anything like that, at least
not by MAC address. (I suppose it might be doing so based on MY/YOUR calls.)

If you have 2 ID-1s on the same frequency and set to DD RPS, with
cross-matching MY/YOUR calls and sharing the same RPT1 call, then yes,
they form (basically) a point-to-point bridging tunnel between the
ID-1s. Multiple such tunnels should be able to run concurrently, limited
only by available channel time/transmitter duty cycle, etc.

However, a lone 3rd ID-1 can't talk to anyone. For multipoint (ie,
long-distance wireless LAN), you need an IP router hooked into the RP-2C
box. There are a few ways you can set it up (some of which probably
aren't compatible with using the G2 gateway software on the same stack),
but the key part is for each machine to not try talking directly to the
others, but instead to send via the IP gateway. Using a router with a
number of secondary IPs sliced up into /30-sized networks should work,
or you could use PPPoE, or you can play tricks with destination NAT (but
that requires extra special setup for the reverse routing.) As long as
the packets flow from machine A into the controller via the RF port, to
the router, and back to the controller and out via RF again, it should
be fine. Just setting up machines in the same subnet doesn't work,
because the repeater doesn't actually repeat or digipeat; the client
machines will never hear each other's ARP requests.

--
Peter Corbett :: KD8GBL
peter@...

On 2010-09-30 15:30, Tom Azlin N4ZPT wrote:

No and No ["... can two ID-1 sites communicate w/ each other via a local RP-2D site?]

Setting up routes the way Steve Stroh mentioned (each ID-1 has a unique 3rd octet) is simple and easy to do, but (of course) it's a bastardization of how networking is generally done. With the right router that supports classless addressing, it should not be necessary to chew up a whole class C subnet for each ID-1.

I'm in the unfortunate position of having an ID-1 and no one to talk to in DD mode (or in DV mode, but that may change soon). A friend (Scott Honaker / N7SS) has an RP-4000V, RP-2D, & RP-2C on a tower nearby, but w/o an Internet connection. Since (I think) I'm the only one that could hit it on 23cm, I can't really tell if I am hitting it (I can hit the 70cm unit w/ ease @ 5W).

Hence, I can't experiment, as the RP-2D gives NO on-air indication that it even exists (let alone powered on, receiving, etc). I think there is a way to set up IP routing that would work in a more conventional manner, but I can't test my idea(s).

I can hit the 2m & 70cm modules of the K7LWH system (about 25 miles away), but not the 23cm DV or DD modules.

My guess is that a few of you are in the same boat as well ...

开云体育

On 2010-09-30 16:42, Peter Corbett wrote:

...

 can two ID-1 sites communicate w/ each other via a local RP-2D site?
    

Yes and no. The RP-2D/RP-2C combo isn't an Ethernet bridge, and doesn't seem to maintain an ARP table or TCAM or anything like that, at least not by MAC address. (I suppose it might be doing so based on MY/YOUR calls.)
  

I didn't expect the RP-2D/2C combo to maintain an ARP table, but I was hoping that one of the two would just digipeat DD packets.

If you have 2 ID-1s on the same frequency and set to DD RPS, with cross-matching MY/YOUR calls and sharing the same RPT1 call [and I assume RPT2 is programmed w/ the gateway to accomplish this], then yes, they form (basically) a point-to-point bridging tunnel between the ID-1s.

Hmm, that works?? And why is it a tunnel (in the sense that no one on the local frequency couldn't hear it)?

However, a lone 3rd ID-1 can't talk to anyone. ... Just setting up machines in the same subnet doesn't work, because the repeater doesn't actually repeat or digipeat; the client machines will never hear each other's ARP requests.
  

Hmm, if it works for two ID-1 radios on the same DD module, let's say that we have several ID-1 radios (say, AAA, BBB, CCC, DDD, etc) on the same DD module (say, ZZZ), each programmed w/? "ZZZ A" for Rpt1 and "ZZZ G" for Rpt2, and as follows for UrCall:

AAA:? BBB
BBB:? AAA
CCC:? AAA
DDD:? AAA
etc:? AAA


Now you say that AAA and BBB can communicate (assuming their backing computers/routers are configured w/ appropriate IP and a common subnet mask).? When BBB ARPs for AAA, that packet goes back out on the ZZZ output, and surely AAA, CCC, & DDD receive it.? Are you saying that CCC (& DDD, etc) would discard the packet and not send it through to the RJ-45, because the UrCall doesn't match?

OK, now say that BBB ARPs for CCC.? I would think that since BBB is still programmed with a UrCall of AAA, that ZZZ would send it back out over the air (intended for AAA), and CCC (& DDD, etc) would see it just fine (again ignoring the UrCall field), and the backing computer/router would respond.

A similar argument goes for CCC (& DDD, etc) communicating back to AAA or BBB.? Again, unless the ID-1 filters packets based on UrCall, I would think this would work.

After all, this is exactly how I understand DV works, with many users on two different modules:? So long as each DV user programs the UrCall with ANY user's callsign on the _OTHER_ (remote) module (and of course sets up Rpt1/2 correctly), all of the users can hear all of the others.? Isn't that correct?? And isn't your "cross-matching MY/YOUR calls"? just a technique to fool the gateway into rerouting the packets back to the originating DD module?

Has anyone tried this?

Now if the ID-1 is applying DSQL-type filtering in DD mode, that would of course stop this in its tracks, but otherwise, it should work, I'd think (and for more than three ID-1 radios).

Note that in both the DD and DV examples above, AAA doesn't even have to be on the air for BBB, CCC, DDD, etc to talk to each other.? The only requirement would be that the gateway software would have to THINK that AAA was on the ZZZ DD module.

-- Dean 425-338-4276 (Seattle area) if you want to talk in detail, or even on WC7SO/C (usually listening).

ps: Four years ago, someone warned me about asking D-Star questions that might make me look stupid.? I don't mind looking stupid if I gain understanding in the process.? Besides ...

On 2010-Sep-30 19:58 , Dean Gibson AE7Q wrote:

On 2010-09-30 16:42, Peter Corbett wrote:

...

can two ID-1 sites communicate w/ each other via a local RP-2D
site?

Yes and no. The RP-2D/RP-2C combo isn't an Ethernet bridge, and
doesn't seem to maintain an ARP table or TCAM or anything like
that, at least not by MAC address. (I suppose it might be doing so
based on MY/YOUR calls.)

I didn't expect the RP-2D/2C combo to maintain an ARP table, but I
was hoping that one of the two would just digipeat DD packets.

If you have 2 ID-1s on the same frequency and set to DD RPS, with
cross-matching MY/YOUR calls and sharing the same RPT1 call /[and I
assume RPT2 is programmed w/ the gateway to accomplish this]/, then
yes, they form (basically) a point-to-point bridging tunnel between
the ID-1s.

Hmm, that works? And why is it a tunnel (in the sense that no one
on the local frequency couldn't hear it)?

Hear, but choose to ignore.
More tunnel, in the sense of 'ethernet in here, magic happens, ethernet
out there'.

RPT2 is only used with the Icom gateway and friends; if you're staying
local to the RP-2C, it stays blank, IIRC.

However, a lone 3rd ID-1 can't talk to anyone. ... Just setting up
machines in the same subnet doesn't work, because the repeater
doesn't actually repeat or digipeat; the client machines will never
hear each other's ARP requests.

Hmm, if it works for two ID-1 radios on the same DD module, let's
say that we have several ID-1 radios (say, AAA, BBB, CCC, DDD, etc)
on the same DD module (say, ZZZ), each programmed w/ "ZZZ A" for
Rpt1 and "ZZZ G" for Rpt2, and as follows for UrCall:

AAA: BBB BBB: AAA CCC: AAA DDD: AAA etc: AAA


Now you say that AAA and BBB can communicate (assuming their backing
computers/routers are configured w/ appropriate IP and a common
subnet mask). When BBB ARPs for AAA, that packet goes back out on
the ZZZ output, and surely AAA, CCC, & DDD receive it. Are you
saying that CCC (& DDD, etc) would discard the packet and not send it
through to the RJ-45, because the UrCall doesn't match?

OK, now say that BBB ARPs for CCC. I would think that since BBB is
still programmed with a UrCall of AAA, that ZZZ would send it back
out over the air (intended for AAA), and CCC (& DDD, etc) would see
it just fine (again ignoring the UrCall field), and the backing
computer/router would respond.

Yes, the incoming packet's UrCall doesn't match the local MyCall, so (as
far as I can tell) CCC and DDD would ignore the packet.

I haven't tried having 2 ID-1's who both think they are BBB (but with
different IPs on the machines behind them), but it should work as long
as both BBBs never want to talk to each other.

Similarly, I'm not really sure what the behavior of using UrCall=CQCQCQ
is on DD. I want to say we've tried that, and it isn't as magic a
solution as ought to be.

After all, this is exactly how I understand DV works, with many users
on two different modules: So long as each DV user programs the
UrCall with ANY user's callsign on the *_OTHER_* (remote) module (and
of course sets up Rpt1/2 correctly), all of the users can hear all of
the others. Isn't that correct? And isn't your "cross-matching
MY/YOUR calls" just a technique to fool the gateway into rerouting
the packets back to the originating DD module?

I'll admit that I haven't operated DV at all, but I'd been under the
impression that the convention was to leave the UrCall as CQCQCQ to get
the traditional everyone-hears-everyone behavior, and only to change the
programing of UrCall when you wanted a one-on-one conversation?

Has anyone tried this?

Now if the ID-1 is applying DSQL-type filtering in DD mode, that
would of course stop this in its tracks, but otherwise, it should
work, I'd think (and for more than three ID-1 radios).

Note that in both the DD and DV examples above, AAA doesn't even have
to be on the air for BBB, CCC, DDD, etc to talk to each other. The
only requirement would be that the gateway software would have to
THINK that AAA was on the ZZZ DD module.

...when the gateway software is in use, perhaps. The 'repeater' stacks
I've played with here don't run it at all; they only run an IP router
behind the RP-[12]D.

--
Peter Corbett :: KD8GBL
peter@...

Oh, I was saying no to it being a repeater or digipeater.

And no to the two ID-1 communicating via an RP-2C/D with no special routes or servers behind the RP-2C/D. Certainly two ID-1 can make a bridge.

Agreed with all you were saying Peter. It matches our experience these past years. 73, tom n4zpt

If you are in range of that RP-2C/D then when you put your ID-1 in DD RPS, have the call signs right, put in fixed ip/mask/default gateway addresses in you laptop, and plug the ID-1 into the local laptop you should see the radio and the access point talking. If not in range your ID-1/laptop will be trying to connect but you will see nothing coming back.

On range: We see that even when we have 3 bars in the DV mode we sometimes get nothing in the DD mode on the co-located site using same antenna and a triplexer. (no FEC and a 128/4.8 worse path I suppose).

We have put a small laptop behind the RP2C running the network we wanted (ignoring the normal ip address of the 2C) and we then can ping the laptop "server" and access files on that server. That is why I think of it as a bridge but I am not a networking expert. Just manage a complete D-STAR Stack where we are playing with the 23cm DD every once in a while.

Also understand on just a single ID-1 so hard to do testing. We had a gang buy them so started setting up LAN parties to try every thing.

We stashed the docs we had here



73, tom n4zpt