9 Jun
2012
9 Jun
'12
8:43 p.m.
Hi,
I've got two machines running here on the, 44.155.6.225 and
44.155.6.226. I'd appreciate if someone on the 44-net could just check
they can reach 44.155.2.226 for me please (it could be slow, machine is
going an apt-get update at the moment).
Also, would anyone be in a position to tell me what the best wireless
mesh protocol to use is at the moment. These are two Icom ID-1 D-star
radios. I've two more that two local hams are going to put running for
me on high points and I'd like to run something 'mesh' on the nodes to
allow me to get back to the gateway (225) from anywhere within range of
any three?
Regards
John
EI7IG
9 Jun
9 Jun
8:59 p.m.
There are two common protocols that I have used:
Olsr and open mesh (aka batman)
Both are well documented.
As far as the uhf radio cards, there are two known sources:
Xagyl communications and Doodle Labs.
According to the FCC we can run up to 10 watts in spread spectrum emission types on UHF
70cm encompassing no more than 5mhz. I am not sure of the emission type identifier
needed.
The cards from doodle labs are 200~250 us dollars.
As there is a 5mhz limit you are looking at about 5mbits of speed.
Unsure if this is "legal" in the us though. Maybe a call to the FCC office or a
nice letter as there was a bandwidth limit for
Digital emissions of 56k if I am not mistaken.
Couple it with something like a router board from ubiquiti and build a mesh and you are
killing the price of dstar with more bandwidth. Use speak freely on a multicast address
and you have hd digital voice! Point to multi point!
73 de KD5JFE
Elias
9:22 p.m.
On 09/06/12 20:59, Elias V. Basse III wrote:
(Please trim inclusions from previous messages)
_______________________________________________
There are two common protocols that I have used:
Olsr and open mesh (aka batman)
I remember OLSR ok.. the other is new to me
Both are well documented.
Ok, thanks,
Any reason to use one over the other?
Regards
John
EI7IG
9:32 p.m.
Hi John,
Working from public internet address.
Not working via direct tunneling.
-----Original Message-----
I've got two machines running here on the, 44.155.6.225 and 44.155.6.226.
I'd appreciate if someone on the 44-net could just check they can reach
44.155.2.226 for me please (it could be slow, machine is going an apt-get
update at the moment).
Regards
John
EI7IG
9:46 p.m.
On 09/06/12 21:32, Marius Petrescu wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Hi John,
Working from public internet address.
Not working via direct tunneling.
-----Original Me
Hmm, ok thanks, not sure of your IP. I'm using rip44d, so I thought it
would have had everyones routes.
Thanks
John
EI7IG
10:50 p.m.
Hi John,
I tested from 44.182.21.1 via tunnels, and from a remote server I have
access to for the internet only connection (this tunnels via amprgw).
73s de Marius, YO2LOJ
10 Jun
10 Jun
12:13 p.m.
On 09/06/12 22:50, Marius Petrescu wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Hi John,
I tested from 44.182.21.1 via tunnels, and from a remote server I have
access to for the internet only connection (this tunnels via amprgw).
73s de Marius, YO2LOJ
Ok, no worries,
I'd forgotten my gateways entry password, so Jim kindly deleted it for
me, So I have re-created it, changed the tunnel end-point and rebooted
the machine as I was messing with the routing last night.
It should stabilize in the next while. I'm getting the routing updates
from 44.0.0.1 via rip44d and I've a populated routing table, and any
'pings' I send out are going via the tunnel device.
Regards
John
EI7IG
2:21 p.m.
Still not working via direct tunnel.
Your pings may go out via tunnel, but if someone pings you, your ping
replies must go out via tunnel, too.
Without special care, reply packets go out via 44.0.0.1 or are NATed via
default gateway - both cases which don't work.
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of John
Ronan
Sent: Sunday, June 10, 2012 14:13
To: AMPRNet working group
Subject: Re: [44net] Quick Test Request
Ok, no worries,
I'd forgotten my gateways entry password, so Jim kindly deleted it for me,
So I have re-created it, changed the tunnel end-point and rebooted the
machine as I was messing with the routing last night.
It should stabilize in the next while. I'm getting the routing updates from
44.0.0.1 via rip44d and I've a populated routing table, and any 'pings' I
send out are going via the tunnel device.
Regards
John
EI7IG
3:44 p.m.
On 10/06/12 14:21, Marius Petrescu wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Still not working via direct tunnel.
Ok, long story shortened. For some reason I was trying to use tunl1
device, search and replaced tunl1 with tunl0 and it's all started
working, not entirely sure why, but I'll leave that for another day.
root@mini-itx:~# ping 44.182.21.1
PING 44.182.21.1 (44.182.21.1) 56(84) bytes of data.
64 bytes from 44.182.21.1: icmp_seq=1 ttl=64 time=91.6 ms
64 bytes from 44.182.21.1: icmp_seq=2 ttl=64 time=90.3 ms
Thanks
John
EI7IG
6:03 p.m.
Excelen John,
Working now 100% both from internet and from tunnel :-)
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of John
Ronan
Sent: Sunday, June 10, 2012 17:45
To: AMPRNet working group
Subject: Re: [44net] Quick Test Request
Ok, long story shortened. For some reason I was trying to use tunl1 device,
search and replaced tunl1 with tunl0 and it's all started working, not
entirely sure why, but I'll leave that for another day.
9 Jun
9 Jun
10:12 p.m.
Hey John, I've tried to telnet to both addresses and get the same result on
both...unreachable protocol
This is from the linux trace screen....
21:11:16.086099 IP 192.168.1.150 > 83.71.213.122: IP 44.135.90.2.3970 >
44.155.6.226.23: S 1402888192:1402888192(0) win 2048 <mss 512>
(ipip-proto-4)
21:11:16.225955 IP 83.71.213.122 > 192.168.1.150: ICMP 83.71.213.122
protocol 4 port 44 unreachable, length 72
73, Don - ve3zda
-----Original Message-----
From: 44net-bounces+ve3zda=gmail.com(a)hamradio.ucsd.edu
[mailto:44net-bounces+ve3zda=gmail.com@hamradio.ucsd.edu] On Behalf Of John
Ronan
Sent: Saturday, June 09, 2012 3:43 PM
To: 'AMPRNet working group'
Subject: [44net] Quick Test Request
(Please trim inclusions from previous messages)
_______________________________________________
Hi,
I've got two machines running here on the, 44.155.6.225 and
44.155.6.226. I'd appreciate if someone on the 44-net could just check
they can reach 44.155.2.226 for me please (it could be slow, machine is
going an apt-get update at the moment).
Also, would anyone be in a position to tell me what the best wireless
mesh protocol to use is at the moment. These are two Icom ID-1 D-star
radios. I've two more that two local hams are going to put running for
me on high points and I'd like to run something 'mesh' on the nodes to
allow me to get back to the gateway (225) from anywhere within range of
any three?
Regards
John
EI7IG
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
10 Jun
10 Jun
12:35 a.m.
Just a word here.
D-STAR Digital Data as implemented by Icom uses the D-STAR Frame for
routing on air and from gateway to gateway. So you will want to test
before deploying a network in a mesh environment.
I'm not sure if ID-1s treat UR:CQCQCQ as a broadcast for DD, thus enabling
an IP payload to transparently go to multiple receivers. I don't know the
answer, but I'd test well. The test could be performed with two ID-1s on
DD simplex (not RPS) and setting both to UR:CQCQCQ and try to pass traffic.
The payload is Ethernet frames, so it should just act as an Ethernet
bridge over RF if the CQCQCQ D-STAR address functions as broadcast.
The protocol itself is ambiguous on this point.
Copied to D-STAR_23cm(a)yahoogroups.com
------------------------------
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, Jun 9, 2012 at 12:43 PM, John Ronan <jpronans(a)gmail.com> wrote:
(Please trim inclusions from previous messages)
______________________________**_________________
Hi,
I've got two machines running here on the, 44.155.6.225 and 44.155.6.226.
I'd appreciate if someone on the 44-net could just check they can reach
44.155.2.226 for me please (it could be slow, machine is going an apt-get
update at the moment).
Also, would anyone be in a position to tell me what the best wireless mesh
protocol to use is at the moment. These are two Icom ID-1 D-star radios.
I've two more that two local hams are going to put running for me on high
points and I'd like to run something 'mesh' on the nodes to allow me to get
back to the gateway (225) from anywhere within range of any three?
Regards
John
EI7IG
______________________________**___________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/**mailman/listinfo/44net<http://hamradio.ucsd.e…
11:57 a.m.
On 10/06/12 00:35, K7VE - John wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Just a word here.
D-STAR Digital Data as implemented by Icom uses the D-STAR Frame for
routing on air and from gateway to gateway. So you will want to test
before deploying a network in a mesh environment.
I'm not sure if ID-1s treat UR:CQCQCQ as a broadcast for DD, thus
enabling an IP payload to transparently go to multiple receivers. I
don't know the answer, but I'd test well. The test could be performed
with two ID-1s on DD simplex (not RPS) and setting both to UR:CQCQCQ
and try to pass traffic. The payload is Ethernet frames, so it
should just act as an Ethernet bridge over RF if the CQCQCQ D-STAR
address functions as broadcast.
The protocol itself is ambiguous on this point.
Actually it does, which I've found out experimentally in the past.
Regards
John
EI7IG
7:35 p.m.
John,
Thanks for the confirmation, I didn't have the radio to test. Good news.
------------------------------
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, Jun 10, 2012 at 3:57 AM, John Ronan <jpronans(a)gmail.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On 10/06/12 00:35, K7VE - John wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Just a word here.
D-STAR Digital Data as implemented by Icom uses the D-STAR Frame for
routing on air and from gateway to gateway. So you will want to test
before deploying a network in a mesh environment.
I'm not sure if ID-1s treat UR:CQCQCQ as a broadcast for DD, thus enabling
an IP payload to transparently go to multiple receivers. I don't know the
answer, but I'd test well. The test could be performed with two ID-1s on
DD simplex (not RPS) and setting both to UR:CQCQCQ and try to pass traffic.
The payload is Ethernet frames, so it should just act as an Ethernet
bridge over RF if the CQCQCQ D-STAR address functions as broadcast.
The protocol itself is ambiguous on this point.
Actually it does, which I've found out experimentally in the past.
Regards
John
EI7IG
4345
days inactive
4346
days old
13 comments
5 participants
participants (5)
-
Don -
Elias V. Basse III -
John Ronan -
K7VE - John -
Marius Petrescu