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@...
