Tried to search for this but came up empty, so sorry if it has been asked over and over again.

At one time I had my RasPBX and Cisco 7940 phones working just fine.  But now, trying to move from a Linksys router hosting the PBX to a Ubiquity router I seem to have overlooked something.

I've watched both of Paul's, KF5JIM, videos on configuring the node and the phone (same RasPI, just a different IP address) and have changed the SIPDefault.cnf file to have the correct proxy address (in both places) and the phone's TFTP server address.  The phone also shows the RasPBX address for HTTP server and port 80.

What am I over looking?

Or was it like this on my previous setup and I've just forgotten I was getting this error message?  I'm asking this question because even though I'm getting the message, things seems seem to be working.

And one last comment.  I've seen several references to forwarding port 5060, but have seen anything definitive about that.  Some of the instructional videos and "How To" articles really ought to get updated more often.

Any and all help appreciated,

Steve G./N4TTY

I don't believe that this is possible but the post I found is pretty old. 

https://supportforums.cisco.com/document/15276/how-dial-ip-address-cisco-sip-ip-phone

Bottom line(literally), feature not supported.

Hi Bob,

KE8AVJ@arrl.net

Thanks again

Update: I did the presentation and it went over well. I think I have drawn some interest. Thanks again!

I need email address for w8iss and ke8avj and anyone else who requests info.

Bob W8ERD   w8erdbob@gmail.com

Hi,

I would love to get a hold of your slides. I would like to do a presentation on BBHN for my club.

Thanks,
KE8AVJ

Thanks for the help with your node!

We have some pictures of the booth, but I don't recall seeing you in any of them.

I will send you my slides, which describe the mesh/ham crossband repeater.

Bob W8ERD

I was that 'ham' that helped out with setting up a new link from the ball arena to the north hall.

Linksys router with a 13db (I think) vertical attached directly.

Wondering if anyone took any pictures of the booth and anyone that came by? Would like to

have a copy of one with my backpack bbhn-camera that I was walking around with most of

dayton weekend.

Also would like to get a little more info about the 2m/70cm to bbhn setup if possible.

Had a good time down there this year. Looking to show up next year with a better high

power 2.4 and 5GHz setup. Looking at having a camera in the car when parked in the parking

yard across from Hara arena.

James W8ISS

It does use port 5525.  The client is initiating an outbound connection though, so, no INBOUND firewall rules on your "internal" network needs to be set.

On the server, it ACCEPTS incoming requests on 5525 and DOES need to port forward 5525 to your tunnel server.

Also, yes, the naming must match exactly (case-sensitive).  This is a known issue and will be corrected in the next release of the tunnel solution coming soon.

Here is the report on our mesh activities at the Dayton Hamvention, written by the main mover Bill Curtice WA8APB, of Dayton.  The Dayton mesh group did a wonderful job of installing all the infrastructure and making all the arrangements. 
I agree with Bill on all points, although I suspect the use of Horizontal polarization had a significant effect on our success.

I was unable to send attachments, which would be Bill and my slides, plus the hamvention map showing the node placements. I will send them to anyone who requests them.

Bob W8ERD

Begin forwarded message:
From: "WA8APB - Bill Curtice" <wa8apb@arrl.net>
Subject: Report on Mesh at Hamvention
Date: May 27, 2015 at 11:33:53 PM EDT
To: "'WA8APB - Bill Curtice'" <wa8apb@arrl.net>

To:  The Miami Valley Mesh Alliance Following is the report on Mesh at Dayton Hamvention

Bottom Line:

Technically, our mesh was a success.  Our Ubiquiti nodes did prevail over the thousands of interfering WiFi noise sources, demonstrating that mesh can be made to work in the worst of all possible environments.  Likewise, the Mesh Networks booth was a success, attracting an almost constant flow of Hams.  On the down side, our Linksys nodes failed to survive the onslaught of WiFi, and we came up short in demonstrating applications of the mesh network.

The Booth:

Interest and traffic at our booth exceeded our wildest expectations.  I was especially impressed with the number of “senior” hams who came to the booth seeking information and understanding.  I thought most interest would come from young hams; that was not the case.  I would guess that most inquiries came from hams licensed in the ‘60s and before; they wanted to know about mesh, and they wanted to get information they could present to their clubs at home.  Over 116 people provided email addresses, asking us to forward our TAPR Forum mesh presentation slides.   This was very encouraging.  Unfortunately, we were so busy keeping up with booth traffic, we didn’t have time to even get our booth totally set up… or to launch Larry’s “MeshMobile”, to set up Bob Dixon’s PTZ camera, or even to get working telephones deployed across the mesh.  Bob Dixon did demonstrate his “portable telephone company”, an integration of Mesh, WiFi, and UHF/VHF Communications capabilities.   I originally thought of Larry’s MeshMobile as a way to raise interest in mesh, and to solicit or drive traffic to our booth…. fearing that things might be a bit lonely in that corner.  Was I ever wrong; we had strong booth traffic from the get-go.  Our booth staffing levels were not adequate for the traffic (and interest) we experienced.

The Mesh Network -- We installed:

·        L-Com HG2409 2.4GHz Omni-Directional Horizontally Polarized wave-guide antennas with Ubiquiti Bullet M2HP radios located:o   Outside:§  On the 45 foot tower located on the north side of the East Hall§  Outside, on the DARA Communications Van Masto   Inside the East Exhibit Hall§  At the Mesh Networks Booth, located in the south-east corner of the hall, near the main East Hall Entrance§  Hanging from the East Hall Ceiling, room center·        Linksys 2.4 GHz Nodes (with antennas horizontally polarized, some with after-market 7dbi or 9dbi antennas), located:o   In the Food Court area, on window sills common to the North Hall (three units)o   On top of a wall ledge bordering the permanent food court sales area (east end of the food court)- one unito   Above the drop ceiling in the BallArena and Silver Arena (7 units)o   At the Mesh Networks Booth, to support client laptop display computers (3 units)·        Ubiquiti 5.8 GHz NanoStation nodes (60 degree beam width):o   At the Mesh Networks Booth, pointed toward the food courto   At the west end of the Food Court, pointed toward the mesh booth·        A fixed-view TV Camera (1080p, 4 fps) on the East Hall tower, overlooking the Flea Market.  The camera was direct connected to a Linksys Node, at the Mesh Booth. ·        Ubiquiti nodes on the tower and in the East Hall were direct-connected with an Ethernet switch located at the Mesh Networks Booth

We Learned:

• Channel 1 (2.4 GHz) was never 100% saturated; I measured it as high as 85% during crowd peak periods.
• Signal to Noise Ratio measurements were made from various points in the East Hall, Food Court, North Hall, BallArena, and Silver Arena.  The Fluke AirCheck meter used enabled us to independently measure S/N ratios for each node.  We found:  
  • The Ubiquiti nodes with high-gain antennas (both 2.4 GHz and 5.8 GHz) had very high S/N ratios, even at crowd peak ..... 40-60 db.
  • The S/N Ratio of the Linksys nodes did not fare as well, measuring 14 to 44db at crowd peak.
• The three East Hall Ubiquiti nodes (located at our booth, hanging from the East Hall ceiling, and on the outside tower on the north side of East Hall) were “hardwire direct connected”.   From any of them, we could see all 23 of our nodes on the mesh status screen at the start of each day.   All Linksys nodes were RF-connected only.
• By mid day, all the low power Linksys nodes in the BallArena and Silver Arena disappeared from the mesh status screen.  While the Fluke AirCheck showed they were still running ...... it appeared the link between the Linksys nodes and the Ubiquiti nodes in East hall was broken.  I believe links to the Linksys devices were overwhelmed by WiFi interference.  The following experiences support this belief.   
  • As an experiment, a visiting ham placed an additional Linksys node in the gap, between a BallArena Linksys Node and its closest Ubiquiti neighbor, causing most of the Linksys nodes to reappear on the central mesh status screen.   The ability of this link to bear traffic (bit rate) during peak crowd time was not measured.
  • KD8RBP, Seth, attempted to run traffic over the mesh from the National Traffic System booth located in the ARRL Area of the BallArena, to the Preble County Communication Van.  Seth was using a 2.4 GHz NanoStation.  The path was from his node, to the Linksys nodes located above the ceiling in the BallArena, to the Ubiquiti nodes in East Hall, to the Ubiquiti tower node, to the DARA Van Node, to the Preble County Trailer.  The mesh connection failed, when the link between the BallArena Linksys nodes and the East Hall Ubiquiti nodes failed.  Seth subsequently attempted to pass traffic from the Mesh Networks Booth in East Hall; that worked, and he was able to successfully remote control an HF transceiver in the Preble County Van.  I believe Seth’s experience is consistent with our experience with the Linksys nodes.
  • The Linksys nodes in the BallArena and Silver Arena were in close proximity to one another ...... and it appears they did function together as a mesh even at crowd peak, even though they became disconnected (isolated) from the East Hall Ubiquiti nodes.
• The 5.8 GHz mesh was never challenged .... no competing stations and no band loading.   The 5.8 GHz NanoStationlocated at the Mesh Networks Booth was “direct-connected” to the 2.4 Ubiquiti nodes.  It backed-up the 2.4 Ubiquiti nodes, and assured a workable, 5.8 GHz high speed communications channel throughout the East Hall and Food Court areas, regardless of what happened on 2.4 GHz.    Measured S/N ratios for the 5.8 Nodes were consistently high, above 40 db.  Unfortunately, we failed to field any clients that took advantage of the 5.8 GHz mesh (the MeshMobilewas intended to do this….).
• Outside, it appears our 2.4 Ubiquiti nodes (on the East Hall tower and on the DARA van mast) were never challenged; we measured high S/N ratios in the Flea Market, and in the vendor/staff parking areas, during crowd peak.
• In a sense, this experience supports the concept of deploying architecture with central Ubiquiti nodes supporting low power nodes around them.  I believe we would have a stronger mesh were we to put a Ubiquiti node in the center of each room.  Do away with using Linksys nodes placed as “Infrastructure”.... and instead use them as mesh gateways, on the floor, enabling people to connect to the mesh.  Maintain mesh integrity using the Ubiquiti node infrastructure across the complex.
• We planned to use proximity, power, and (horizontal) polarity to prevail over interfering WiFi signals.  I now believe “power” (on both 2.4 Hz and 5.8 GHz), the high gain antennas, and the higher receive sensitivity of the Ubiquiti nodes, ruled the day.  Proximity (and density) works, but only if it is high enough that you have no weak links.  The impact (or value) of horizontal polarization was not measured.
• Another lesson learned concerned the Cat5e Ethernet cable used to connect the node and camera on the East Hall tower to the Mesh Networks booth.  We initially installed low-cost copper-clad aluminum (CCA), 24 ga, shielded, twisted pair wire.  The cable tested OK using an Ethernet test device.  We used this wire successfully on other installations, at distances of up to 120 feet.  At Hamvention, we encountered problems with both Power over Ethernet, and with signal transmission, for the Ubiquiti node and the IP Camera located on the East Hall Tower.  Wire length was approximately 200 feet.  We tried moving the PoE units to the tower… and found we could power the devices in that way, but still could not copy digital data at the mesh booth.  Our problems were resolved only when we removed the CCA cable, and installed solid copper, 23 ga, shielded, twisted pair Cat6e cable.
• Unfortunately, we failed to comprehensively demonstrate “Applications” of the mesh.  Bob Dixon’s demonstration of the integration of Mesh, WiFi, and UHF/VHF communications shined there, but otherwise, we had little to show that we were actually using the mesh to do something… to make something happen.  Only the tower camera video was available on the mesh; KD8RBP’s NTS link failed, we did not deploy the MeshMobile (roving scooter with 2.4 and 5.8 nodes active), nor did we take time to deploy telephones!  We had plans addressing these areas, but failed to follow through when we were consumed with booth traffic.

The TAPR Forum:

Bob Dixon (W8ERD) and I presented Mesh at the TAPR Forum on Friday Morning; I believe the presentation was well received. I gave a brief introduction to mesh, after which Bob demonstrated (both at the Forum and at our booth) how UHF/VHF, Mesh, and WiFi technologies can be used together by Hams to deliver emergency communications significantly exceeding anything routinely done today.  Perhaps more significantly, his work in no way diminished or dismissed the value of technology or capability Hams have deployed for years; rather, he showed how new technology can leverage existing skills and capabilities to greatly improve the service we offer.  He caught the attention of many that took the time to look or inquire.  Narrated presentation slides are attached to this email.

Surplus Wireless Gear Inc.:

Surplus Wireless Gear Inc., of Olyphant, PA (near Scranton), (www.swginc.net) accepted our invitation to exhibit in a booth adjacent to our Mesh Networks booth.  It was their first time at Hamvention.  They offered used Ubiquiti equipment for sale, as well as other gear.  As far as I know, they were the only inside exhibitor offering broadband wireless equipment at Hamvention.  They advised us that they sold out of the more popular Ubiquiti items the first day (Bullets, etc.), and were taking orders for fulfillment from their home base.   As they were leaving, they mentioned to me that they definitely wanted to return next year, and would like to have more booth space.  I believe this was a good experience for them, and also think their presence was good for mesh, good for Hamvention, and good for Ham Radio.

Thank  You….. to All Who Made This Happen!

We owe many thanks to all who made mesh happen at Hamvention; those who supported the planning, those who loaned equipment, those who helped install (and remove) our gear, and those who staffed the booth.  We also thank the Hamvention organization, and Hara Arena, for their kind support.

A special vote of thanks is owed to Larry Baker, KB8EMD; he was at Hara Arena almost every day, all day, the week before Hamvention to support equipment install and troubleshooting.  Many others gave of their time generously as well…. and that is very much appreciated!!

Conclusion:

All said, I think we learned much…… have much to think about….. and much more to learn.

73

Bill

Bill Curtice - WA8APBHome: 937-426-7082Cell: 937-287-0871Text:  937-234-7975Skype: williamcurtice

Greeting, I have numerous wrt54g routers that I did K5KTF's USB mod on; they all performed flawlessly in version 1 then I upgraded to release version 3.1. I have followed the same steps of getting the USB sticks recognized then moved the OS over to the sticks using K5KTF's instructions on this board at http://www.broadband-hamnet.org/applications-for-the-mesh/116-move-os-to-usb-storage.html everything seems to work accept name resolution. I can access the node and other mesh nodes using IP, but not by node names when ethernet connected to the node with the OS moved to usb. I can however access the node with os on usb from other nodes using it's name and even go through it to other mesh nodes by name when I have accessed the questionable node from another node. I have looked all over for differences but can't seem to find what the problem is. Any help would be greatly appreciated. I created the following file /etc/init.d/mountusb and it's startup in /etc/rc.d

#!/bin/sh /etc/rc.common EXTERNAL_PARTITION=/dev/scsi/host0/bus0/target0/lun0/part2

START=41

start () { echo "loading USB and ext2 modules"

for module in usbcore usb-ohci uhci ehci-hcd scsi_mod sd_mod usb-storage jbd ext2; do

insmod $module

done

sleep 2s

[ "$FAILSAFE" != "true" ] && [ -b $EXTERNAL_PARTITION ] && {

mount $EXTERNAL_PARTITION /mnt/root

[ -x /mnt/root/sbin/init ] && {

mount -o move /proc /mnt/root/proc && \ pivot_root /mnt/root /mnt/root/mnt/openwrt && {

mount -o move /mnt/openwrt/dev /dev

mount -o move /mnt/openwrt/tmp /tmp swapon /dev/scsi/host0/bus0/target0/lun0/part1

}

}

}

}

-----------------------------------------------------

Also here is the results of the CLI 'mount' command

root@AF7EF-2:/etc/rc.d#

mount rootfs on / type rootfs (rw)

/dev/root on /mnt/openwrt/rom type squashfs (ro)

none on /dev type devfs (rw)

none on /proc type proc (rw)

none on /tmp type tmpfs (rw,nosuid,nodev)

none on /dev/pts type devpts (rw)

/dev/mtdblock/4 on /mnt/openwrt/jffs type jffs2 (rw)

mini_fo:/jffs on /mnt/openwrt type mini_fo (rw)

none on /proc/bus/usb type usbfs (rw)

/dev/scsi/host0/bus0/target0/lun0/part2 on / type ext2 (rw)

-------end

Thanks in advance

73

Dan ~ AF7EF

+1 to github

New to the broadband-hamnet project but not to development. It looks like the git links are down for the code, possibly due to the domain change. I'd like to help on the dev side if possible. 

Good to know, Thank You

Check Your Email

I have a tunnel server setup, if you would like to try and tunnel to my server. Just give me the node name of your Tunnel Client. Make sure you are open on port 5525. We have been playing around with a tunnel between Here and NC, but have been running into some trouble of seeing the other nodes and not being able to access them or advertised services. We Initially though it was due to both nodes being the gateway.

Oh and an email so I can send you the information for your tunnel client.