44.x.x.x HamWAN network at Paine
I have an idea to provide additional radio network connectivity to the Snohomish County DEM at Paine on 23cm, that would require one or two fixed 44.x.x.x IP addresses at the DEM, and one at my house (separate from my MikroTik radio), that would be accessible via the present 44.24.240.x connection to Paine (and perhaps any other 44.24.240.0/20 address). Both involve the use of two (or more) Icom ID-1 radios in D-Star DD mode. Background: An Icom ID-1 in DD mode acts just like a piece of Ethernet cable (except that it is half-duplex and limited to a raw 128Kbps speed). No IP address is (or can be) assigned to the device. Any Ethernet packet reaching the ID-1's Ethernet port (whatever the content) is simply encapsulated and transmitted if the radio is in DD-mode. Similarly, any received data (properly encapsulated by another ID-1) is simply sent out the receiving radio's Ethernet port. The only radio configuration possible is to select a 23cm frequency and set the radio into DD-mode. Most of these actions can either be done by the radio's control head, or via a USB port "connected" to a Windows PC running Icom's control software for the ID-1. This prior sentence is important in the following discussion. As an aside, the transmission of an ID-1 can be addressed to and received by a D-Star DD-mode "repeater" module, routed via the D-Star network over the Internet to another such "repeater" module anywhere in the world, and retransmitted over the air to a receiving ID-1 radio. This mechanism, while perhaps interesting, is not the subject of this eMail. I only mention it so as to avoid confusion. In scenario #1 for the ID-1 that already is installed at the Snohomish County DEM: 1. The Ethernet port of the ID-1 is directly connected to a switch at the DEM that is on the 44.24.240.x network. In this mode, any packets received over-the-air by the ID-1 are injected into the local 44.24.240.x network, and are routed in exactly the same manner as from any other device hard-wired to the 44.24.240.x network at the DEM. Further, any Ethernet packets seen by the ID-1 (whether intended for radio transmission or not), would be transmitted by the ID-1. 2. Another ID-1, located (say) at my house would be connected to a router, which would act as though it were directly connected to the 44.24.240.x network at the DEM. I don't view the above scenario as a good idea. For one thing, the indiscriminate transmissions from the DEM of unrelated 44.x.x.x packets doesn't seem like a good idea. For another, there is no security. So, that brings me to scenario #2: 1. At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. 2. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM. Now, here is the wrinkle (to both scenarios): The ID-1 at the DEM is currently in VERY LOW utilization, being (as so far as we know) only able to contact my ID-1 (in either digital data or voice mode), and the two 23cm D-Star K7LWH repeater modules (one voice, and presumably one data) in Bellevue. Also, the ID-1 also supports normal FM voice mode, and is easily able to hit with one watt (from both the DEM and my house) the KB7CNN 23cm FM repeater on East Tiger Mountain. So, it would be nice to use the DEM's ID-1 radio in different modes, as needed, and switch modes or frequencies REMOTELY as desired. The solution to this the use of a Digi "Anywhere/5" (or "/2") Ethernet-to-USB box (I have several). With the installation of Digi drivers on any Windows PC, these allow a PC anywhere in the world to connect over the Internet to a Digi box and have access to several remote USB devices (including any connected USB hubs). In particular, the USB control port of an ID-1. In fact, this is how I control my ID-1 at home: this allows me to control the ID-1 from any Windows PC. Hence the desire for a fixed 44.24.240.x IP address for the Digi box at the DEM, allowing REMOTE control and configuration of the ID-1 when the Internet is not available. While the Digi box can be connected to any network at the DEM, it seems most productive to connect it to the 44.24.240.x network there, allowing remote configuration and control of the ID-1 in an Internet outage (this can be disabled by unplugging the ID-1's USB port). Unfortunately, the Digi USB boxes are only usable from Windows systems (Digi's remote SERIAL (RS-232) port boxes are supported not only on Windows from 98 on, but on most variants of Linux ...). Yes, this provides a much slower connection to the DEM than the MikroTik radios, but doesn't have quite the strict line-of-sight issues that 5cm does, and thus permits some mobile access. To Scott Hokaker: I am willing to provide a Digi "Anywhere/5" box on permanent loan (or perhaps donation) to this project. I also have a couple of consumer-grade routers (Linksys BEFSR41, Netgear WGT624v2) that are similarly available, if they are suitable. Comments welcome! -- Dean
I might be able to hit this on 23 cm -- just be sure its in its own Ethernet broadcast group, it will transmit anything that appears on its Ethernet port. I think this would be a great experiment -- also on the direct buy program, an ID-RP2D can be had for $600 ( http://www.icomamerica.com/en/amateur/BuyDirect/d-star/default.aspx) and added to both HamWan and possibly NR7SS repeater gateway. ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays> On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
I have an idea to provide additional radio network connectivity to the Snohomish County DEM at Paine on 23cm, that would require one or two fixed 44.x.x.x IP addresses at the DEM, and one at my house (separate from my MikroTik radio), that would be accessible via the present 44.24.240.x connection to Paine (and perhaps any other 44.24.240.0/20 address). Both involve the use of two (or more) Icom ID-1 radios in D-Star DD mode.
Background: An Icom ID-1 in DD mode acts just like a piece of Ethernet cable (except that it is half-duplex and limited to a raw 128Kbps speed). No IP address is (or can be) assigned to the device. Any Ethernet packet reaching the ID-1's Ethernet port (whatever the content) is simply encapsulated and transmitted if the radio is in DD-mode. Similarly, any received data (properly encapsulated by another ID-1) is simply sent out the receiving radio's Ethernet port. The only radio configuration possible is to select a 23cm frequency and set the radio into DD-mode. Most of these actions can either be done by the radio's control head, or via a USB port "connected" to a Windows PC running Icom's control software for the ID-1. This prior sentence is important in the following discussion.
As an aside, the transmission of an ID-1 can be addressed to and received by a D-Star DD-mode "repeater" module, routed via the D-Star network over the Internet to another such "repeater" module anywhere in the world, and retransmitted over the air to a receiving ID-1 radio. This mechanism, while perhaps interesting, is not the subject of this eMail. I only mention it so as to avoid confusion.
In scenario #1 for the ID-1 that already is installed at the Snohomish County DEM:
1. The Ethernet port of the ID-1 is directly connected to a switch at the DEM that is on the 44.24.240.x network. In this mode, any packets received over-the-air by the ID-1 are injected into the local 44.24.240.x network, and are routed in exactly the same manner as from any other device hard-wired to the 44.24.240.x network at the DEM. Further, any Ethernet packets seen by the ID-1 (whether intended for radio transmission or not), would be transmitted by the ID-1. 2. Another ID-1, located (say) at my house would be connected to a router, which would act as though it were directly connected to the 44.24.240.x network at the DEM.
I don't view the above scenario as a good idea. For one thing, the indiscriminate transmissions from the DEM of unrelated 44.x.x.x packets doesn't seem like a good idea. For another, there is no security. So, that brings me to scenario #2:
1. At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. 2. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM.
Now, here is the wrinkle (to both scenarios): The ID-1 at the DEM is currently in VERY LOW utilization, being (as so far as we know) only able to contact my ID-1 (in either digital data or voice mode), and the two 23cm D-Star K7LWH repeater modules (one voice, and presumably one data) in Bellevue. Also, the ID-1 also supports normal FM voice mode, and is easily able to hit with one watt (from both the DEM and my house) the KB7CNN 23cm FM repeater on East Tiger Mountain. So, it would be nice to use the DEM's ID-1 radio in different modes, as needed, and switch modes or frequencies REMOTELY as desired. The solution to this the use of a Digi "Anywhere/5" (or "/2") Ethernet-to-USB box (I have several). With the installation of Digi drivers on any Windows PC, these allow a PC anywhere in the world to connect over the Internet to a Digi box and have access to several remote USB devices (including any connected USB hubs). In particular, the USB control port of an ID-1. In fact, this is how I control my ID-1 at home: this allows me to control the ID-1 from any Windows PC.
Hence the desire for a fixed 44.24.240.x IP address for the Digi box at the DEM, allowing REMOTE control and configuration of the ID-1 when the Internet is not available. While the Digi box can be connected to any network at the DEM, it seems most productive to connect it to the 44.24.240.x network there, allowing remote configuration and control of the ID-1 in an Internet outage (this can be disabled by unplugging the ID-1's USB port). Unfortunately, the Digi USB boxes are only usable from Windows systems (Digi's remote SERIAL (RS-232) port boxes are supported not only on Windows from 98 on, but on most variants of Linux ...).
Yes, this provides a much slower connection to the DEM than the MikroTik radios, but doesn't have quite the strict line-of-sight issues that 5cm does, and thus permits some mobile access.
To Scott Hokaker:
I am willing to provide a Digi "Anywhere/5" box on permanent loan (or perhaps donation) to this project. I also have a couple of consumer-grade routers (Linksys BEFSR41, Netgear WGT624v2) that are similarly available, if they are suitable.
Comments welcome!
-- Dean
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
I like this plan. We have a DD mode repeater on site currently that was moved from Granite Falls. I think it currently has the antenna at the 150' level and the ID-1 is using the antenna at 40'. These can be swapped as needed. Scott N7SS On Sat, Apr 26, 2014 at 9:41 PM, John D. Hays <john@hays.org> wrote:
I might be able to hit this on 23 cm -- just be sure its in its own Ethernet broadcast group, it will transmit anything that appears on its Ethernet port.
I think this would be a great experiment -- also on the direct buy program, an ID-RP2D can be had for $600 ( http://www.icomamerica.com/en/amateur/BuyDirect/d-star/default.aspx) and added to both HamWan and possibly NR7SS repeater gateway.
------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays>
On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
I have an idea to provide additional radio network connectivity to the Snohomish County DEM at Paine on 23cm, that would require one or two fixed 44.x.x.x IP addresses at the DEM, and one at my house (separate from my MikroTik radio), that would be accessible via the present 44.24.240.x connection to Paine (and perhaps any other 44.24.240.0/20 address). Both involve the use of two (or more) Icom ID-1 radios in D-Star DD mode.
Background: An Icom ID-1 in DD mode acts just like a piece of Ethernet cable (except that it is half-duplex and limited to a raw 128Kbps speed). No IP address is (or can be) assigned to the device. Any Ethernet packet reaching the ID-1's Ethernet port (whatever the content) is simply encapsulated and transmitted if the radio is in DD-mode. Similarly, any received data (properly encapsulated by another ID-1) is simply sent out the receiving radio's Ethernet port. The only radio configuration possible is to select a 23cm frequency and set the radio into DD-mode. Most of these actions can either be done by the radio's control head, or via a USB port "connected" to a Windows PC running Icom's control software for the ID-1. This prior sentence is important in the following discussion.
As an aside, the transmission of an ID-1 can be addressed to and received by a D-Star DD-mode "repeater" module, routed via the D-Star network over the Internet to another such "repeater" module anywhere in the world, and retransmitted over the air to a receiving ID-1 radio. This mechanism, while perhaps interesting, is not the subject of this eMail. I only mention it so as to avoid confusion.
In scenario #1 for the ID-1 that already is installed at the Snohomish County DEM:
1. The Ethernet port of the ID-1 is directly connected to a switch at the DEM that is on the 44.24.240.x network. In this mode, any packets received over-the-air by the ID-1 are injected into the local 44.24.240.x network, and are routed in exactly the same manner as from any other device hard-wired to the 44.24.240.x network at the DEM. Further, any Ethernet packets seen by the ID-1 (whether intended for radio transmission or not), would be transmitted by the ID-1. 2. Another ID-1, located (say) at my house would be connected to a router, which would act as though it were directly connected to the 44.24.240.x network at the DEM.
I don't view the above scenario as a good idea. For one thing, the indiscriminate transmissions from the DEM of unrelated 44.x.x.x packets doesn't seem like a good idea. For another, there is no security. So, that brings me to scenario #2:
1. At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. 2. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM.
Now, here is the wrinkle (to both scenarios): The ID-1 at the DEM is currently in VERY LOW utilization, being (as so far as we know) only able to contact my ID-1 (in either digital data or voice mode), and the two 23cm D-Star K7LWH repeater modules (one voice, and presumably one data) in Bellevue. Also, the ID-1 also supports normal FM voice mode, and is easily able to hit with one watt (from both the DEM and my house) the KB7CNN 23cm FM repeater on East Tiger Mountain. So, it would be nice to use the DEM's ID-1 radio in different modes, as needed, and switch modes or frequencies REMOTELY as desired. The solution to this the use of a Digi "Anywhere/5" (or "/2") Ethernet-to-USB box (I have several). With the installation of Digi drivers on any Windows PC, these allow a PC anywhere in the world to connect over the Internet to a Digi box and have access to several remote USB devices (including any connected USB hubs). In particular, the USB control port of an ID-1. In fact, this is how I control my ID-1 at home: this allows me to control the ID-1 from any Windows PC.
Hence the desire for a fixed 44.24.240.x IP address for the Digi box at the DEM, allowing REMOTE control and configuration of the ID-1 when the Internet is not available. While the Digi box can be connected to any network at the DEM, it seems most productive to connect it to the 44.24.240.x network there, allowing remote configuration and control of the ID-1 in an Internet outage (this can be disabled by unplugging the ID-1's USB port). Unfortunately, the Digi USB boxes are only usable from Windows systems (Digi's remote SERIAL (RS-232) port boxes are supported not only on Windows from 98 on, but on most variants of Linux ...).
Yes, this provides a much slower connection to the DEM than the MikroTik radios, but doesn't have quite the strict line-of-sight issues that 5cm does, and thus permits some mobile access.
To Scott Hokaker:
I am willing to provide a Digi "Anywhere/5" box on permanent loan (or perhaps donation) to this project. I also have a couple of consumer-grade routers (Linksys BEFSR41, Netgear WGT624v2) that are similarly available, if they are suitable.
Comments welcome!
-- Dean
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM.
We have a router at Snohomish County DEM with an extra port that could be used for this. The subnet there is 44.24.240.128/28. We have another subnet of address pairs set aside for router-to-router links. So as far as networking goes, we could execute your plan. I can't commend about the feasibility of any of the other bits. Tom
Any packets on that LAN are considered trusted since they passed authentication. What's the auth story on the 23cm modems? --Bart On 4/26/2014 10:37 PM, Tom Hayward wrote:
On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM. We have a router at Snohomish County DEM with an extra port that could be used for this. The subnet there is 44.24.240.128/28. We have another subnet of address pairs set aside for router-to-router links. So as far as networking goes, we could execute your plan. I can't commend about the feasibility of any of the other bits.
Tom
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
It's just an Ethernet tunnel over DSTAR. Sent from my iPhone
On Apr 26, 2014, at 10:39 PM, Bart Kus <me@bartk.us> wrote:
Any packets on that LAN are considered trusted since they passed authentication. What's the auth story on the 23cm modems?
--Bart
On 4/26/2014 10:37 PM, Tom Hayward wrote:
On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote: At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM. We have a router at Snohomish County DEM with an extra port that could be used for this. The subnet there is 44.24.240.128/28. We have another subnet of address pairs set aside for router-to-router links. So as far as networking goes, we could execute your plan. I can't commend about the feasibility of any of the other bits.
Tom
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
The only "authentication" the radio has, are the following: 1. The radio can be set to only receive remote transmissions that include a two-digit decimal code; *or* 2. The radio can be set to only receive remote transmissions that are addressed to the callsign programmed into the receiving radio (I would recommend this setting). Any other authentication would have to be provided by a router or firewall. On 2014-04-26 22:39, Bart Kus wrote:
Any packets on that LAN are considered trusted since they passed authentication. What's the auth story on the 23cm modems?
--Bart
On 4/26/2014 10:37 PM, Tom Hayward wrote:
On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM. We have a router at Snohomish County DEM with an extra port that could be used for this. The subnet there is 44.24.240.128/28. We have another subnet of address pairs set aside for router-to-router links. So as far as networking goes, we could execute your plan. I can't commend about the feasibility of any of the other bits.
Tom
It should be on a dedicated router on its own segment. Sent from my iPhone
On Apr 27, 2014, at 9:27 AM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
The only "authentication" the radio has, are the following: The radio can be set to only receive remote transmissions that include a two-digit decimal code; or The radio can be set to only receive remote transmissions that are addressed to the callsign programmed into the receiving radio (I would recommend this setting). Any other authentication would have to be provided by a router or firewall.
On 2014-04-26 22:39, Bart Kus wrote: Any packets on that LAN are considered trusted since they passed authentication. What's the auth story on the 23cm modems?
--Bart
On 4/26/2014 10:37 PM, Tom Hayward wrote:
On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote: At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM. We have a router at Snohomish County DEM with an extra port that could be used for this. The subnet there is 44.24.240.128/28. We have another subnet of address pairs set aside for router-to-router links. So as far as networking goes, we could execute your plan. I can't commend about the feasibility of any of the other bits.
Tom
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Exactly (or the equivalent). On 2014-04-27 09:34, John Hays wrote:
It should be on a dedicated router on its own segment.
Sent from my iPhone
On Apr 27, 2014, at 9:27 AM, Dean Gibson AE7Q <hamwan@ae7q.com <mailto:hamwan@ae7q.com>> wrote:
The only "authentication" the radio has, are the following:
1. The radio can be set to only receive remote transmissions that include a two-digit decimal code; *or* 2. The radio can be set to only receive remote transmissions that are addressed to the callsign programmed into the receiving radio (I would recommend this setting).
Any other authentication would have to be provided by a router or firewall.
On 2014-04-26 22:39, Bart Kus wrote:
Any packets on that LAN are considered trusted since they passed authentication. What's the auth story on the 23cm modems?
--Bart
On 4/26/2014 10:37 PM, Tom Hayward wrote:
On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM. We have a router at Snohomish County DEM with an extra port that could be used for this. The subnet there is 44.24.240.128/28. We have another subnet of address pairs set aside for router-to-router links. So as far as networking goes, we could execute your plan. I can't commend about the feasibility of any of the other bits.
Tom
OK, we can slap some extra security on there. Shouldn't need an extra router for that. What about the PtMP story? One of the advantages you mentioned (Dean) was mobile access. Can it multiplex access somehow? --Bart On 4/27/2014 9:53 AM, Dean Gibson AE7Q wrote:
Exactly (or the equivalent).
On 2014-04-27 09:34, John Hays wrote:
It should be on a dedicated router on its own segment.
Sent from my iPhone
On Apr 27, 2014, at 9:27 AM, Dean Gibson AE7Q <hamwan@ae7q.com <mailto:hamwan@ae7q.com>> wrote:
The only "authentication" the radio has, are the following:
1. The radio can be set to only receive remote transmissions that include a two-digit decimal code; *or* 2. The radio can be set to only receive remote transmissions that are addressed to the callsign programmed into the receiving radio (I would recommend this setting).
Any other authentication would have to be provided by a router or firewall.
On 2014-04-26 22:39, Bart Kus wrote:
Any packets on that LAN are considered trusted since they passed authentication. What's the auth story on the 23cm modems?
--Bart
On 4/26/2014 10:37 PM, Tom Hayward wrote:
On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM. We have a router at Snohomish County DEM with an extra port that could be used for this. The subnet there is 44.24.240.128/28. We have another subnet of address pairs set aside for router-to-router links. So as far as networking goes, we could execute your plan. I can't commend about the feasibility of any of the other bits.
Tom
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
I had to Google to find out what P2MP was, but in my VERY brief Google education on the subject, I don't think it applies. The radio doesn't multiplex anything. The consumer-grade routers I own (Linksys BEFSR41, Netgear WGT624v2) seem to have no way to turn off NAT. dd-wrt is not possible with the BEFSR41; it is "work-in-progress" for the WGT624v2. NAT seems to make routing issues a little more complex to think through. Both routers have the ability to specify a "DMZ host", but I think that just turns on universal NAT to that host. Both routers have the capability of manually adding entries to a static routing table, but I don't know if that skips over the NAT. If we have to have NAT, it seems to me that the best way to set up the router is with the radio connected to the LAN side (with whatever private IP address we want), and have the WAN side connected to the 44.x.x.x network. That allows incoming (ie, via the radio) packets to go wherever they can and responses to come back; whereas orienting the router the other way (unless we use the "DMZ host" feature) doesn't. I suppose I could donate one of my (very) elderly (2005) Dell PowerEdge 1650 1U servers to the effort, but that seems like a bit of overkill ... What I think would be a good idea is to meet and discuss this face-to-face (pretty much anytime) with diagrams, rather than shoveling eMails back and forth. Scott, if your schedule permits, you are more than welcome. -- Dean ps: Scott, I plan to come to the DEM on Tuesday to start on this, unless you're not going to be there, or other conditions (like ongoing slide work) make it a bad idea. On 2014-04-27 12:06, Bart Kus wrote:
OK, we can slap some extra security on there. Shouldn't need an extra router for that.
What about the PtMP story? One of the advantages you mentioned (Dean) was mobile access. Can it multiplex access somehow?
--Bart
On 4/27/2014 9:53 AM, Dean Gibson AE7Q wrote:
Exactly (or the equivalent).
On 2014-04-27 09:34, John Hays wrote:
It should be on a dedicated router on its own segment.
Sent from my iPhone
On Apr 27, 2014, at 9:27 AM, Dean Gibson AE7Q <hamwan@ae7q.com <mailto:hamwan@ae7q.com>> wrote:
The only "authentication" the radio has, are the following:
1. The radio can be set to only receive remote transmissions that include a two-digit decimal code; *or* 2. The radio can be set to only receive remote transmissions that are addressed to the callsign programmed into the receiving radio (I would recommend this setting).
Any other authentication would have to be provided by a router or firewall.
On 2014-04-26 22:39, Bart Kus wrote:
Any packets on that LAN are considered trusted since they passed authentication. What's the auth story on the 23cm modems?
--Bart
On 4/26/2014 10:37 PM, Tom Hayward wrote:
On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote: > At the Snohomish County DEM, place a router (or bridge) between > the ID-1 and the 44.24.240.x network. > In this scenario, the ID-1 located at my house would also be > connected to a router that acts as though it were directly > connected to the 44.24.240.x (or any other) network at the DEM. We have a router at Snohomish County DEM with an extra port that could be used for this. The subnet there is 44.24.240.128/28. We have another subnet of address pairs set aside for router-to-router links. So as far as networking goes, we could execute your plan. I can't commend about the feasibility of any of the other bits.
Tom
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
BTW, I through a bunch of packets at the RP2D. I think it was replying but I wasn't able to get IP level responses. ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays> On Sun, Apr 27, 2014 at 6:48 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
I had to Google to find out what P2MP was, but in my VERY brief Google education on the subject, I don't think it applies.
The radio doesn't multiplex anything.
The consumer-grade routers I own (Linksys BEFSR41, Netgear WGT624v2) seem to have no way to turn off NAT. dd-wrt is not possible with the BEFSR41; it is "work-in-progress" for the WGT624v2. NAT seems to make routing issues a little more complex to think through. Both routers have the ability to specify a "DMZ host", but I think that just turns on universal NAT to that host. Both routers have the capability of manually adding entries to a static routing table, but I don't know if that skips over the NAT. If we have to have NAT, it seems to me that the best way to set up the router is with the radio connected to the LAN side (with whatever private IP address we want), and have the WAN side connected to the 44.x.x.x network. That allows incoming (ie, via the radio) packets to go wherever they can and responses to come back; whereas orienting the router the other way (unless we use the "DMZ host" feature) doesn't. I suppose I could donate one of my (very) elderly (2005) Dell PowerEdge 1650 1U servers to the effort, but that seems like a bit of overkill ...
What I think would be a good idea is to meet and discuss this face-to-face (pretty much anytime) with diagrams, rather than shoveling eMails back and forth. Scott, if your schedule permits, you are more than welcome.
-- Dean
ps: Scott, I plan to come to the DEM on Tuesday to start on this, unless you're not going to be there, or other conditions (like ongoing slide work) make it a bad idea.
On 2014-04-27 12:06, Bart Kus wrote:
OK, we can slap some extra security on there. Shouldn't need an extra router for that.
What about the PtMP story? One of the advantages you mentioned (Dean) was mobile access. Can it multiplex access somehow?
--Bart
On 4/27/2014 9:53 AM, Dean Gibson AE7Q wrote:
Exactly (or the equivalent).
On 2014-04-27 09:34, John Hays wrote:
It should be on a dedicated router on its own segment.
Sent from my iPhone
On Apr 27, 2014, at 9:27 AM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
The only "authentication" the radio has, are the following:
1. The radio can be set to only receive remote transmissions that include a two-digit decimal code; *or* 2. The radio can be set to only receive remote transmissions that are addressed to the callsign programmed into the receiving radio (I would recommend this setting).
Any other authentication would have to be provided by a router or firewall.
On 2014-04-26 22:39, Bart Kus wrote:
Any packets on that LAN are considered trusted since they passed authentication. What's the auth story on the 23cm modems?
--Bart
On 4/26/2014 10:37 PM, Tom Hayward wrote:
On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q <hamwan@ae7q.com><hamwan@ae7q.com>wrote:
At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM.
We have a router at Snohomish County DEM with an extra port that could be used for this. The subnet there is 44.24.240.128/28. We have another subnet of address pairs set aside for router-to-router links. So as far as networking goes, we could execute your plan. I can't commend about the feasibility of any of the other bits.
Tom
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Which RP2D? K7LWH or NR7SS? I heard you on K7LWH DV-A ... Did you read the Icom and/or K5TIT documentation? [Lurkers: that's my idea of humor ...] ps: John: Since an Icom gateway is dual-homed at 10.0.0.2 (Internet gateway 10.0.0.1) and 172.16.0.20, if one wants to put another box on the local 10.x.x.x network, are there any 10.x.x.x addresses that are reserved/available for local use, without being assigned/preempted by the US Trust system? Otherwise, I suppose I could do port-forwarding on the box into the 172.16.x.x network, and allocate one there ... On 2014-04-27 19:02, John D. Hays wrote:
BTW, I through a bunch of packets at the RP2D. I think it was replying but I wasn't able to get IP level responses.
------------------------------------------------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#%21/john_hays> <http://www.facebook.com/john.d.hays>
On Sun, Apr 27, 2014 at 6:48 PM, Dean Gibson AE7Q <hamwan@ae7q.com <mailto:hamwan@ae7q.com>> wrote:
I had to Google to find out what P2MP was, but in my VERY brief Google education on the subject, I don't think it applies.
The radio doesn't multiplex anything.
The consumer-grade routers I own (Linksys BEFSR41, Netgear WGT624v2) seem to have no way to turn off NAT. dd-wrt is not possible with the BEFSR41; it is "work-in-progress" for the WGT624v2. NAT seems to make routing issues a little more complex to think through. Both routers have the ability to specify a "DMZ host", but I think that just turns on universal NAT to that host. Both routers have the capability of manually adding entries to a static routing table, but I don't know if that skips over the NAT. If we have to have NAT, it seems to me that the best way to set up the router is with the radio connected to the LAN side (with whatever private IP address we want), and have the WAN side connected to the 44.x.x.x network. That allows incoming (ie, via the radio) packets to go wherever they can and responses to come back; whereas orienting the router the other way (unless we use the "DMZ host" feature) doesn't. I suppose I could donate one of my (very) elderly (2005) Dell PowerEdge 1650 1U servers to the effort, but that seems like a bit of overkill ...
What I think would be a good idea is to meet and discuss this face-to-face (pretty much anytime) with diagrams, rather than shoveling eMails back and forth. Scott, if your schedule permits, you are more than welcome.
-- Dean
ps: Scott, I plan to come to the DEM on Tuesday to start on this, unless you're not going to be there, or other conditions (like ongoing slide work) make it a bad idea.
On 2014-04-27 12:06, Bart Kus wrote:
OK, we can slap some extra security on there. Shouldn't need an extra router for that.
What about the PtMP story? One of the advantages you mentioned (Dean) was mobile access. Can it multiplex access somehow?
--Bart
On 4/27/2014 9:53 AM, Dean Gibson AE7Q wrote:
Exactly (or the equivalent).
On 2014-04-27 09:34, John Hays wrote:
It should be on a dedicated router on its own segment.
Sent from my iPhone
On Apr 27, 2014, at 9:27 AM, Dean Gibson AE7Q <hamwan@ae7q.com <mailto:hamwan@ae7q.com>> wrote:
The only "authentication" the radio has, are the following:
1. The radio can be set to only receive remote transmissions that include a two-digit decimal code; *or* 2. The radio can be set to only receive remote transmissions that are addressed to the callsign programmed into the receiving radio (I would recommend this setting).
Any other authentication would have to be provided by a router or firewall.
On 2014-04-26 22:39, Bart Kus wrote:
Any packets on that LAN are considered trusted since they passed authentication. What's the auth story on the 23cm modems?
--Bart
On 4/26/2014 10:37 PM, Tom Hayward wrote: > On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q > <hamwan@ae7q.com> <mailto:hamwan@ae7q.com> wrote: >> At the Snohomish County DEM, place a router (or bridge) >> between the ID-1 and the 44.24.240.x network. >> In this scenario, the ID-1 located at my house would also >> be connected to a router that acts as though it were >> directly connected to the 44.24.240.x (or any other) >> network at the DEM. > We have a router at Snohomish County DEM with an extra port > that could be used for this. The subnet there is > 44.24.240.128 <tel:44.24.240.128>/28. We have another subnet > of address pairs set aside for router-to-router links. So as > far as networking goes, we could execute your plan. I can't > commend about the feasibility of any of the other bits. > > Tom
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
All that routing stuff is at a layer higher than I was meaning to ask about. PtMP is just short hand for Point to Multi-Point communication. In the two modes of operation you outlined, it seems to me it's possible for 2 mobile stations to communicate with 1 common fixed station by simply transmitting packets that bear either a common 2-digit code, or contain the fixed station's callsign. Is the fixed station capable of sending responses addressed distinctly to each of the 2 mobile stations? Is the addressing doable on a per-packet basis, or would the fixed radio need to be re-programmed with a new destination address (callsign) or something? Can it simply transmit a frame bearing the common 2-digit code and all stations in earshot will receive it? In terms of multiplexing, how does any station know when it is OK to transmit? Is there a CSMA scheme or is it just an immediate transmission when data comes in? Is there something more advanced, like ARQ? In the above scenario, are the 2 mobile stations able to communicate directly between each other? (assuming all nodes can hear each other here) --Bart On 4/27/2014 6:48 PM, Dean Gibson AE7Q wrote:
I had to Google to find out what P2MP was, but in my VERY brief Google education on the subject, I don't think it applies.
The radio doesn't multiplex anything.
The consumer-grade routers I own (Linksys BEFSR41, Netgear WGT624v2) seem to have no way to turn off NAT. dd-wrt is not possible with the BEFSR41; it is "work-in-progress" for the WGT624v2. NAT seems to make routing issues a little more complex to think through. Both routers have the ability to specify a "DMZ host", but I think that just turns on universal NAT to that host. Both routers have the capability of manually adding entries to a static routing table, but I don't know if that skips over the NAT. If we have to have NAT, it seems to me that the best way to set up the router is with the radio connected to the LAN side (with whatever private IP address we want), and have the WAN side connected to the 44.x.x.x network. That allows incoming (ie, via the radio) packets to go wherever they can and responses to come back; whereas orienting the router the other way (unless we use the "DMZ host" feature) doesn't. I suppose I could donate one of my (very) elderly (2005) Dell PowerEdge 1650 1U servers to the effort, but that seems like a bit of overkill ...
What I think would be a good idea is to meet and discuss this face-to-face (pretty much anytime) with diagrams, rather than shoveling eMails back and forth. Scott, if your schedule permits, you are more than welcome.
-- Dean
ps: Scott, I plan to come to the DEM on Tuesday to start on this, unless you're not going to be there, or other conditions (like ongoing slide work) make it a bad idea.
On 2014-04-27 12:06, Bart Kus wrote:
OK, we can slap some extra security on there. Shouldn't need an extra router for that.
What about the PtMP story? One of the advantages you mentioned (Dean) was mobile access. Can it multiplex access somehow?
--Bart
On 4/27/2014 9:53 AM, Dean Gibson AE7Q wrote:
Exactly (or the equivalent).
On 2014-04-27 09:34, John Hays wrote:
It should be on a dedicated router on its own segment.
Sent from my iPhone
On Apr 27, 2014, at 9:27 AM, Dean Gibson AE7Q <hamwan@ae7q.com <mailto:hamwan@ae7q.com>> wrote:
The only "authentication" the radio has, are the following:
1. The radio can be set to only receive remote transmissions that include a two-digit decimal code; *or* 2. The radio can be set to only receive remote transmissions that are addressed to the callsign programmed into the receiving radio (I would recommend this setting).
Any other authentication would have to be provided by a router or firewall.
On 2014-04-26 22:39, Bart Kus wrote:
Any packets on that LAN are considered trusted since they passed authentication. What's the auth story on the 23cm modems?
--Bart
On 4/26/2014 10:37 PM, Tom Hayward wrote: > On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q > <hamwan@ae7q.com> wrote: >> At the Snohomish County DEM, place a router (or bridge) between >> the ID-1 and the 44.24.240.x network. >> In this scenario, the ID-1 located at my house would also be >> connected to a router that acts as though it were directly >> connected to the 44.24.240.x (or any other) network at the DEM. > We have a router at Snohomish County DEM with an extra port that > could be used for this. The subnet there is 44.24.240.128/28. We > have another subnet of address pairs set aside for > router-to-router links. So as far as networking goes, we could > execute your plan. I can't commend about the feasibility of any > of the other bits. > > Tom
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
On 2014-04-27 22:59, Bart Kus wrote:
All that routing stuff is at a layer higher than I was meaning to ask about.
PtMP is just short hand for Point to Multi-Point communication.
In the two modes of operation you outlined, it seems to me it's possible for 2 mobile stations to communicate with 1 common fixed station by simply transmitting packets that bear either a common 2-digit code, or contain the fixed station's callsign.
Yes.
Is the fixed station capable of sending responses addressed distinctly to each of the 2 mobile stations?
Yes, but not programmatically. While the control head and the Windows software can change the addressing, that's done through the USB port, not over the Ethernet port. I believe the USB control interface is documented, so one could write software to do that, but that's too much nuisance for me.
Is the addressing doable on a per-packet basis, or would the fixed radio need to be re-programmed with a new destination address (callsign) or something?
No, and yes (see above).
Can it simply transmit a frame bearing the common 2-digit code and all stations in earshot will receive it?
Yes. It's totally up to the receiving radio as to whether use the 2-digit code or callsign for filtering. If it doesn't, it receives everything it hears.
In terms of multiplexing, how does any station know when it is OK to transmit?
Later D-Star voice (+ low speed data) radios had a "busy lockout" option. The ID-1 has no such visible option, so I don't know the answer to your question.
Is there a CSMA scheme or is it just an immediate transmission when data comes in? Is there something more advanced, like ARQ?
No, yes, no.
In the above scenario, are the 2 mobile stations able to communicate directly between each other? (assuming all nodes can hear each other here)
Absolutely. Unless a receiving radio filters on the 2-digit code or callsign, it receives everything. By extension, when it transmits, everyone else hears it. The sender (absent a protocol) has no way of knowing what receiver is hearing (or filtering) it. About ten years ago I wrote a program to send (serial) data (@ 1200 bps) between multiple D-Star voice radios (which all have the 1200 bps data "subchannel"). Those radios had "busy lockout", but the software had no way of knowing if the frequency was in use. I used a simple "ACK" protocol, and in the absence of receiving an ACK, used a semi-exponential random backoff if no ACK was received. In other words, I used the absence of an ACK as a probable indication of a collision. The ID-1 is two orders of magnitude faster and encapsulates and sends arbitrary Ethernet frames, but not much else is different (the 2-digit code and callsign filtering is also applicable to voice usage). Of course, in TCP/IP, the packet originator will do any necessary retries. The whole thing is suitable for multiple stations on a frequency, only in a low-traffic environment. Of course, this is perfectly suited to typical Amateur Radio repeater usage [Dean's sarcasm is showing]. Note that in original D-Star design, it was thought (John Hays, correct me if I'm wrong) that a D-Star DD-mode repeater module would receive each Ethernet packet, lookup the target callsign in the callsign "roaming" database to see where (which repeater) the target callsign was last heard*, and send the encapsulated packet over the Internet to a destination dd-mode repeater, where the packet would be sent out over the air, hopefully to a listening ID-1 radio. I believe (again, John knows this better than I for DD-mode) it's only after the packet has been de-encapsulated by the receiving radio, that the destination IP address in the Ethernet packet is even examined, and that only by the host or router connected to the radio. This is called "callsign routing", and it works in exactly the same way for voice (DV-mode). Unfortunately, this mechanism is way too complicated for the average Amateur Radio operator to understand, so it is rarely used for voice, having been effectively replaced (oops, supplanted) by "reflectors" linking repeaters in an EchoLink-like scenario. So, you may wonder, why do I want to even screw around with the ID-1 radios in DD-mode? Because there are so few of them, and I have one on the air, and the SnoCo DEM has one on the air. I think John Hays has one (or maybe he has the Icom 9100 ???). I think Scott has one at home (in the box). Gary Fiber (a former Icom employee) has one in his vehicle.
On 4/27/2014 6:48 PM, Dean Gibson AE7Q wrote:
I had to Google to find out what P2MP was, but in my VERY brief Google education on the subject, I don't think it applies.
The radio doesn't multiplex anything.
The consumer-grade routers I own (Linksys BEFSR41, Netgear WGT624v2) seem to have no way to turn off NAT. dd-wrt is not possible with the BEFSR41; it is "work-in-progress" for the WGT624v2. NAT seems to make routing issues a little more complex to think through. Both routers have the ability to specify a "DMZ host", but I think that just turns on universal NAT to that host. Both routers have the capability of manually adding entries to a static routing table, but I don't know if that skips over the NAT. If we have to have NAT, it seems to me that the best way to set up the router is with the radio connected to the LAN side (with whatever private IP address we want), and have the WAN side connected to the 44.x.x.x network. That allows incoming (ie, via the radio) packets to go wherever they can and responses to come back; whereas orienting the router the other way (unless we use the "DMZ host" feature) doesn't. I suppose I could donate one of my (very) elderly (2005) Dell PowerEdge 1650 1U servers to the effort, but that seems like a bit of overkill ...
What I think would be a good idea is to meet and discuss this face-to-face (pretty much anytime) with diagrams, rather than shoveling eMails back and forth. Scott, if your schedule permits, you are more than welcome.
-- Dean
ps: Scott, I plan to come to the DEM on Tuesday to start on this, unless you're not going to be there, or other conditions (like ongoing slide work) make it a bad idea.
On 2014-04-27 12:06, Bart Kus wrote:
OK, we can slap some extra security on there. Shouldn't need an extra router for that.
What about the PtMP story? One of the advantages you mentioned (Dean) was mobile access. Can it multiplex access somehow?
--Bart
On 4/27/2014 9:53 AM, Dean Gibson AE7Q wrote:
Exactly (or the equivalent).
On 2014-04-27 09:34, John Hays wrote:
It should be on a dedicated router on its own segment.
Sent from my iPhone
On Apr 27, 2014, at 9:27 AM, Dean Gibson AE7Q <hamwan@ae7q.com <mailto:hamwan@ae7q.com>> wrote:
The only "authentication" the radio has, are the following:
1. The radio can be set to only receive remote transmissions that include a two-digit decimal code; *or* 2. The radio can be set to only receive remote transmissions that are addressed to the callsign programmed into the receiving radio (I would recommend this setting).
Any other authentication would have to be provided by a router or firewall.
On 2014-04-26 22:39, Bart Kus wrote: > Any packets on that LAN are considered trusted since they passed > authentication. What's the auth story on the 23cm modems? > > --Bart > > On 4/26/2014 10:37 PM, Tom Hayward wrote: >> On Sat, Apr 26, 2014 at 9:26 PM, Dean Gibson AE7Q >> <hamwan@ae7q.com> wrote: >>> At the Snohomish County DEM, place a router (or bridge) >>> between the ID-1 and the 44.24.240.x network. >>> In this scenario, the ID-1 located at my house would also be >>> connected to a router that acts as though it were directly >>> connected to the 44.24.240.x (or any other) network at the DEM. >> We have a router at Snohomish County DEM with an extra port >> that could be used for this. The subnet there is >> 44.24.240.128/28. We have another subnet of address pairs set >> aside for router-to-router links. So as far as networking goes, >> we could execute your plan. I can't commend about the >> feasibility of any of the other bits. >> >> Tom
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
So, you may wonder, why do I want to even screw around with the ID-1 radios in DD-mode? Because there are so few of them, and I have one on the air, and the SnoCo DEM has one on the air.
Another local EmComm group has 7 ID-1's that, AFAIK, aren't yet being used. Some of the folks there that I've talked to have mentioned propagation issues as the primary impediment. I bet they'd be very happy to have a cookbook process in place where they could get on and connect with a node like Paine Field or set up one of their own. 73 Bill, WA7NWP
On 2014-04-30 17:37, Bill Vodall wrote:
So, you may wonder, why do I want to even screw around with the ID-1 radios in DD-mode? Because there are so few of them, and I have one on the air, and the SnoCo DEM has one on the air. Another local EmComm group has 7 ID-1's that, AFAIK, aren't yet being used. Some of the folks there that I've talked to have mentioned propagation issues as the primary impediment.
I bet they'd be very happy to have a cookbook process in place where they could get on and connect with a node like Paine Field or set up one of their own.
Bill, WA7NWP
Stay tuned ...
Bill, Kirkland Emergency Communications Team took delivery of 10 ID-1s, a ID-RP2C Controller and a ID-R3 Data Module in 2010. The intent was to link our EOC-Radio Room with our 7 remotes sites and two portable units with a high speed data network. However we did not develop functional requirement specifications and we did not do any preliminary feasibility testing before equipment order was placed. I spent two years attempting to develop a working network. Below are some of my findings. 1. The radio to radio path has to be line of sight or via a good reliable reflector. The best tool that I found to determine if a viable path exists is Radio Mobile. I did a number of field tests, ID-1 to ID-1 and ID-1 to the K7LWH DD node on the Lincoln Tower in Belleview. In all tests where the terrain extended into the direct path a connection could not be established. Our only fixed location in Kirkland with K7LWH DD node is the city hall. We have only on fire station that could see the antenna on the City Hall. With the new construction I am not sure if it is currently a good path. 2. ID-1 to ID-1 DD mode is simplex. A 1MB image takes about 2.5 minutes to transfer. 3. I am not sure of what the through put would be for a DD Gateway (K7KFD) 2, 3 or 4 ID-1's were connected at the same time and passing files. 4. I was told by ICOM, a few years ago, that the ID-1s could not be meshed. If the firmware could be reprogrammed to be compatible with Broadband-Hamnet, many of us may be willing to take the ID-1 off the shelf and get them on the air. 5. There are groups that have established links using ID-1s back to back but I determined that our group did not have the human recourse to establish and maintain a reliable link in a disaster at this time. I for one would like to see an ID-1 networking "cookbook" if one is ever written. John Haze K7VE was a recourse the rest was through trial and error. I am willing to share my rough notes (they are rough) with anyone that may be interested. In the mean time I am looking to HamWAN and Broadband-Hamnet to handle high speed data transfer in Kirkland. Bob Morrisson KE7JL Kirkland Emergency Communications Team -----Original Message----- From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Bill Vodall Sent: Wednesday, April 30, 2014 5:37 PM To: Puget Sound Data Ring Subject: Re: [HamWAN PSDR] 44.x.x.x HamWAN network at Paine
So, you may wonder, why do I want to even screw around with the ID-1 radios in DD-mode? Because there are so few of them, and I have one on the air, and the SnoCo DEM has one on the air.
Another local EmComm group has 7 ID-1's that, AFAIK, aren't yet being used. Some of the folks there that I've talked to have mentioned propagation issues as the primary impediment. I bet they'd be very happy to have a cookbook process in place where they could get on and connect with a node like Paine Field or set up one of their own. 73 Bill, WA7NWP _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
One thing I have discovered is if you build it, sometimes they do NOT come. First you have to have a need, business case, what ever you want to call it. Services running etc? Steve On Thu, May 1, 2014 at 10:53 AM, Bob <ke7jl@comcast.net> wrote:
Bill, Kirkland Emergency Communications Team took delivery of 10 ID-1s, a ID-RP2C Controller and a ID-R3 Data Module in 2010. The intent was to link our EOC-Radio Room with our 7 remotes sites and two portable units with a high speed data network. However we did not develop functional requirement specifications and we did not do any preliminary feasibility testing before equipment order was placed. I spent two years attempting to develop a working network. Below are some of my findings. 1. The radio to radio path has to be line of sight or via a good reliable reflector. The best tool that I found to determine if a viable path exists is Radio Mobile. I did a number of field tests, ID-1 to ID-1 and ID-1 to the K7LWH DD node on the Lincoln Tower in Belleview. In all tests where the terrain extended into the direct path a connection could not be established. Our only fixed location in Kirkland with K7LWH DD node is the city hall. We have only on fire station that could see the antenna on the City Hall. With the new construction I am not sure if it is currently a good path. 2. ID-1 to ID-1 DD mode is simplex. A 1MB image takes about 2.5 minutes to transfer. 3. I am not sure of what the through put would be for a DD Gateway (K7KFD) 2, 3 or 4 ID-1's were connected at the same time and passing files. 4. I was told by ICOM, a few years ago, that the ID-1s could not be meshed. If the firmware could be reprogrammed to be compatible with Broadband-Hamnet, many of us may be willing to take the ID-1 off the shelf and get them on the air. 5. There are groups that have established links using ID-1s back to back but I determined that our group did not have the human recourse to establish and maintain a reliable link in a disaster at this time.
I for one would like to see an ID-1 networking "cookbook" if one is ever written. John Haze K7VE was a recourse the rest was through trial and error. I am willing to share my rough notes (they are rough) with anyone that may be interested.
In the mean time I am looking to HamWAN and Broadband-Hamnet to handle high speed data transfer in Kirkland.
Bob Morrisson KE7JL Kirkland Emergency Communications Team
-----Original Message----- From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Bill Vodall Sent: Wednesday, April 30, 2014 5:37 PM To: Puget Sound Data Ring Subject: Re: [HamWAN PSDR] 44.x.x.x HamWAN network at Paine
So, you may wonder, why do I want to even screw around with the ID-1 radios in DD-mode? Because there are so few of them, and I have one on the air, and the SnoCo DEM has one on the air.
Another local EmComm group has 7 ID-1's that, AFAIK, aren't yet being used. Some of the folks there that I've talked to have mentioned propagation issues as the primary impediment.
I bet they'd be very happy to have a cookbook process in place where they could get on and connect with a node like Paine Field or set up one of their own.
73 Bill, WA7NWP
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
On 2014-05-01 10:53, Bob wrote:
4. ...I was told by ICOM, a few years ago, that the ID-1s could not be meshed. If the firmware could be reprogrammed to be compatible with Broadband-Hamnet, many of us may be willing to take the ID-1 off the shelf and get them on the air. 5. There are groups that have established links using ID-1s back to back ...
The most important thing to remember about two ID-1 radios communicating in DD-modes, is that they are*"a long Ethernet cable over RF."* That is all they are. If you have more than two ID-1 radios communicating in DD-mode, it is just like very long Ethernet cables connected to a common Ethernet hub. Note that I said an Ethernet "hub" rather than an Ethernet "switch". The distinction, while minor, is more appropriate considering "collisions". Further, the ID-1 radio is just about as stupid as a piece of Ethernet cable. So long as it encounters a properly formed *Ethernet* packet (not necessarily a TCP/IP packet), it will send it, and on reception, reproduce it, whether or not the packet contained garbage. This has two ramifications: Ramification #1: The architecture of your network is completely flexible, just like it is on the Internet. You can do anything you want. Caveat: you have to do it yourself with external equipment; the ID-1 will not do it for you. So, for any "use case" you want, you *must* (not should) design your network with just wires (eg, very long Ethernet cables). Then, when you are done, you "remove" the cable and replace it with two ID-1 radios. Just like the Ethernet cable in real life, there are certain limitations with the ID-1: 1. Line of sight; and 2. speed. So, what are the advantages of the ID-1 over wire? 1. Distance to the next hop; and 2. frequency agility (move away from competing traffic). Since the ID-1 can be remotely controlled, we are going to be experimenting with this capability to increase the utility of the ID-1 in DD-mode. In my opinion, asking the ID-1 to have /"firmware ... reprogrammed to be compatible with Broadband-Hamnet"/ is missing both the point and flexibility of the ID-1. Rather than have the software in the ID-1, you can have it in the adjoining box. What adjoining box? Well, what are you trying to do? Consider the "Universal Digital Radio" (UDRX-440) from "NW Digital Radio". Some buyers want it to be a complete "appliance" solution (eg, gateway, server, etc), and some just want it to be a "raw" radio. Well, with the ID-1 you don't get a choice: it's the raw radio. These days, little network devices (eg, Raspberry Pi) can be had for the price of an Icom programming cable (grin), and they can provide almost all the flexibility you need. Ramification #2: There is no privacy or security. I'm not talking about *data* privacy/security; amateurs already know that's part of amateur radio. I'm talking about *n**etwork***security. Just like the ten-mile fictional Ethernet cable you can run from your house to your friend's house, someone can "cut" into the cable at any point, and not only see what you are transferring, but also can add a fictional "hub" and access your entire network (unless protected; see below), just like anyone else in your house or local LAN. That includes files on your local computers, unless you have taken precautions. The Icom ID-1 manual rightly gives a strong warning about this in several places. Which brings me to configuration. In my opinion, the best way to set up an ID-1, is you keep your old "outdated" 10Mbps Ethernet routers (eg, Linksys BEFSR41 routers that were commonly issued by Verizon for DSL). You connect the LAN side to your home network, and the WAN side to the ID-1. This keeps the local LAN traffic off the air, and also provides network security via the built-in firewall in the router. OK, so you and your friend Joe each have your ID-1 radios set up this way, so what can you do? Answer: *nothing*. You have to have a network service available on one or both the of the local LANs that you want to *share* (and to the entire world), and so you "punch" a hole in your firewall device, to forward network traffic to your server. Your server better have all the security you need, or you are going to be in trouble, and I don't mean with the FCC ... If you think that the proper network and security design is too much work, then you should probably sell your ID-1, or just use it in voice (FM or DV) mode. I don't mean to be snippy, mean, or superior. These are exactly the issues that *anyone* running a proper service on the Internet has to face. The fact that it might be on a somewhat obscure portion of the Internet doesn't really provide any security. Even if you trust the amateurs you grant access to, doesn't mean that they have taken the proper security precautions in their home network's access to their regular Internet ISP. Some amateurs (not you; your friends ...) have a real capacity to think they know more than they do ... OK, OK, it sounds like a lecture. Sorry; I used to teach basic networking at the UW in Bothell. I'll end with this true story: Years ago, I found someone's mail server being used as an "open relay" (a common default configuration some twenty years ago) by some spammer. For some reason, I felt led to contact the administrator of the abused server, and he replied with much thanks. He told me that he had just installed Linux on a brand new server, using an IP address that had not been used before, and then went to breakfast before completing the server configuration. When he came back (about an hour later), his server had been discovered and was being used to send spam. "Obscurity is no security" -- Dean
Take a look at the CPIN network, in PA, it is fantastic. http://www.remoteamateur.com/ (Lower down the page!) Also the *Cambria Radio Club* has done fantastic work with Mesh. * * Keith KB3TCB On 4/27/2014 12:26 AM, Dean Gibson AE7Q wrote:
I have an idea to provide additional radio network connectivity to the Snohomish County DEM at Paine on 23cm, that would require one or two fixed 44.x.x.x IP addresses at the DEM, and one at my house (separate from my MikroTik radio), that would be accessible via the present 44.24.240.x connection to Paine (and perhaps any other 44.24.240.0/20 address). Both involve the use of two (or more) Icom ID-1 radios in D-Star DD mode.
Background: An Icom ID-1 in DD mode acts just like a piece of Ethernet cable (except that it is half-duplex and limited to a raw 128Kbps speed). No IP address is (or can be) assigned to the device. Any Ethernet packet reaching the ID-1's Ethernet port (whatever the content) is simply encapsulated and transmitted if the radio is in DD-mode. Similarly, any received data (properly encapsulated by another ID-1) is simply sent out the receiving radio's Ethernet port. The only radio configuration possible is to select a 23cm frequency and set the radio into DD-mode. Most of these actions can either be done by the radio's control head, or via a USB port "connected" to a Windows PC running Icom's control software for the ID-1. This prior sentence is important in the following discussion.
As an aside, the transmission of an ID-1 can be addressed to and received by a D-Star DD-mode "repeater" module, routed via the D-Star network over the Internet to another such "repeater" module anywhere in the world, and retransmitted over the air to a receiving ID-1 radio. This mechanism, while perhaps interesting, is not the subject of this eMail. I only mention it so as to avoid confusion.
In scenario #1 for the ID-1 that already is installed at the Snohomish County DEM:
1. The Ethernet port of the ID-1 is directly connected to a switch at the DEM that is on the 44.24.240.x network. In this mode, any packets received over-the-air by the ID-1 are injected into the local 44.24.240.x network, and are routed in exactly the same manner as from any other device hard-wired to the 44.24.240.x network at the DEM. Further, any Ethernet packets seen by the ID-1 (whether intended for radio transmission or not), would be transmitted by the ID-1. 2. Another ID-1, located (say) at my house would be connected to a router, which would act as though it were directly connected to the 44.24.240.x network at the DEM.
I don't view the above scenario as a good idea. For one thing, the indiscriminate transmissions from the DEM of unrelated 44.x.x.x packets doesn't seem like a good idea. For another, there is no security. So, that brings me to scenario #2:
1. At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. 2. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM.
Now, here is the wrinkle (to both scenarios): The ID-1 at the DEM is currently in VERY LOW utilization, being (as so far as we know) only able to contact my ID-1 (in either digital data or voice mode), and the two 23cm D-Star K7LWH repeater modules (one voice, and presumably one data) in Bellevue. Also, the ID-1 also supports normal FM voice mode, and is easily able to hit with one watt (from both the DEM and my house) the KB7CNN 23cm FM repeater on East Tiger Mountain. So, it would be nice to use the DEM's ID-1 radio in different modes, as needed, and switch modes or frequencies REMOTELY as desired. The solution to this the use of a Digi "Anywhere/5" (or "/2") Ethernet-to-USB box (I have several). With the installation of Digi drivers on any Windows PC, these allow a PC anywhere in the world to connect over the Internet to a Digi box and have access to several remote USB devices (including any connected USB hubs). In particular, the USB control port of an ID-1. In fact, this is how I control my ID-1 at home: this allows me to control the ID-1 from any Windows PC.
Hence the desire for a fixed 44.24.240.x IP address for the Digi box at the DEM, allowing REMOTE control and configuration of the ID-1 when the Internet is not available. While the Digi box can be connected to any network at the DEM, it seems most productive to connect it to the 44.24.240.x network there, allowing remote configuration and control of the ID-1 in an Internet outage (this can be disabled by unplugging the ID-1's USB port). Unfortunately, the Digi USB boxes are only usable from Windows systems (Digi's remote SERIAL (RS-232) port boxes are supported not only on Windows from 98 on, but on most variants of Linux ...).
Yes, this provides a much slower connection to the DEM than the MikroTik radios, but doesn't have quite the strict line-of-sight issues that 5cm does, and thus permits some mobile access.
To Scott Hokaker:
I am willing to provide a Digi "Anywhere/5" box on permanent loan (or perhaps donation) to this project. I also have a couple of consumer-grade routers (Linksys BEFSR41, Netgear WGT624v2) that are similarly available, if they are suitable.
Comments welcome!
-- Dean
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
participants (10)
-
Bart Kus -
Bill -
Bill Vodall -
Bob -
Dean Gibson AE7Q -
John D. Hays -
John Hays
-
Scott Honaker -
Steve -
Tom Hayward