[DSTAR_DIGITAL] Linux G2 Repeater Announcement

[dlake02]

At the end of last week, GB7MH, currently awaiting installation at our repeater 
site, was connected to the live Icom G2 Trust Network.

The repeater uses my Linux-based G2 compatible code, Robin Cutshaw's DPlus code 
(unmodified) and Pete Loveall's D-Star Monitor code (unmodified).

The repeater is a modified Tait T800 operating in full GMSK mode with 6.25kHz 
of bandwidth.

The interface board is the Satoshi first-generation GMSK Node Adapater.

The unit is capable of full callsign routing to/from the live G2 network 
including station updates.  G2 registration is available via a self-service 
webpage, much the same as on Icom G2 nodes.

The system is now on test pending site installation in the next few weeks and 
usually connected to REF005A.   Installation could be delayed if any 
service-impacting bugs are found - particularly with the G2 SQL replication.

I would like to thank (in no particular order) the following people who have 
made this possible:

- Satoshi Yasuda
- Jim McClellan
- Pete Loveall
- Robin Cutshaw
- Darren Storer
- Iain Philipps
- The members of the Ashdown Forest Repeater Group
- Anyone else that I asked a dumb question of and was kind enough to help me.

NOTE:  Until I am happy that the system is stable, software will NOT be 
available.  The G2 network is very fragile, and I need to be 100% sure that 
this system works without impacting other users before I'm prepared to release 
it.  

73  David - G4ULF

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Scott 

Congratulations on your progress.

Last night, I had a conversation via the GB7NM with G3SMU from GB7MH - totally 
G2 routed on the live G2 network.

I would be interested if you could G2 route from your software to my callsign 
via the G2 network ?  I was last seen on GB7MH, and am there most of the time.

I'm a little confused by your comment about FOUR trust servers - there is only 
ONE trust server outside of Japan, because the system as supplied by Icom does 
not allow for multiple levels of trust. 

The whole point of G2 callsign routing is that EVERY node is accessible to the 
Trust Server.  

The alternative is disconnected pockets of D-Star - that would be very 
confusing to users, where they have a local D-Star repeater on a different 
network, hence unable to reach their contact.

I had experience of this on the Dutch/German border recently - there are a 
series of "linked" D-Star repeaters on their own network, and I was unable to 
reach anyone in the UK on the USRoot Trust Server !  But the only indication 
you get is a RPT? back when you try and call someone that you had previously 
worked on the main G2 network. 

That is certainly not what I want - that is why 99% of my project has been to 
ensure that I have compatibility and interoperability with the de-facto network 
and the trust of those that are kind enough to run it on behalf of the whole 
Amateur community. 

73 David - G4ULF

--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
>
> It was accepted by FOUR(4) ICOM TRUST servers, so far.
> 
> Scott.
> 
> --- In dstar_digital@yahoogroups.com, "john_ke5c"  wrote:
> >
> > --- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
> > > dstar_gwy_srv can be used on any DSTAR ICOM system,
> > > Europe,US, Japan,...
> > > 
> > > It is idependent of any "backbone",if there is such a word
> > > backbone when it comes to dstar.
> > > 
> > > I believe you mean dstar TRUST groups, not "backbone".
> > 
> > Is your software accepted by ICOM for use on their (and our) backbone?
> > 
> > But I have to agree with Aro, it wasn't the "first".
> > 
> > 73 -- John
> >
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Aro

Personally, I'm not too bothered about who is first/second/third, but yes, my 
repeater has been live for about 10 days now on the real G2 network.

73  David  - G4ULF



--- In dstar_digital@yahoogroups.com, "aro_bugger"  wrote:
>
> > First home-made dstar G2 gateway went live today.
> 
> No, G4ULF was first last week with GB7MH, and his connect to ICOM backbone & 
> dplus & dstarmon - see his earlier post.  Is better?
> 
> 7/3, Aro
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Scott

There is no "European" Trust server !

There is one trust server because Icom only allow one in an entire network.  
That is the K5TIT trust server.

There are small pockets of isolated groups in Germany that are running a 
handful of repeaters, but these are no good to man-nor-beast as they are not 
connected to the vast majority of other D-Star repeaters in Europe, a continent 
in which I live !

These disconnected pockets will breed yet another overlay network - we have far 
too many already, IMHO.

73 David - G4ULF



--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
>
> 
> There are 4 European ICOM TRUST servers.
> You would need permission with them to register your
> home-made "ICOM compatible" G2 Gateway, same thing with the US.
> 
> I also have instructions on how to create a NEW ICOM 
> TRUST server. They have created their own ICOM TRUST server,
> just like K5TIT did.
> 
> They are pretty active witrh their ICOM TRUST server
> and they allow registration from anyone that wants to learn.
> I do not believe that they would deny you registration
> if you asked them. 
> The Europeans TRUST server groups are very friendly.
> 
> My dstar "ICOM compatible" G2 Gateway KJ4NHF 
> went live with the European TRUST server a couple of weeks ago.
> 
> Scott/KI4LKF
> 
> --- In dstar_digital@yahoogroups.com, "dlake02"  wrote:
> >
> > Scott 
> > 
> > Congratulations on your progress.
> > 
> > Last night, I had a conversation via the GB7NM with G3SMU from GB7MH - 
> > totally G2 routed on the live G2 network.
> > 
> > I would be interested if you could G2 route from your software to my 
> > callsign via the G2 network ?  I was last seen on GB7MH, and am there most 
> > of the time.
> > 
> > I'm a little confused by your comment about FOUR trust servers - there is 
> > only ONE trust server outside of Japan, because the system as supplied by 
> > Icom does not allow for multiple levels of trust. 
> > 
> > The whole point of G2 callsign routing is that EVERY node is accessible to 
> > the Trust Server.  
> > 
> > The alternative is disconnected pockets of D-Star - that would be very 
> > confusing to users, where they have a local D-Star repeater on a different 
> > network, hence unable to reach their contact.
> > 
> > I had experience of this on the Dutch/German border recently - there are a 
> > series of "linked" D-Star repeaters on their own network, and I was unable 
> > to reach anyone in the UK on the USRoot Trust Server !  But the only 
> > indication you get is a RPT? back when you try and call someone that you 
> > had previously worked on the main G2 network. 
> > 
> > That is certainly not what I want - that is why 99% of my project has been 
> > to ensure that I have compatibility and interoperability with the de-facto 
> > network and the trust of those that are kind enough to run it on behalf of 
> > the whole Amateur community. 
> > 
> > 73 David - G4ULF
> > 
> > --- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
> > >
> > > It was accepted by FOUR(4) ICOM TRUST servers, so far.
> > > 
> > > Scott.
> > > 
> > > --- In dstar_digital@yahoogroups.com, "john_ke5c"  wrote:
> > > >
> > > > --- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
> > > > > dstar_gwy_srv can be used on any DSTAR ICOM system,
> > > > > Europe,US, Japan,...
> > > > > 
> > > > > It is idependent of any "backbone",if there is such a word
> > > > > backbone when it comes to dstar.
> > > > > 
> > > > > I believe you mean dstar TRUST groups, not "backbone".
> > > > 
> > > > Is your software accepted by ICOM for use on their (and our) backbone?
> > > > 
> > > > But I have to agree with Aro, it wasn't the "first".
> > > > 
> > > > 73 -- John
> > > >
> > >
> >
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Scott

You forget one important, pertinent fact.

It Doesn't Work.

It is supposed to work, but it doesn't.  You CANNOT have devolved trust servers 
at the moment in the Icom network.  The pc_startipaddr must be unique.  If you 
have two, disconnected trust domains, then registering the same station in two 
locations could result in clashes in the start_ipaddr.  That would break G2 
routing even if you pre-cached the GIP table.

I repeat - there is no EU trust server.  There are a group of experimenters in 
Germany, but there is no EU-wide Trust Server.  99% of D-Star repeaters in 
Europe that are Internet connected are homed to the G2 Trust server run by the 
K5TIT team.  That is what creats a cohesive network.

If there are pockets of disconnected Trust Servers as you advocate, then there 
will be no way of communicating using G2 routing between those domains.

Building isolated trust domains is wrong, and we'll end up with yet-another IP 
overlay like D-Plus, D-Extra, IRLP, Echolink, eQSO, etc, etc.  A smaller and 
smaller Amateur community, more and more disconnected from each other.  

I have no problem with the technicalities of what you are doing.  

But your assertions that what the Amateur community want are smaller and 
smaller pockets of local connectivity are just plain wrong.

It's like having multiple telephone networks where you can only call someone on 
the same network that you are connected to, but not knowing that until you dial 
their number and nothing happens.

David - G4ULF


--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
>
> 
> ICOM TRUST servers support one TRUST talking to another.
> It is in the ICOM design.
> 
> Scott
> 
> --- In dstar_digital@yahoogroups.com, Erik Finskas  wrote:
> >
> > ham44865 wrote:
> > > More dstar repeaters are coming online in the EU trust.
> > > 
> > > I am sure other Continents or Countries will do the same.
> > > It is inescapable.
> > > 
> > > Scott
> > > 
> > > --- In dstar_digital@yahoogroups.com 
> > > <mailto:dstar_digital%40yahoogroups.com>, "dlake02"  wrote:
> > >  >
> > >  > These disconnected pockets will breed yet another overlay network - 
> > > we have far too many already, IMHO.
> > >  >
> > >  > 73 David - G4ULF
> > 
> > What is definately needed is a complete network, where all are connected 
> > together, some way.
> > 
> > Currently if multiple trust servers are created, they tear down the 
> > common network and create small cells which cannot talk to each other. 
> > That's not how it should be, so if you need to design your own trust 
> > servers, do it so that they exchange information with each other if so 
> > configured. D-STAR is not about everybody's own network but a global 
> > network.
> > 
> > Erik OH2LAK
> >
>

[DSTAR_DIGITAL] Re: We will start implementing a new dstar TRUST server in the US.

[dlake02]

Who are "We" please ?

David

--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
>
> We have not decided on the host name yet.
> Details will follow in the next couple of weeks.
> 
> It will be open to testing and experimentation.
> 
> 
> 73
> Scott/KI4LKF
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Hi Jochen

First, you sent me an email asking if I would like to test my software on your 
system several weeks ago - I apologise that I have been so busy, that I haven't 
gotten round to it yet !  

Second.  I have some questions about your X-Trust system:

1) Each user requires a unique /28 IP address, with the subnet zero address 
being used as the first registration point.  In order for one station to 
contact another, they essentially use source-routing between the two /28 IP 
addresses.  Is your system designed to generate unique 10.X.X.X/28 IP addresses 
across both your and any connected Trust Servers ?For example, if I 
register on your system, will it check that the /28 subnet is unique on both 
your system and the K5TIT system before allocating it ? 

2) The Icom system uses a system of snapshot updates.   In other words, the 
full database should only be sent once when the Zone RP registers.  After that, 
only updates are sent to each Zone RP.  That keeps the network bandwidth down.  
In the G2 Test network, this is exactly what I see - stations moving repeaters 
are synchronised within seconds.   Unfortunately, I suspect due to the sheer 
size of the database, the Live G2 system does not do this, and sends full 
databases every few hours.  The database tables are getting very big - the SQL 
processing time can be longer than the time between updates.  On your system, 
do you send full databases or snapshot updates ?

3) The Icom G2 software is able to identify that an IP address has changed - in 
the UK, it is quite normal for the public, routable IP address of an ADSL line 
to change many times a day, usually as the service policy changes (for example, 
there are packages that offer higher throughputs during the night than at busy 
times).  My own public IP changes around 6 times a day.  Can you software cope 
with this ?

4) I am glad that you are in discussions with the K5TIT team - having witnessed 
first-hand the sheer annoyance of being within range of a D-Star repeater on a 
different G2 network, I would hate to see isolated, disconnected pockets of 
coverage.

73  David - G4ULF

--- In dstar_digital@yahoogroups.com, "Jochen Althoff"  wrote:
>
> Hello Group,
>  
> for evryone who like to do some tests or who want's to join the
> trust, please feel free to register with:
> xtrust2.xreflector.net
> This setting for this may be done in the dsipsvd.conf located in
> /opt/products/dstar/dstar_gw/dsipsvd/
> in the line beginning with 
> TRUST_SERVER = 
> The xtrust team will see your registration request and will accept it
> within
> 24h, independent of the system you are using (ICOM or non ICOM).
> All Systems will be supported to strictly follow the idea of hamradio
> and   to
>  meet
>  the
>  demands on
> the german law. Also there are no
> requirements to run 3rd party scripts as a gate for
> 
> acceptance. This
> is to avoid already existing regional
>  concerns
> about giving someone else
> partial control over their gateway system.
> Xtrust2 is the main trust server of a group of 3 independent trust 
> servers which are replicating their data against each other and are 
> fully compatible to the G2 network and any other icom trust server
> running the replication scripts.
> But please be aware, currently there is no data exchange between
> the K5TIT Trust and one of the XTRUSTs established.
> I had a small talk to Jim, N5MIJ, from the K5TIT Team in Friedrichshafen
> at the ham fair to explain him that it is strongly not our intrest to
> divide
> the existing D-Star network into pieces but we saw the needings of
> another trust to fulfill the above mentioned needings. And i also
> explained
> to him that we are intrested to replicate the data with the fellows from
> the K5TIT Trust Team. We agreed that we will have futher conversations
> regarding that issue.
> Again, this all ist not to act against the deserving K5TIT Team. I will
> state
> this clearly to prevent some rumours.
> For more details please refer to:
>   http://www.xreflector.net  or
>  http://www.open-dstar.net/
>  
> On behalf of the XTrust Team,
> Jochen df1vb
>  
>  
>  
>  msgId=8352/stime=1248373896/nc1=1/nc2=2/nc3=3>
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

> There is a certain expectation among D-STAR RF users that if they are
> in range of a D-STAR repeater, that provides gateway services, that
> they should be able to do callsign routing to any other D-STAR RF user
> that is in range of a gateway equipped D-STAR repeater.  This means
> that they all need to be on the same "trust server" in the current
> architecture.  As an RF user, I shouldn't need to find out which trust
> server the local gateway uses (is it on K5TIT/USTRUST or another trust
> server?).  I should simply be able to put the callsign in the UR
> field, along with the proper RPT1 and RPT2 entries, and make my call.


EXACTLY 


David - G4ULF

--- In dstar_digital@yahoogroups.com, John Hays  wrote:
>
> I think the point KE5C and G4ULF are trying to make is this:
>
> There is a certain expectation among D-STAR RF users that if they are
> in range of a D-STAR repeater, that provides gateway services, that
> they should be able to do callsign routing to any other D-STAR RF user
> that is in range of a gateway equipped D-STAR repeater.  This means
> that they all need to be on the same "trust server" in the current
> architecture.  As an RF user, I shouldn't need to find out which trust
> server the local gateway uses (is it on K5TIT/USTRUST or another trust
> server?).  I should simply be able to put the callsign in the UR
> field, along with the proper RPT1 and RPT2 entries, and make my call.
>
> Having other "trust servers" that don't sync with each other, segments
> the D-STAR community into cliques -- most of us do not want that, we
> want a unified D-STAR network.
>
> Personally, I would like to see an improved "trust server" with the
> following changes:
>
> 1. RF users don't need to register to be added to the "routing"
> tables.  The gateway just reports who it hears on the air, and
> requests routing information for those callsigns it does not know.
> 2. Internet connected nodes have a strong authentication (gateways,
> application servers (such as DPLUS and D-EXTRA), reflectors) -- Dongle
> type users would come into the network through an application server,
> rather than direct -- then they would be treated like other D-STAR
> units with callsign routing, etc.
> 3. A confederated trust server architecture so that regional trust
> servers sync database entries so that a gateway or application server
> could ask any trust server for routing information.
> 4. A bridge to the Icom architecture and a new "short hand" capability
> where "G" nodes don't need to be entered in RPT2 if the controller
> sends all traffic to the local gateway.
>
> Until Scott can take the effort to work with K5TIT to get his code
> tested on their test system and have it talk to the USTRUST it will
> not be of interest to most repeater/gateway operators.  G4ULF has gone
> to that effort, so I think we will start saying a lot more homebrew
> repeater/gateways coming on line using his code, once his production
> beta is complete.
>
>
> On Jul 23, 2009, at 11:24 AM, ham44865 wrote:
>
> >
> > There are 4 European ICOM TRUST servers.
> > You would need permission with them to register your
> > home-made "ICOM compatible" G2 Gateway, same thing with the US.
> >
> > I also have instructions on how to create a NEW ICOM
> > TRUST server. They have created their own ICOM TRUST server,
> > just like K5TIT did.
> >
> > They are pretty active witrh their ICOM TRUST server
> > and they allow registration from anyone that wants to learn.
> > I do not believe that they would deny you registration
> > if you asked them.
> > The Europeans TRUST server groups are very friendly.
> >
> > My dstar "ICOM compatible" G2 Gateway KJ4NHF
> > went live with the European TRUST server a couple of weeks ago.
> >
> > Scott/KI4LKF
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> John Hays
> Amateur Radio: K7VE
> j...@...
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Scott

Some comments on your code logic please (all meant in the spirit of
co-operation, NOT criticism):

1) dstar_register_rptr.  You use the call  strcpy(ip, inet_ntoa(ia)); 
However ia has already been set to the IP Address of the Trust Server. 
If this is a registration, the IP address sent in the initial sequence
should be a subnet-zero unique 10.X.X.X address with a /28 mask.

Once the Trust Server has authorized the connection, then the
dstar_ip_check should use the IP address from which it reported - the
Trust Server will use the source IP of the incoming check and place that
against the Zone RP details in the GIP database.  dstar_ip_check
therefore needs to obtain that IP address from the GIP table and use
that once registered.

This is important as the real source IP could be dynamic or NAT-ted.

So, my understanding of the registration sequence is:

  - set date to 01-01-1970 00:00:00.
  - set IP address to unique 10.X.X.X/28
  - send to Trust server

Polling then continues according to what is received in the database
sync.

2) dstar_ip_check.   This should really just be a continuation of the
above code - startup and polling are really the same thing.  Again,
there are a couple of issues that I have.

- The IP address should be whatever the G2 sync is telling you in the
update from the Trust Server.
- The date sent should be the last SYNC date from the G2 update.  This
is VERY important.

I'll explain why the last statement.  In the correct mode of operation,
the G2 system only ever sends a full update ONCE, and that is in
response to the date being set to 01-01-1970 00:00:00 as per your
registration script. Your poll to the G2 Trust system will thereafter
include the DATE of the LAST received update.  By that means, the Trust
server works out what you have missing, and only sends snapshot updates.
As long as you always set the polling date to be that of the last
received incoming update, you will never get a FULL update.

Now, there is one huge caveat to that last paragraph - that is not how
the Live G2 system is behaving currently.   However, that is how the
Test system beahves.

3) dstar_accept_ip_updates.  Your approach here is very similar to mine,
except I'm using SQLite to keep the installed code-base size down.  Two
main comments:

- There is a length field in the incoming update which indicates the
total size of the data.  This is made up of the first four bytes of the
update frame.   Multiply the first by 0x100, the next by 0x1,
the next by 0x100 and then add together, add 0x52 to account for the
44-byte header and the 4-byte size, and you'll get the total expected
string length.  About 3Mbytes on the live G2 system.

- I'm having a real issue processing the SQL anything like fast enough. 
I'm moving to a batched system in SQLite to try to speed things up, but
I notice that you do the same as me which is to effectively stop
accepting incoming calls whils the Postgres database updates.  This may
cause issues on the live network that you don't see on the test due to
the size and frequency of the incoming updates.


Rather than three separate programs, I've created a single g2_sync
process as information from one part is used in the other, but I
understand your logic.

73 David- G4ULF

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Scott

This is the source downloaded today:

dstar_gwy.zipi386   17.5 KiBSun Jul 19 2009 10:44

David

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Scott

Do not twist my words please.

I didn't say that a Trust Server didn't work.

What I said was that whilst Icom have designed the G2 Trust Server to be
able to be run as a devolved system, that piece of code doesn't work. 
You cannot build the Icom system as a cascade of units.

IF the Icom software was able to be run as several replicating units
across the world, we wouldn't be having this conversation !

Now, to make it clear.

No users registered to the German Trust Server will be able to G2 route
to users registered to the World-Wide system run by K5TIT or vice-versa.

Users that wish to use both systems will need to register to both
independently.

That is a severely retrograde step in the world of D-Star, especially at
a time when Icom themselves have spent time and money fixing the issue
of the isolation of the Japanese D-Star network.

David

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Scott

"Software" and "flawless" - two words that simply don't belong together.

I notice in your database structure that you choose not to record the 
start_ipaddr field.

As you have no knowledge of the 10.X.X.X/28 address, how do you add users to 
the trust domain ?

David 

--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
>
> 
> It has changed 10 times since then.   OLD stuff.
> 
> The one I am running now, it is flawless.
> 
> I will post another copy after I define it to run as a 
> Linux service.
> 
> 
> Scott
> 
> --- In dstar_digital@yahoogroups.com, "dlake02"  wrote:
> >
> > Scott
> > 
> > This is the source downloaded today:
> > 
> > dstar_gwy.zipi386   17.5 KiBSun Jul 19 2009 10:44
> > 
> > David
> >
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Scott

In the initial packet, the IP address is set to a 10.X.X.X/28 address.  You 
won't see that in the database, because it is only sent until the Zone RP is 
authorized.  

Once authorized, the IP address used is the one that the Trust Server picks up 
from source IP of the poll.

Also, once registered, each module registers with a 10.X.X.X/28 address so that 
DD traffic can reach it.

David

--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
>
> Registrations for NEW dstar repeaters to an ICOM TRUST
> do not have data like 10.x.x.x
> 
> I checked about 5 NEW repeater registrations to us trust
> and 3 to European trusts.
>  
> No 10.x.x.x anywhere in any registration packet
> for a NEW repeater.
> 
> Scott
> 
> --- In dstar_digital@yahoogroups.com, "dlake02"  wrote:
> >
> > Scott
> > 
> 
> > If this is a registration, the IP address sent in the initial sequence
> > should be a subnet-zero unique 10.X.X.X address with a /28 mask.
> > 
> ...
> ...
> > 
> > 73 David- G4ULF
> >
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

OK - so the truth of the "European" Trust is that it comprises about 8 
repeaters mostly around the heavily populated area of Dortmund and one repeater 
in the US.

So, that excludes the other 26 countries that make up the European Union.

A few weeks ago, I was driving in that area.  I'd been chatting via one of the 
Dutch repeaters to a friend back in the UK, and crossed into Germany (I wanted 
to test my car on the unrestricted Auotbahn)

I found a D-Star repeater, not realising that it was in this unconnected group. 
 I tried to call to my friend, and got an RPT? back.  Then I tried to link to 
one of the D-Plus reflectors - no go.

We simply cannot have disconnected islands like this - all it is going to do is 
to put off D-Star users who will moan like mad about the multiple networks, 
just as I do with Echolink, IRLP, eQSO, etc, etc.

Erik is 100% correct.

David - G4ULF

> > NO, I meant the European TRUST at dstareusers.eu is
> > running as a TRUST server exactly as k5tit does
> > at dstarusers.org or something.
> >
> > They have built a NEW TRUST server.

--- In dstar_digital@yahoogroups.com, "Erik Finskas"  wrote:
>
> --- Original message ---
> > From: ham44865 
> > To: dstar_digital@yahoogroups.com
> > Sent: 24.7.'09,  19:00
> >
> > NO, I meant the European TRUST at dstareusers.eu is
> > running as a TRUST server exactly as k5tit does
> > at dstarusers.org or something.
> >
> > They have built a NEW TRUST server.
> >
> > That is the point.
> >
> > Now others will build more, as every country should have one.
> >
> > That is the point.
> >
> > I dont care which repeater belongs to which trust at this point.
> >
> > We will also build another one in the US and another in Canada.
> >
> > We DO NOT care about routing from EU trust to US trust and back.
> > That is not the point I am trying to explain here
> 
> Who are WE in this aspect? Why do you want to create numerous parallel 
> networks unvisible ro each other? You then fail to understand the whole 
> concept of D-STAR callsign routing.
> 
> > The point is now we know how to create TRUST servers
> > for peoiple to enjoy and repeaters can belong to any
> > TRUST.   Is is not any more one ONLY. You see what I mean.
> >
> > And check this out, A dstar repeater can switch from one
> > TRUST to another TRUST in 5 seconds.  That is the
> > beauty of it.
> >
> > If one goes down, there is another and another and another ...
> 
> Why dont you all join your your forces and start designing a next 
> generation trust system which has multiple instances for redundancy but 
> still acts like one so everybody could use it and enjoy a global D-STAR 
> network..
> 
> Erik OH2LAK
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

There is one problem will Open Source, and that is the possibility that someone 
will change something that breaks things for everyone else. 

The effect there could be to close down all open source development.   

Developing and testing network software is a nightmare, because the effects can 
reach far beyond your domain (I have a particular nightmare of a NetBIOS over 
IPX type 20 packet generated by a very poor piece of code that opened a buffer 
leak in a LAN switch several years ago and knocked out a 5000 user network in 
10 minutes). 

So, there is a careful balance between code that is freely available and code 
that can be modified to break things for other people.

I haven't decided whether I'm going to open-source or just generally release my 
software yet - I haven't done anything like enough testing yet.

It is running on one repeater, has a few bugs, but nothing major.  I will 
release to some Alpha testers first, run it in a very closely monitored state, 
and see how it plays with the live network.

So, I'll be following the standard software lifecycle of dev-test, 
alpha/pre-production, production.

Yes that will slow things down, but hopefully it'll improve code quality in the 
long run.

73  David - G4ULF


--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
>
> No complaints so far.
> He was looking at an old version.
> 
> I dont see anyone else releasing OPEN SOURCE G2 versions,
> so I do my best to release what I have after I test 
> with the ICOM test TRUST server and then run it on the 
> LIVE ICOM TRUST server.
> 
> It is a big project, so it takes time.
> 
> Scott
> 
> --- In dstar_digital@yahoogroups.com, Jay Maynard  wrote:
> >
> > On Fri, Jul 24, 2009 at 04:42:09PM -, ham44865 wrote:
> > > I release a copy every two weeks or so, sometimes
> > > twice during the same day.
> > 
> > Then don't complain when someone comments on a version you haven't releaed
> > yet.
> > 
> > > I made my dstar G2 gateway OPEN SOURCE from the beginning at the above
> > > SourceForge page with a GPL Licence, freely available for download.
> > 
> > Great! As far as I'm concerned, *every* *last* *piece* of software that runs
> > on a D-Star gateway should be at least available as open source. Do you plan
> > to add a piece of software to replace the belligerently closed-source
> > dstarmon?
> > -- 
> > Jay Maynard, K5ZC at K6ZC port Bhttp://www.conmicro.com
> > http://www.k6zc.org  http://www.tronguy.net
> > http://jmaynard.livejournal.com   (Yes, that's me!)
> > http://www.hercules-390.org
> >
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

John

The whole use of the 10.X.X.X addresses seems like a real mess, but in fact, it 
could be put to very good use.

The advantage is that every callsign has a unique address in the system, down 
to a device level.  

A very similar concept exist in the cellular networks - each device has it's 
own identity and that identity moves between cellular zones and networks.  
Whilst callsigns are useful, there is no good routing protocol for callsigns - 
that is what G2 attempts and fails to do today.

Now, host addresses actually are very useful things, and there is no reason why 
these couldn't be used to provide a much more scalable G2 architecture that 
retained it's compatibility with the existing G2 network.  Advertising the 
movement of a /32 address across a small IP network such as the G2 network 
using an IETF standard routing protocol would be very quick.

I'm not going to go into great detail on my thoughts - there are correct forums 
for doing that, and that isn't here.  However, for those that are Cisco IOS 
literate think about this:

 - Three routers, connected via your favourite IGRP (mine is OSPF).
 - DNS with a lookup to G4ULF 10.1.1.1
 - OSPF on both routers with "redistribute connected" configured
 - Create a loopback on R1 for 10.1.1.1/32.  From R3 ping "g4ulf"
 - Delete the loopback on R1 and create on R2 for 10.1.1.1/32.  From R3 ping 
"g4ulf"

Now, pretend the routers are G2 gateways and the loopback is created from the 
"Last Heard" table


David - G4ULF


--- In dstar_digital@yahoogroups.com, John Hays  wrote:
>
> 
> On Jul 24, 2009, at 12:33 PM, dlake02 wrote:
> 
> > Scott
> >
> > In the initial packet, the IP address is set to a 10.X.X.X/28  
> > address. You won't see that in the database, because it is only sent  
> > until the Zone RP is authorized.
> >
> > Once authorized, the IP address used is the one that the Trust  
> > Server picks up from source IP of the poll.
> >
> > Also, once registered, each module registers with a 10.X.X.X/28  
> > address so that DD traffic can reach it.
> >
> > David
> >
> >
> > .
> >
> > 
> 
> 
> David,
> 
> Its great that you are willing to freely share your knowledge of how  
> G2 works - I can't wait until your beta is over and you release code  
> for us to try and source to study. (My Friendcoms arrived today for my  
> desktop test platform.)  I'm still wondering if you have also found a  
> way to have your gateway code talk to the RP2C or is it only for home  
> brew GMSK modem/node adapter controlled repeaters?
> 
> Architecturally, I find the whole 10.x.x.x dependency a little off- 
> putting.  Even for DD, the routing should be by callsign (look at the  
> DD packet format, it has nothing to do with TCP/IP, its about  
> encapsulating Ethernet packets inside of D-STAR packets).  Maybe next  
> generation trust/gateway architecture can eliminate this dependency?
> 
> I think the gateway architecture should be  Internet encapsulates D- 
> STAR packets treating both DD and DV the same.  All the trust would  
> need is to map which callsigns need routed to which gateway and let  
> the gateway handle it from there.
> 
> 
> John Hays
> Amateur Radio: K7VE
> j...@...
>

[DSTAR_DIGITAL] Re: First contact with home-made G2 dstar gateway to ICOM's dstar gwy

[dlake02]

Scott

Sorry to bust your bubble, but I did this over 2 weeks ago now on the real G2 
system, not the German one that house a handful of repeaters.

As I am fed up with you not listening to what people are saying, may I just 
repeat for the last time:

There is NO "European" Trust Server.  Please will you stop talking about 
pan-European service that does not exist.

Any attempt to break the G2 network up and isolate it into pockets is foolish 
in the extreme, and will hurt the reputation of D-Star.

If the telephone network or the Internet had been built in the way that you 
seem to be championing, we'd have had no communication between users on 
different networks.

David
--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
>
> We did it, folks.
> 
> First contract from my home-made dstar G2 gateway to
> an ICOM's dstar gateway/repeater.
> 
> dstar routing worked with URCALL=...the remote calllsign ...
> 
> This is amazing.
> Now I have to automate the software to run as a Linux service.
> 
> I want to congratulate the EU TRUST server group for
> testing with me. Thanks a million folks.
> I will release it as OPEN SOURCE at:
> 
>  http://dstardextra.sourceforge.net/
> 
> If you do not know you are doing, do NOT change the
> source code, the only thing that could be changed
> is the config file to put your own dstar repeater callsign
> and the ADMIN callsign(s).
> 
> Scott
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

John

Yes, but my thoughts are why use a relational database to do the job of a 
Routing Protocol ?

Something like ISIS or OSPF is easily able to cope with the number of repeaters 
and stations we have.  And having the Private IP Address space is actually 
pretty good as we can keep it to an IP VPN.

I'd only be making a look-up between the callsign and an IP address. The actual 
payload be-it UDP or TCP is pretty irrelevant; you just need to know how to get 
from A to B which today is source-routed on G2.

DNS is scalable to the extent that we need as well (probably 4 servers 
worldwide), plus the local machine could be a caching nameserver taking strain 
off the central ones (which wouldn't actually be a strain at all given the low 
numbers even if every Amateur in the world had D-Star).

I know of similar SQL-based routing systems that struggle to survive at the 
10,000+ user level (I'll let you guess...) but IP routing at that sort of 
figure is a walk-in-the-park.

If it was done properly, we could even get G2 callsign routing on DV-Dongles.

I'm going to put some ideas forward to the Trust Server team and see what they 
think, but there certainly is a lot of scope for getting some real 
experimentation back into Amateur Radio.  That alone is a very good thing in 
these days of black-box radios IMHO.

73  David - G4ULF


--- In dstar_digital@yahoogroups.com, John Hays  wrote:
>
> David,
> 
> I'm only Cisco IOS literate with a manual in hand :) but I see the  
> appeal of the reuse of IP protocols.  I just think it confuses the  
> issue in D-STAR
> 
> I feel the callsign (including the 8th character designator) in the D- 
> STAR protocol is unique enough for endpoint determination.
> 
> The routing is pretty simple in my "simple" mind.
> 
> Gateway receives a D-STAR header.
>   If it knows the destination (URCALL) already (say its on a locally  
> attached repeater or at a cached gateway location), it sends it to the  
> destination.
>   If it doesn't know the destination it asks the "trust server" where  
> to deliver it (probably the IP of the gateway to last report seeing  
> the callsign)
>   If it can't find the destination, it sends a service message back to  
> the origin callsign that the destination callsign is unknown.
> 
>   The gateway also looks at the source (MYCALL)
>   If it is already cached as being on an attached repeater, do 
> nothing
>   If it is from an attached repeater and either doesn't exist or 
> is  
> marked being on another gateway, update the trust that the callsign is  
> now on this gateway
>   If it is from a remote gateway, update local cache to associate 
> the  
> callsign with the remote gateway
> 
>   Of course there is more code to it than that, to handle routing  
> loops, timeouts, etc., but I think it pretty much handles  
> "connectionless" D-STAR traffic.
> 
> For DD, this means you can run any Ethernet encapsulated protocol  
> between endpoints, not just TCP/IP.  You can also use the address  
> space that makes sense,  e.g. 10.x.x.x, 44.x.x.x, 192.168.x.x,  
> 172.x.x.x, or x.x.x.x in the IP world.
> 
> John
> 
> On Jul 24, 2009, at 1:40 PM, dlake02 wrote:
> 
> > John
> >
> > The whole use of the 10.X.X.X addresses seems like a real mess, but  
> > in fact, it could be put to very good use.
> >
> > The advantage is that every callsign has a unique address in the  
> > system, down to a device level.
> >
> > A very similar concept exist in the cellular networks - each device  
> > has it's own identity and that identity moves between cellular zones  
> > and networks. Whilst callsigns are useful, there is no good routing  
> > protocol for callsigns - that is what G2 attempts and fails to do  
> > today.
> >
> > Now, host addresses actually are very useful things, and there is no  
> > reason why these couldn't be used to provide a much more scalable G2  
> > architecture that retained it's compatibility with the existing G2  
> > network. Advertising the movement of a /32 address across a small IP  
> > network such as the G2 network using an IETF standard routing  
> > protocol would be very quick.
> >
> > I'm not going to go into great detail on my thoughts - there are  
> > correct forums for doing that, and that isn't here. However, for  
> > those that are Cisco IOS literate think about this:
> >
> > - Three routers, connected via your favourite IGRP (mine is OSPF).
> > - DNS with a lookup to G4ULF 10.1.1.1
> > - OSPF on both routers with "redistribute connected" configured
> > - Create a loopback on R1 for 10.1.1.1/32. From R3 ping "g4ulf"
> > - Delete the loopback on R1 and create on R2 for 10.1.1.1/32. From  
> > R3 ping "g4ulf"
> >
> > Now, pretend the routers are G2 gateways and the loopback is created  
> > from the "Last Heard" table
> >
> > David - G4ULF
> >
> >
> >
> > 
> 
> John Hays
> Amateur Radio: K7VE
> j...@...
>

[DSTAR_DIGITAL] Linux G2-Compatible Software

[dlake02]

Hello All

I've had several emails over the weekend asking very similar questions on my 
software, so I'm going to make some comments and observations here.

Why ?  Quite simple - I already have a very busy day (and evening) job, and the 
time I have to reply/work on the code is very limited.

1) What is the build that I'm aiming for ?

- The aim of my project was very simple - to be able to put a 70cm D-Star 
repeater on air that did not use any Icom "moving parts."  As 2m is pretty-much 
full in the UK, and 23cm not available, this is primarily a single-band system 
on 70cm.  The group of which I am a member already operates a 70cm IRLP node, 
GB3MH, and we have site clearance for GB7MH.  

- Build-wise, I am using the first-generation Satoshi Node Adapter, the latest 
v4 firmware and a fanless Mini ITX system running CentOS 4.6 from a 4GB CF 
card.   I haven't had time to look at the Satoshi v5 system or the Radio Modem 
from Fred van Kempen - work has just been too busy.

- The radio is a Tait T800 tuned by someone that knows far more about radios 
that I ever will.

2) Do you support D-Plus, D-Star Monitor, D-anything-else.

- My software replaces the RPC2 and the Gateway.  However, it does "echo" the 
RPC2->Gateway frames, so any other code package that currently runs on a real 
G2 gateway and listens for those frames (e.g. Robin Cutshaw's D-Plus package or 
Pete Lovealls D-Star Monitor package) will run exactly as if it were on an Icom 
G2 system.

- In theory, I could write the other half of the protocol to fully emulate the 
Gateway->RPC2 frames.  I have descriptions for most of those.  But I don't 
(currently) have an RPC2 that I could play with.  It is a thought, and I do 
have some very interesting offers.

3) Do you support Callsign Routing/G2 Synchronisation ?

- Yes.  I sync to the world-wide Trust Server kindly run by the K5TIT team for 
the benefit of all Amateurs.  The whole point of the project was as a total 
replacement for an Icom G2 stack.  I see the inclusion of G2 registration and 
callsign routing as a fundamental part of the project.

- There is one exception - multicast routing.  I can route to other systems on 
Slash routing, but I don't have any mechanics to build local multicast groups.  
Yet..

- User registration is also vital.  I use the same logic as the G2 system does 
to register the first IP address on the G2 system.  I don't currently have the 
ability to add additional suffixes within the subnet zero block.  Users go to 
an HTTPS page to register; the admin then validates them and they are included 
in the G2 sync.

4) Why isn't this code available yet ?

- I'm a Network Engineer by profession, and I've seen far too many applications 
thrown together quickly without sufficient testing on pre-production systems or 
in limited Beta/Alphas.  There are also two concerns:  1) If I release 
something that is broken, I will spend what little time I have left supporting 
it.   2) If I release something that breaks the network for everyone else, I 
will be in a lot of trouble and could close development for everyone else.   

- As soon as I have GB7MH on-air, then I will quickly know just where the flaws 
in the code are - and there are bound to be some.  However, GB7MH is a group 
project and others are working very hard to ready the site for installation.  
Getting Internet Access to the bell tower of a church in rural south-east 
England is not easy.  

- My initial thoughts are to release the system to other repeater groups.  It 
isn't designed to be a D-Star hot-spot and it isn't designed to link analogue 
and digital modes.  If groups wish to clone my build, then I see no reason why 
they couldn't be part of my Alpha/Beta trials.  Of course, all donations to the 
installation and upkeep of GB7MH would be gratefully received.

- Open Source ?   I don't know  Here's my concern.  I know how this works, 
where the flaws are, what breaks.  If someone took my code, modified it and 
brought the whole of the G2 network crashing down (yes, it IS possible to do 
that from one ZoneRP), then I would ultimately be morally responsible.  I don't 
want to put myself in that position.

5) Where next ?

- My focus is in code stability, co-existence with the G2 network and in 
delivering GB7MH.   Any future direction will depend on those.


If you have emailed me direct, I WILL respond, but it can sometimes take me 
many days if not weeks to respond.  

73 - David G4ULF

[DSTAR_DIGITAL] Re: Anyone knows why ...

[dlake02]

Scott

I think I explained this already.

It can take a VERY long time to receive the database sync from the Trust 
Server.  In some instances, up to 2 hours after requesting it.

What you are seeing is pretty quick - but I would expect that as you are on a 
very small system.

David

--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
>
> 
>   ...a dstar repeater/gwy local dstar database
> takes 2 minutes to receive the IP repeater updates
> and the radio user updates from the TRUST server.
> 
> My home-made G2 dstar repeater/gateway receives updates from 
> the TRUST two minutes after another repeater sent its
> update to the TRUST.
> 
> Is that normal? 2 minutes, actually 1 minute and 40 seconds.
> 
> Scott
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Hi John

Understood, but the best form of hashtable for routing is the Forwarding 
Information Base on an IP router.

I was just trying to maintain as much compatibility with the current G2 
architecture as possible whilst providing a scalable backbone.

But, I do understand what you mean about a double look-up of 
callsign/IP-address.  

And I think we agree on one thing - the way it is done at the moment causes 
more problems than it solves.

73 David - G4ULF

--- In dstar_digital@yahoogroups.com, John Hays  wrote:
>
> Hi David (and Stewart),
> 
> On Jul 27, 2009, at 1:30 PM, Stewart Bryant wrote:
> 
> > dlake02 wrote:
> > >
> > >
> > > John
> > >
> > > Yes, but my thoughts are why use a relational database to do the  
> > job of
> > > a Routing Protocol ?
> > >
> >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Let me clarify.  I could be wrong, but don't think I ever mentioned a  
> relational database in my discussion.  I use the term "hashtable" in  
> the generic sense, which on a gateway or application server would  
> probably be a memory resident data structure with no database at all.
> 
> If you look at the D-STAR air protocol, there is nothing related to IP  
> involved.  Even in DD the D-STAR frame encapsulates an Ethernet  
> packet, which may or may not include a IP packet and certainly there  
> is no need for a DV user to need an IP address.  IP really only comes  
> into play as an encapsulating transport layer for native D-STAR frames  
> over the Internet.  If we keep out design dependencies that violate  
> the protocol layers for expediency, then the transport can be replaced.
> 
> The gateway really should keep references to map a callsign address to  
> the gateway or application server address that is servicing that  
> callsign at that instant in time.  There really isn't even a need for  
> every gateway to know the current callsign to gateway or application  
> server mapping, it really only needs to keep a cache of active  
> references. The equivalent of a trust server would offer the  
> equivalent of a Dynamic DNS service that would allow unknown mappings  
> to be discovered in real time.
> 
> Think of it this way
> 
> [ Internet Packet for Gateway to Gateway Routing/Transport |
>   D-STAR Frame with SRC (MY)/DST(UR) Callsigns |
>   DD Payload of Ethernet packet |
>   IP or other network protocol (address space determined 
> by  
> participants; Net 10, Net 44, Net 192.168.0-255, Net 172.16-31, Net  
> 169.254, or any other space, or even use other Ethernet protocols like  
> IPX/SPX, Ethertalk, XNS, whatever) |
>   End of DD |
>   End of D-STAR Frame |
> End of Internet Packet ]
> 
> All nicely encapsulated (easier to do with pictures). Then you could  
> switch to ATM encapsulation rather than straight IP, or send it via  
> Frame Relay, X.25 or even AX.25 without dependency on an artificial IP  
> mapping for callsigns that is unnecessary.  DV could travel the same  
> path, just substituting the DV Payload for the DD payload.
> 
> The code for the D-STAR portion isn't that complex, the gateways and  
> application servers don't even need a callsign (the whole G port  
> anomaly is strange to me -- just send everything to the gateway and  
> let it decide if a given frame needs relayed - you, David, probably  
> had to simulate it in your code to look like an Icom controller based  
> solution, but upon reflection I think you would find it unnecessary  
> and superfluous in your repeater).  Traditional IP networking can be  
> used to keep the gateways and application servers properly addressed  
> (maybe even within a VPN), but users don't need to know about routing.
> 
> John Hays
> Amateur Radio: K7VE
> j...@...
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

The DNS is only to find the reference between the callsign and the IP address.  
 Entries would only be added once stations are authorised, so any delay would 
not affect the live routing.

IP Routing would take care of station moves, not DNS.

Every repeater would look-up the callsign-to-IP address, and then simply IP 
route to destination.

I completely agree that DNS is inappropriate for instantaneous moves.  

73 David - G4ULF


--- In dstar_digital@yahoogroups.com, "Woodrick, Ed"  wrote:
>
> 
> Don't believe that DNS updates are instantaneous. In common configuration, IP 
> address changes can easily take 6 hours.
> 
> And if you pull the TTLs down to something short, you start to bang the heck 
> out of the centralized name servers. Whoops, let me say the one centralized 
> name server, because zone replication timeframes will also add a lot of delay.
> 
> Ed WA4YIH
> 
> From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com] On 
> Behalf Of Stewart Bryant
> Sent: Monday, July 27, 2009 4:31 PM
> To: dstar_digital@yahoogroups.com
> Subject: Re: [DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live 
> today.
> 
> 
> 
> dlake02 wrote:
> 
> I completely agree with you David. This is an IP networking
> problem easily solved by a mixture of DNS and IP routing.
> We do not even need to worry about IP mobility, at the mobility
> rates we are talking here regular convergence would work.
> 
> I would partition the network into a mixture of IGP and BGP
> just like the Internet. That allows you full scaling and
> the ability to apply policy between the ASs.
> 
> Callsign migration time would be limited by the b/w of the
> links used, but I would be disappointed if it were
> over a second within an IGP.
> 
> I originally thought that this would need routing protocol
> enhancements, but on thinking about it, from a
> network perspective it would work right out of the box.
> 
> Stewart/G3YSX
>

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[dlake02]

Hi Nate

No offense taken !  I don't know DNS in the kind of detail required.  My 
concern is the amount of network traffic DNS could take compared to that used 
on a properly configured IP routing protocol.  Again, I know the latter well - 
not the former.

Your comment on the 10.X.X.X range is interesting - whilst I would gladly sweep 
that away in an instance, I am concerned that there is a use that may break.  
Does anyone know what was in Icom's mind when they used that range ?

73  David

--- In dstar_digital@yahoogroups.com, Nate Duehr  wrote:
>
> 
> On Jul 28, 2009, at 1:51 AM, dlake02 wrote:
> 
> > I completely agree that DNS is inappropriate for instantaneous moves.
> >
> > 73 David - G4ULF
> >
> No offense intended David, but anyone who says this hasn't done it.   
> DNS can EASILY handle virtually instantaneous updates, when configured  
> and used correctly.  It is NOT used correctly (like many of the  
> technologies in the Icom Gateway) and the attempt makes the DNS  
> implementation look foolish... similar to the decision to build Apache/ 
> Tomcat from *source* makes the use of those technologies look goofy.   
> No one building any other Apache/Tomcat application in the world  
> intended for a "network appliance" writes and releases csh scripts  
> (ugh) to build the things from source to use them on a common Linux  
> platform like CentOS...
> 
> The whole implementation seems like an overgrown college kid's demo to  
> me, having been involved in multiple commercial Linux projects.  Very  
> very odd.
> 
> Nevertheless I digress.
> 
> As you pointed out, DNS is not needed for anything other than IP  
> mapping, which seems useless right now, but seems to point to a plan  
> (maybe shelved?) to allow routed IP connectivity between the private  
> 10.x.x.x range between ID-1 rigs.  It looks to me like that "vision"  
> was there, but never implemented.
> 
> --
> Nate Duehr, WY0X
> n...@...
>

[DSTAR_DIGITAL] Re: Finally, an Open G2 that runs on ICOM repeater-controller hardware.

[dlake02]

Scott 

"European G2 TRUST server at: xtrust2.xreflector.net"

There is no European Trust Server.

There are a group of German D-Star users that have declared UDI from the 
one-and-only worldwide G2 Trust Server and hence partitioned the network.

As people have been working hard to fix the routing between the Japanese and 
non-Japanese networks, it is my belief that it is unhelpful for any individual 
to promote further partition of the worldwide D-Star network.

I am not a self-publicist - I have been working quietly and privately on a 
non-Icom repeater linked to the G2 network that will allow repeater groups to 
save thousands of pounds/dollars and join the K5TIT-run network.   Two 
repeaters are now successfully running this solution - users are unaware that 
they are operating on a non-Icom system and have full access to callsign 
routing and reflector linking.

Will I open-source it ?  Probably not.  Why ?  Because the D-Star network is so 
fragile, that if someone changes something in my code that breaks the network, 
I will get the blame, and that will pull any chance of future development.

But, anyone can have a signed binary to run on their Linux system.  486, 512M 
RAM works fine.  You just need a Satoshi board and a decent radio system with 
two-point modulation on TX.

People know how to get hold of me.

David - G4ULF


--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
>
>   We finally did it folks.
> 
> We now have an Open G2 written in C that communicates
> correctly with the ICOM repeater controller hardware.
> 
> The handshake protocol between the ICOM G2 and the
> ICOM repeater controller hardware was a little tricky
> to figure out at first.
> 
> In summary, we have accomplished the following:
> 
> Open G2 "dstar_g2_gwy" software written in C replaces ICOM dsgwd G2.
> Open "dstar_g2_sync" written in C replaces the ICOM dsipsvd.
> 
> At first, the ICOM repeater controller was not talking 
> to our Open G2 "dstar_g2_gwy".
> Once we figured the handshake protocol, it was rather easy.
> 
> Since the Open G2 "dstar_g2_gwy" can also run on
> the GMSK RF modem/node, we have an option in dstar_g2_gwy.cfg
> to allow the Gateway owner to run the Open G2 without
> any ICOM hardware, but just a GMSK RF modem/node.(DV node thingy)
> 
> All types of DV packets go thru.
> What has to be done next:
> 
> a)
>Cross-banding features.
> 
> b)
>High-Speed Digital Data(DD) processing.
> 
> 
> Currently, Digital Voice(DV)
>  on 2m, 70cm and 1.2 GHz bands are handled.
> Modules C, B and A.
> 
> We'd like to thank the D STAR Gateway/repeater owners that
> participated in the tests. 
> Thanks a million.
> 
> 73
> The D_STAR_Open_Source group
> http://groups.yahoo.com/group/D_STAR_Open_Source
>

[DSTAR_DIGITAL] Re: Finally, an Open G2 that runs on ICOM repeater-controller hardware.

[dlake02]

Ah - that would be much like the terse response I got to ask to join the rtpDir 
group then ?  

I was told that my access attempt was being logged, and I would be reported to 
the FBI...


--- In dstar_digital@yahoogroups.com, Tony Langdon  wrote:
>
> At 03:22 AM 10/5/2009, you wrote:
> 
> >2. Who controls it?
> >"The D_STAR_Open_Source_group"
> 
> I would also be asking about the guarantee of access to the 
> download/support forum as well, without arbitrary decisions about who 
> can enter the support forum.
> 
> 
> >3. What license is it released under?
> >"The D_STAR_Open_Source_group"
> 
> And here, I'd like to see the legalese.
> 
> 73 de VK3JED / VK3IRL
> http://vkradio.com
>

[DSTAR_DIGITAL] Re: callsign routing

[dlake02]

Not quite true.

If you have a small number of synced gateways talking to a Trust Server (which 
is actually the standard gateway software running in a Trust Server mode), when 
a station moves repeaters, the update is virtually instantaneous across all 
repeaters.

In fact, after the initial database push, all you ever see are updates.  

However, if there are repeaters that are out-of-sync (determined by the UTC 
time-stamp on the database updates), then the Trust Server appears to fall-back 
to a periodic update, and that period is set by the time it takes to get round 
each repeater with the database update.

So the issue is that the database update mechanism is not robust enough to cope 
with the fact that some repeaters may be uncontactable.  This creates the 
current issues - 4 months ago, the interval between database updates was about 
51 minutes.  Today, I've counted at 1 hour.  And it's the full database every 
time.

73 David - G4ULF
--- In dstar_digital@yahoogroups.com, "Woodrick, Ed"  wrote:
>
> AFAIK, the ONLY updating that occurs is to the Trust Server and then 
> replicated out. So one repeater will not update another repeater system.
> 
> The only exception, with the latest gateway software, is that if you move 
> between modules on the same system, the local system will redirect the call 
> to the module that you are on.
> 
> Ed WA4YIH
> 
> 
> From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com] On 
> Behalf Of Dave Cooley
> Sent: Friday, October 16, 2009 7:50 AM
> To: dstar_digital@yahoogroups.com
> Subject: [DSTAR_DIGITAL] Re: callsign routing
> 
> 
> 
> Tony and John ,
> 
> I agree fully.
> 
> And yes it is best to announce how you are coming in.
> 
> */Here is a question for the Gateway Experts:/*
> 
> On the issue of Update Latency;
> 
> When a user call sign routes into a repeater does that repeater update
> 
> the users table with their current information?
> 
> Example: Lets say I have been on W1AW and now switch to W2AW. I make a
> 
> (call sign route) call to N2LZ who is on W3AW . Will W3AW update my
> 
> location information immediately with my new location (W2AW) or does it
> 
> have to wait until the trust server update? If it would update from the
> 
> traffic information, the mobile user could just make a callsign routed
> 
> call back to their home repeater (or in Frans case, his sons home
> 
> repeater), and this would immediately update their location on that
> 
> repeater. I realize this doesn't correct the problem of update latency,
> 
> but I think in many situations would provide an acceptable work around
> 
> as most users only communicate with one or two repeaters on a regular basis.
> 
> Food For Thought!
> Dave Cooley
> Brandon, Fl.
>

[DSTAR_DIGITAL] Re: Beeps

[dlake02]

There are other reasons why the radio may generate a "beep."

The main one is loss of bit-sync.

Every 21st frame has 0x55 0x2d 0x16 at the end - if you generate these at 20 or 
22 frame intervals, sure enough, you get a beep.

If you miss several, you get a beep.

So, under weak conditions, you can hear more beeps as the radio struggles to 
re-sync the bit-stream.

Spoken from coding experience of someone who has spent the last 12 months 
counting in 12 bytes x 21 frames :-)

David

--- In dstar_digital@yahoogroups.com, "Neil"  wrote:
>
> The beeps are generated (by the radio) when it 'thinks' the signal being 
> recieved has finished, like a 'clear to send' request.  Due to our really 
> patchy coverage here in the UK, I experience many 'beeps' from the repeaters 
> stream, while it drops in and out of range, it has nothing to do with what 
> you are listening to, so same with simplex.
> 
> Neil.
> - Original Message - 
> From: "Nate Duehr" 
> To: "Justin G0KSC" 
> Cc: 
> Sent: Wednesday, October 14, 2009 3:15 PM
> Subject: Re: [DSTAR_DIGITAL] Beeps
> 
> 
> Technically this is also true.  The beeps are just an indication that
> signal has dropped, and a configurable feature on some of the rigs to
> turn it off or change its volume level from the speaker.
> 
> The information shown on the SCREEN however, is the actual
> "notification" about what the system thinks is going on.
> 
> 
> On Oct 14, 2009, at 8:00 AM, Justin G0KSC wrote:
> 
> >
> > I think you will find the bleeps are from your radio. The receiver
> > bleeps to notify you a DV signal has dropped, not the repeater. Try
> > a simplex QSO, this will confirm this for you.
> >
> >
> > - Original Message -
> > From: Robbie De Lise
> > To: dstar_digital@yahoogroups.com
> > Sent: Wednesday, October 14, 2009 2:52 PM
> > Subject: Re: [DSTAR_DIGITAL] Beeps
> >
> >
> > As I experience it i think something like this:
> >
> > No beep: The repeater did not confirm your TX, prolly no RX on the
> > repeater side
> > 1st beep: The repeater (CALL A, B or C) confirms your TX
> > 2nd beep: The gateway (CALL G) confirms your TX.
> >
> > Ofcourse, when someone pushes the PTT right after the BEEP or before
> > the BEEP,
> > the repeater does not have the time to send the confirmation out.
> > (The confirmations are send seperately from the DV transmission)
> >
> > so:
> >
> > DV TX
> > stop TX
> > Confirm Repeater TX (BEEP)
> > stop TX
> > Confirm Gateway TX (BEEP)
> > stop TX
> >
> > if someone pushes the mike faster its like:
> >
> > DV TX
> > stop TX
> > Confirm Repeater TX (BEEP)
> > stop TX
> > DV TX
> > stop TX
> > Confirm Repeater TX (BEEP)
> > stop TX
> > Confirm Gateway TX (BEEP)
> > stop TX
> >
> > or even:
> >
> > DV TX
> > stop TX
> > DV TX
> > stop TX
> > Confirm Repeater TX (BEEP)
> > stop TX
> > Confirm Gateway TX (BEEP)
> > stop TX
> >
> >
> >
> > I could also be completely wrong :)
> >
> > Let me know if someone else has the same experience.
> >
> > 73s
> > Robbie
> >
> > On Wed, Oct 14, 2009 at 3:42 PM, Fran Miele 
> > wrote:
> >
> >
> > Several of the users on our system have been discussing the beeps
> > heard on a repeater and it is clear we really don't understand them.
> >
> >
> > I'm sure this has been asked many times before but I can't seem to
> > find a definite answer. Can someone explain the beeps that are heard
> > at the end of a transmission on a repeater? Sometimes there are two,
> > sometimes one and sometimes none.
> >
> >
> > What do they mean, and why the variation?
> >
> >
> > Thanks in advance,
> >
> >
> > Fran, W1FJM
> >
> >
> >
> >
> >
> >
> >
> >
> 
> Nate Duehr
> n...@...
> 
> facebook.com/denverpilot
> twitter.com/denverpilot
> 
> 
> 
> 
> 
> Please TRIM your replies or set your email program not to include the 
> original  message in reply unless needed for clarity.  ThanksYahoo! Groups 
> Links
>

[DSTAR_DIGITAL] Re: MB6AM: UK's First G2 Connected Simplex D-Star Node

[dlake02]

Comments 

73 G4ULF
--- In dstar_digital@yahoogroups.com, "Barry"  wrote:
>
>
> Darren wrote:
>
> > To access MB6AM, users should configure their radios in simplex mode
on
> > 144.8625 MHz, with no RPT settings required. If RPT settings are
used, then
> > the following settings must be programmed:
> >
> > YOUR: CQCQCQ
> > RPT1: MB6AM^^C  (^ = space)
> > RPT2: MB6AM^^G
> > Duplex Offset: +/- 0 MHz
> >
> > D-Star users can make use of all the usual dplus and G2 routing
commands, so
> > they can link to other nodes or call directly around the D-Star
network.
>
> Well done to all involved, this will definately help improve coverage
to the area, and given time, hopefully many more.
>
> Just a couple of questions, if the users do not put in the RPT
settings in, does the software automatically just take the stations
callsign and route them on whatever MB6AM is connected to?

  It depends.  In Simplex mode (i.e. where there is no "Dup" on
the screen) then the radio will always send RPT 1 and RPT 2 as "DIRECT"
no matter what you program.  I check the flag and set RPT 1 to the port
and RPT 2 to the gateway in both the header and the embedded callsign
string.

In Duplex mode, flag 1 will be ox4X, so I read the RPT1 and RPT2 streams
from the header.  They have to match the configuration of the box.


>
> And, does the 'DUP' flag need to be put in (with a zero split)?
>

 No - see above ! 

> As the node can only go elsewhere (not local) I'm guessing its always
in RPT2 'G' mode all the time regardless.
> Would it be possible to just use the 'YOUR' commands alone?

 Not quite sure what you mean here.  "YOUR" is the destination
callsign identification.  As D-Plus is running on the system, then any
linking/unlinking commands that are passed via the "YOUR" setting make
it to the G2 outbound stream, so anything sniffing this could act on it
(such as D-Plus, DSM, etc).


>
> Regards,
>
> Neil.
> G7EBY.
>

[DSTAR_DIGITAL] Re: New guy

[dlake02]

Nice idea, but unworkable in D-Star due to the fact that it's a single carrier 
system.

If you take a real trunked system like MPT1327, trunked P25 or TETRA, then 
there multiple carriers per site (or timeslots in the case of TETRA) to allow 
multiple calls. 

In D-Star, there can only be one session at a time per repeater.

You would need some contention system to handle multiple users.

For example, if the repeater you appeared on was linked to D-Plus, would you 
unlink it ?  When  would you re-link ?  What if a QSO was in progress ?  

Don't get me wrong - I like the idea.  But D-Star uses the wrong radio access 
method to make it work.

David

--- In dstar_digital@yahoogroups.com, John Hays  wrote:
>
> 
> On Jan 22, 2010, at 3:28 PM, Nate Duehr wrote:
> 
> > On 1/22/2010 4:03 PM, Neil wrote:
> >
> >>
> >>
> >> Wouldn't it be nice if say, a group of people around the country  
> >> (or world even), could put a special call in the UR field and  
> >> everyone in that group would have their traffic automatically  
> >> routed to all the other members, bit like a multicast I suppose,  
> >> but not much fun if the local repeater was already in use.
> >> (That's where G3 'could' come in handy, sending a message instead  
> >> to the members radio on that repeater, underneath the QSO without  
> >> hindering the other users...then you could switch to another  
> >> repeater/node and continue.)
> >>
> >> I suppose you could subscribe to a 'multicast group', something  
> >> like a reflector that handles instantaneous multiple connections.
> >>
> >> Food for thought...
> >>
> >> 73 de Neil G7EBY
> >
> > The commercial digital world calls this "talk groups" and has had it  
> > for at least a decade.
> >
> > An Amateur talk group system would need to come up with a way to  
> > "self-register" with a particular talk group.
> >
> > Could be done.  Interesting concept.
> >
> > Nate WY0X
> >
> > 
> 
> 
> Once we have an open source gateway, its pretty easy.  My  
> understanding is that the RP2C sends any transmission with something  
> in RPT2 to the gateway (doesn't have to just be "call   G" --- there  
> are a couple of syntax that could be used.
> 
> UR: TG0R  (Register)
> MY: K7VE
> RPT1: NW7DR (Module number isn't required by the protocol, but may be  
> required for RP2C)
> RPT2: GATEWAY
> 
> With UR:TG0U (UnRegister)
> 
> The gateway would have a list of active talkgroups and register itself  
> to the talkgroup server (like a reflector) for two way transmission  
> relay -- no need for a "link"
> 
> Another syntax:
> 
> UR:   (usually CQCQCQ  or ---U to Unregister)
> MY: K7VE
> RPT1: NW7DR
> RPT2: TG0  (Gateway will register for talkgroup if not already  
> registered, keep a list of local callsigns in the group and unregister  
> when the last sends the unregister or times out)
> 
> Arbitration of multiple talk groups on a single repeater frequency is  
> the main downside.
> 
> 
> 
> 
> John D. Hays
> Amateur Radio Station K7VE
> PO Box 1223
> Edmonds, WA 98020-1223 VOIP/SIP: j...@...
>   Email: j...@...
>