Here is my list of forwarded ports.

Now, yes, some are for other things (email, AGW/Winlink, IRC, etc) but from 5000 down is what I could find for VoIPoM.

80   to my webserver
25     \
110   to my POP3 email server
587    /
8000  AGW/Winlink packet station
6667  IRCd on localnode
2003  OLSR Dot Draw from localnode to "Visual Of A Mesh Node" topology page on this website
5000  3CX
5004  "
5060  "
5061  "
5090  "
5480  "
5482  "
5483  "
5485  "
5487  "
7000-7500  "
9000-9019  "
10000-20000  "

Seems like overkill, huh? :-) But you can see why it SHOULD be easier to do it this way than try and change from NAT to 1/5/13-DMZ, since this one node does multiple routing to my LAN and other stuff.

I have even tried listing that 3CX PC in the local DMZ pulldown.

Nada

KTF

Sounds like the RTP ports are being blocked somewhere.  TCP is used for the control channel, and UDP is used for the audio channel, using the RTP protocol.

There is a firewall somewhere blocking the ports (Usually 10000-20000/UDP).

However, you can also use the "VPN Free" feature of 3CX to make it a bit simpler.  It wont work with the ATA however (It'll work with the 3CX client softphone).

Has anyone got 3CX working over HSMM-MESH "WITHOUT" doing just 1/5/13-DMZ nodes?

I just started into VoIPoM, and have 3CX on a XP-Pro box with its own 3CX softphone, a 3CX softphone on MY personal PC, and 1 grandstream adapter.

I got it all setup and working on the LAN, but then when I moved the ATA over behind a mesh node (my LAN is tied to my mesh), I can RING the ATA from the softphones, but get no audio either way. If I try to call either softphone from the ATA, I get a busy signal, even though all 3 show registered.

I have mapped numerous ports and ranges on both the LAN gateway and the node at the ATA, but same issue. I feel like im missing a port somewhere or something.

Any clues/hints/tricks?

One thing I am doing, (since Im just starting to build it) is when I create extensions, I am using the last 3 characters of a callsign to get the numbers -- k5KTF=583, kd5MFW=639, nG5V=458, etc-- so we shouldnt need a phone directory as long as you know their callsign. :-)

(I thought it was ingenious :p )

Any suggestions to fix the porting/etc is always appreciated.

73

Jim

K5KTF

Hi Corey!

It would be great if someone would port to as many router platforms as we can, it would make it much easier for people to get into hsmm-mesh.   I'm happy with the linksys hardware, but it won't last forever.

Good question. I don't believe that you MUST change the crystal, but do so would make your router more ham band friendly.

Hi Rusty, I wasn't saying your changes were bad or anything like that. Generally endian fixes are good things, though I haven't looked at the changes so I don't really know :). I was offering to add some type of backwards compatibility to the software.

Backwards compatibility is not that hard to accomplish with a little forethought. I've done it before. You generally need a version number in the protocol and a policy to ignore reserved fields and write reserved fields as zero. And you need a way to discover the latest version another system supports. Then newer versions can know how to handle older version of the protocol and "do the right thing".

I don't know where the Microsoft comment came from. Microsoft and Intel are *insane* about backwards compatibility. I can take software that is almost 30 years old and run it on current versions of Windows. Windows 7 has explicit backwards compatibility settings. If they didn't, nobody would buy new versions of their software.

You may not need backwards compatibility now, and maybe forcing people to upgrade at this point is the best way, but you need to be thinking about this for the future. Once you hit a critical mass, if you don't have a way to move forward with backwards compatibility, then you will never be able to change anything.

My main comment, though, was not about backwards compatibility. I was looking for information about the software required to set up a MESH node, how to configure it, and how the software works together. I couldn't find anything like that. Maybe it's there and I just can't find it. For instance, searching the wiki doesn't turn up anything for "security plugin". With that type of information, I could look at compiling and getting the software running on the Keebox.

I do have a WRT54GL and I have the MESH software running on it. However, it doesn't do much by itself :). I was hoping to get the software and compile it on the Keebox and play with it that way.

Thanks,

-corey

Corey,

First off, the problem is not so much with 'olsrd', per se, but in the
secure plugin. The version of the secure plugin that we're currently
using is not sending packets with the data in the correct byte order for
SOME of the fields nor is it doing the checksums on some incoming packets
the same way they were done at transmission. I corrected those issues.
The OLSR group has my code and it's readily available. If this code
were to be used then any combination routers with different CPU types
of any byte-ordering could join the mesh if they use the secure plugin.

Secondly, to me, the real SOLUTION would be to simply discontinue usage
of the secure plugin. This is just my opinion, not necessarily that
of the HSMM-MESH group. It truly doesn't do anything to "secure" the
mesh when the key is so readily available. It seems to me as more of a
"secret handshake" that you need to get into the club (or the mesh).
Also, the issue could be fixed with a minor release of the HSMM-MESH
firmware -- an update that would remove its usage.

Now for what it's worth, a reminder that HSMM-MESH went through a similar
incompatible change when the firmware went from version 0.3.x to 0.4.0.
Yeah, there was some bitching and moaning but that's the ham community
in general (probably just human nature too :-). I think we can live
with another change like that especially if it means that Bullets and
other non-WRT54G routers (amongst other) could more readily become part
of our meshes as well.

As for your Keebox -- it looks interesting. I don't see why you couldn't
just take our current firmware and possible add a driver for the Ralink
chip (if it's not there already) since everything else would make it a
compatible router for the mesh. The WRT54G family of routers are also
based upon MIPSel-style processors so the secure plugin issue should
be a non-issue, old code or not, if you ported our firmware to run on
your Keebox.

I'm sorry you feel that my corrections weren't good ones because they
didn't maintain backwards compatibility. I don't believe in perpetrating
the bug. The code was wrong, plain and simple, and the bug manifested
itself when routers of different byte-sexes attempted to mesh together.
Definitely not something we're aiming for because the HSMM-MESH group
would really like to port (or have someone port) our firmware to other
routers.

How could it be made backwards compatible? I'd like to hear your ideas.
I'd be surprised if there was a truly compatible fix. Still, we're not
even at a 1.0 version yet and I believe this project needs to continue
to grow. Backwards compatibility is NOT always the best thing to do.
Look what Microsoft did with all those versions of DOS and Windows.
We don't need to keep looking back during development. Like I said,
we're not even at version 1.0 yet.

As to what software a router needs to run to become a mesh node...
I pretty much discussed this at our last Digital Tuesday meeting in Lucas.
The OLSR daemon and the same set of plugins would be a start. This gets
everything routed around the mesh as well as to the nearest gateway.  
Advertising services available at the node or some of its LAN hosts and
accessing and monitoring the mesh are more features available.  Having
a common user interface really helps too!

Seriously, I would strongly suggest you get a WRT54G, GL, or GS,
or two or three, follow our instructions and get the firmware loaded,
do the setup, and ssh into the box and poke around.

That's all for now...  You might want to visit our next Digital Tuesday
meeting in Lucas.  Check out the DAWG-MESH mailing list on Yahoo groups!

73

    -Rusty-

I'm relatively new to the HSMM world, but I've been watching for a while.  I'd like to get started.  I've noticed that the particular routers for this are rather old and tend to be expensive and hard to get.  I do have one WRT54GL, but I have a few others.

I do have extensive Linux embedded experience, so I'm quite comfortable with that.  I have OpenWRT running on a little router by Keebox ($25 at Frys) that has 4MB FLASH and 32MB RAM with a Ralink RA3050F chip (mipsel toolchain).  It's working quite nicely.  (And this router is really nice because it's almost impossible to brick.  It has an emergency recovery mode coded into ROM, so no matter what you do, you can recover.)

So, I would be happy to get HSMM-MESH working on it.  I have read that there are endian issues with the oslrd software, but those have been fix in an (unfortunately) non-backwards compatible way.  I could modify oslrd to add a "backwards compatibility" mode if people haven't already moved to the new version.

Also, it is not clear what software needs to run on the router to make it a node.  Is it just oslrd?  What is the configuration?  How are the networks bridged?  I don't seem to find any documentation on it.  I suppose I could reverse engineer on the WRT54GL, but it would be a lot nicer if I was just missing where the documentation was.  If I did this, I'd be happy to write some docs on it.

Thanks,

-corey - AE5KM

Here is an interesting link for different hardware and amateur use.

http://www.qsl.net/kb9mwr/projects/wireless/modify.html

Hi Everyone,

http://i296.photobucket.com/albums/mm177/kirin_70/IMG_0074.jpg