Why is the code for the map not shareable ????   why  NOT shared the map code ?  embed code for any webpage ?

thanks

I recently setup a Ubiquiti Bullet M2 node with 3.1.0 firmware. With a little playing around I was able to connect to and setup VLANs on a managed switch to provide a WAN address for the firmware and setup hamchat. Looking for other applications to add and hoping another node close to me appears. 

I recently setup a Ubiquiti Bullet M2 node with 3.1.0 firmware. With a little playing around I was able to connect to and setup VLANs on a managed switch to provide a WAN address for the firmware and setup hamchat. Looking for other applications to add and hoping another node close to me appears. 

Using the "ngircd 20.2" IRC server and trying to get access to it via the WAN port I find there is a lack of persistence in port 6667 once enabled.  Mesh network access is rock steady - WAN access is steady only after a weird sequence of steps is followed to make it work. The details below have only been tested on all nodes in 5 mode.

When first setting up the server after going through the adjustments in the docs, then saving and rebooting the router, the IRC server is fully available via the LAN ports, mesh wifi network, and any tunneled connections. IRC is not available via the WAN port. By going through "Setup", "Port Forwarding... Services", "Save Changes" and rebooting the router, that port is still not available at the WAN port and you cannot access the server. There is no presence of port 6667 and I've used a sniffer to verify this. The mesh network can access IRC but nothing on the WAN can.

Now at this point, if I again sign into "Setup" on the mesh status page, then select "Port Forwarding... Services", and click the "Save Changes" button again, but at the same time keep initiating a connect command using an IRC client on the WAN port, at about 15 seconds the client suddenly connects through the WAN port. After that it will stay connected as long as no further changes are made to the router node. The IRC server will remain fully accessible now via the WAN port and any client connected on the WAN port shows up on the list visible to any client connected on the LAN ports on the local mesh, or tunneled mesh connections.

Now if I issue a disconnect command on the WAN port client, it disconnects, but any subsequent attempt to reconnect fails and port 6667 is gone. No further connection via the WAN port is possible.  Clients on the LAN ports and mesh network remain connected just fine. 

From this point on, the only way to get the WAN port client to connect again is to click the "Save Changes" button on the "Port Forwarding... Services" screen and again initiate a connect command to the IRC client connect at the WAN port. Again, at about 15 seconds, port 6667 opens up and allows the client to connect. You then get the same situation as before - the connection is solid as long as nothing is changed in the router. Rebooting kills this connection of course.

"Save Changes" in the Basic Setup screen and rebooting  has no effect and does nothing to save whatever parameters are needed to avoid this sequence. Enabling / disabling / re-enabling the ports does nothing permanent either. Only the "Save Changes" sequence described above opens the WAN port and it will work even with no changes of any kind done to the ports, numbering or port forwarding. I've tested this on several 54G and 54GS units and it works on all of them.

Is it safe to assume this is a "bug" and not a hidden feature of the firewall?

Regards, Wil.

Introducing a new website that covers what we are doing in Orange County California.

Comments are requested.

Visit: http://ocmesh.org

i started to setup a MRSH, however it is not connected

I want to be Connected  BLUE  and Tunnel GREEN ... what are the basic setup instructions  ?

I'm a recent newcomer to IRC but not networking software, so I was able to set up several test chat servers on 54G and 54GS routers using ngircd 20.2 and testing port action using a sniffer. I had problems getting access to the servers though. I found that the clients I was using in Opera and Thunderbird were partly to blame for a lack of an easy setup.

On the setups here at first there was no way I could get a client to connect other than punching in the IP address. Also, as long as "0.0.0.0" is the default for the dns search the wifi address of the router will always be seen first, since the lan address is not available to the server. I found I had to enable the DNS search switch in the ngircd.conf file also.

Then, it wasn't really clear from the docs that you should only put in the node name when setting up the client account (ie ab9u-gr4) and nothing else after it such as "ab9u-g4.mesh". So once that was all working I tried external (wan) access and ran into a wall.

OK, here's my problem, I can not connect to the server using any irc client external to the mesh network via the WAN port.

Everything works within the mesh network address space via wifi or lan ports but nothing comes through the wan port firewall. I can open up ports all day, even enable gateway mode, but in setting up an "outside" client account I can't name the account the same name as what's in the mesh and that seems to be the only way to access the server by the client.

I can connect over the mesh and via tunnels without effort either by lan port or by wifi but not via the wan port at a different IP address range. I've tried adding the router external wan 192.168.3.6 ip to the server listening port list in ngircd.conf but nothing appears using netstat -tl. The other ports show up and are being listened to such as 6667, 6697 but those do not appear on 192.168.3.6. Using a sniffer port 6667 does not respond at the wan port.

What am I missing in the setup? It would be nice to access the IRC via the wan port.

Hello all, 

Just setup my first node with the 3.1.0 firmware and I'm not able to access the internet from the node.

From the administration page if I click refresh I get an 'error: no route to the internet'. telnet into the ubiquiti and not able to ping any external IP address. i.e. 8.8.8.8 'ping: sendto: Network is unreachable.'.  Mesh Gateway is checked.

The node is connected to my home network 192.168.1.0/24, the nodes LAN Mode is "NAT" IPaddr 192.168.1.20 mask 255.255.255.0 

Currently there are no other nodes in range of my qth, the node is able to see other wifi access points in my area.

Ubiquiti routing table. 

Destination Gateway GenMask Iface

10.0.0.0 * 255.0.0.0 eth0.2

10.0.0.0 * 255.0.0.0 wlan0

192.168.1.0 * 255.255.255.0 eth0

Guys,

I am real green horn, and I have flashed several of the WRT54G's with no problem, but now trying to flash a Ubiquity Bullet V3.5.4494 and a V4.0.3. I am getting an error message when I try to upgrade it of "Bad Firmware Update Image". I am using the Factory upload. I am able to communicate with the Bullet normally and it seems to work, but will not flash. Help!

73,

Kevin N4KM

Have you seen the Vocore? http://vocore.io/

or the Onion "Omega"? https://onion.io/omega/

> a remote base station was established on the NJ OEM 222 MHz repeater.

Got any details what comprised the remote base hardware?

Thanks

Mark K5LXP

Albuquerque, NM

I do volunteer work for the American Red Cross, New Jersey Region, on the Disaster Services Technology (DST) team. About 3 weeks before the recent visit of Pope Francis to the United States, I was contacted by Fred, WW2VEH, to discuss a backup plan to cover communications in cities in several states: New York City, Fairfield, NJ, Tinton Falls, NJ, and Philadelphia. What made this discussion interesting was that 3 Red Cross regions needed to communicate for one event, a situation not normally encountered. Fred asked me if I could put together some sort of phone system that could be deployed to these 3 cities as well as several field locations. Using elements of technology from amateur mesh operations and the AllStar Link Network, I was able to deploy a system across those cities using voip phones, an AllStar repeater node and remote base station, and mesh tunnels. Tying this all together was an Asterisk PBX.

Each city had one or two phones tied back to the main AllStar pbx. A tunnel server was established at the pbx end on a Ubiquity Nano station and tunnel clients using Linksys routers were established at each of the locations with phone(s). A dial plan was established enabling the phones to directly dial each other. Behind each phone there was voice mail as well a conference bridge available to all users. In the background, a number of test extensions were configured on the pbx to assist with provisioning the network. At Tinton Falls, 3 phones were set up: one directly off the tunnel client and two others via mesh on 2.4 GHz. Philadelphia had one phone, Fairfield had two phones and New York City had two phones.

Midway through the operation, a remote base station was established on the NJ OEM 222 MHz repeater. This was made available to all users through a special extension number.

All but one of the tunnel clients came up without incident. The one that did not come up was blocked by corporate firewall rules which did not allow unusual ports to leave the premises. All the phones worked well, except for one phone via mesh. The remote base station worked well, even though it was a 1 watt portable talking to a repeater 40 miles away with an attic mounted antenna.

None of the field locations were activated. However, in preparation for activating one location, a ViaSat satellite link was set up in the parking lot of Tinton Falls. A tunnel client was established over this link and the voip phone came up fine. Several calls were placed over this phone, and other than a long turn-around time, voice quality was good.

Some takeaways:

1. The phone that did not work via mesh was on a Part 15 channel. During the operation, Red Cross personnel did all their work via wireless laptops, between 20 and 30 units. In the future, phones connected this way will need to be using ham band only channels.
2. To remedy the problem of the client node being blocked by a firewall, perhaps a design change could be made allowing port 80 or maybe 443 to be used for tunnels.

Some pictures can be seen on the mesh at

http://n2mh-meshphone2/redcross/pope

Weblinks

AllStarLink Network

https://allstarlink.org/

AllStar on a BeagleBone Black or Raspberry Pi 2

http://crompton.com/hamradio/BeagleBoneBlackAllstar/

73, Mark, N2MH