DMRlink test master and...
If you point a peer at the test master, please us a repeater id that matches one of your AllStar nodes. That way I can see where the traffic is coming from. On another note, there is a bug in the mk_dmrlink script. It does not copy the sample playback configuration file into the playback directory. from the root prompt: cd /opt/dmrlink/playback cp ../samples/playback_config_SAMPLE.py playback_config.py -- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
On the DMRlink config or the repeater? or both? On Tue, Dec 15, 2015 at 8:33 AM, Steve Zingman <szingman@msgstor.com> wrote:
If you point a peer at the test master, please us a repeater id that matches one of your AllStar nodes. That way I can see where the traffic is coming from.
On another note, there is a bug in the mk_dmrlink script. It does not copy the sample playback configuration file into the playback directory. from the root prompt: cd /opt/dmrlink/playback cp ../samples/playback_config_SAMPLE.py playback_config.py
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
Whatever you point at the test master. We need to figure out a scheme. On 12/15/2015 11:41 AM, Michael Hebert wrote:
On the DMRlink config or the repeater? or both?
On Tue, Dec 15, 2015 at 8:33 AM, Steve Zingman <szingman@msgstor.com <mailto:szingman@msgstor.com>> wrote:
If you point a peer at the test master, please us a repeater id that matches one of your AllStar nodes. That way I can see where the traffic is coming from.
On another note, there is a bug in the mk_dmrlink script. It does not copy the sample playback configuration file into the playback directory. from the root prompt: cd /opt/dmrlink/playback cp ../samples/playback_config_SAMPLE.py playback_config.py
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org <mailto:Allstar-Digital@lists.keekles.org> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
Understand, bridge.py is a Proxy. What the master sees is ONLY what you point at it. Consider you have a bridge configured as a peer with the id 12345 pointing at the test master. the other IPSC network defined in dmrlink.cfg is a master as 54321. 12345 is bridged with 54321. You have a repeater defined as a peer with a ID of 98765. You have a second repeater defined as a peer with a ID of 56789. The test master will think all the traffic is coming from 12345. Clear as mud? Steve On 12/15/2015 11:41 AM, Michael Hebert wrote:
On the DMRlink config or the repeater? or both?
On Tue, Dec 15, 2015 at 8:33 AM, Steve Zingman <szingman@msgstor.com <mailto:szingman@msgstor.com>> wrote:
If you point a peer at the test master, please us a repeater id that matches one of your AllStar nodes. That way I can see where the traffic is coming from.
On another note, there is a bug in the mk_dmrlink script. It does not copy the sample playback configuration file into the playback directory. from the root prompt: cd /opt/dmrlink/playback cp ../samples/playback_config_SAMPLE.py playback_config.py
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org <mailto:Allstar-Digital@lists.keekles.org> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
Got it. I changed my to 28304 On Tue, Dec 15, 2015 at 10:57 AM, Steve Zingman <szingman@msgstor.com> wrote:
Understand, bridge.py is a Proxy. What the master sees is ONLY what you point at it. Consider you have a bridge configured as a peer with the id 12345 pointing at the test master. the other IPSC network defined in dmrlink.cfg is a master as 54321. 12345 is bridged with 54321. You have a repeater defined as a peer with a ID of 98765. You have a second repeater defined as a peer with a ID of 56789. The test master will think all the traffic is coming from 12345. Clear as mud?
Steve
On 12/15/2015 11:41 AM, Michael Hebert wrote:
On the DMRlink config or the repeater? or both?
On Tue, Dec 15, 2015 at 8:33 AM, Steve Zingman <szingman@msgstor.com> wrote:
If you point a peer at the test master, please us a repeater id that matches one of your AllStar nodes. That way I can see where the traffic is coming from.
On another note, there is a bug in the mk_dmrlink script. It does not copy the sample playback configuration file into the playback directory. from the root prompt: cd /opt/dmrlink/playback cp ../samples/playback_config_SAMPLE.py playback_config.py
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing listAllstar-Digital@lists.keekles.orghttp://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
participants (2)
-
Michael Hebert -
Steve Zingman