[HamWAN PSDR] 44.x.x.x HamWAN network at Paine

[Dean Gibson AE7Q]

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 at ae7q.com 
>>>>> <mailto:hamwan at 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 at 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 at hamwan.org
>>>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>>
>>>
>>>
>>> _______________________________________________
>>> PSDR mailing list
>>> PSDR at hamwan.org
>>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>
>>
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org
>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20140428/6551e230/attachment.html>