Sold pending funds.

Rick, KL7BR

A bad port on the injector, now that is the first time I have heard that one.

Glad you have it working and sorted out, and funny it happens right after the update as well.

Ok first off make sure on the SETUP screen you are in DIRECT mode, its the easiest way to set this up (otherwise you have to make sure you have port forwards correct) and should use that unless you have a reaosn not to. In direct mode the node provides no filtering it simply forwards packets direct to your internal network devices (such as your camera)

2) You mention the camera needs "rtsp://[account:password]@IPC:554/live" the Advertised Services link will not support an @ sign so you can't advertise it with a password so you would need to (manually) put the password in on your remote side.  Note however that Advertised URL's have no effect on if the node will permit the traffic or not, it only does a link for others to click on, nothing else, it is purely cosmetic. If you know how to run an RTSP client manually you can do so without the URL and that would be the way to test it.  

It is also possible your camera has security on it to only accept connections from the 'local' network (local in this case would be those on the same lan port as the camera can know by the IP address its given what is local)  this may not be the case but is something to consider. 

3) Port 554 is not relevant to us as the node is not the server (also everything runs as root on the node anyways so the <1024 rule doesn't apply 

4) Firewall, as noted in direct mode we don't add firewall rules for each connection only a forwarding firewall rule. If your in NAT mode it would require extra setup which can be done via the GUI but I recommend getting it working via direct mode first.

RTSP is simple UDP which we fully support over the network.

As for code, the Dave repo hasn't been used for some time (1.0.0)  I recommend checking out http://www.bbhndev.org/  it has recent code on it (everything from current/previous releases to  beta and alpha code)

Update:

I finished the translating program and it works flawlessly if the computer is plugged into the same node that the camera is plugged into. (N4FWD-2)

So, I decided to move the computer to the second node (N4FWD-1) and try using the advertised service link shown for the camera on that node. Dead in the water. After 2 hours of meticulously testing with various combinations, I have come to the conclusion that the RF portion of BBHN simply does not support the RTSP protocol. Both nodes are at the latest version of firmware for BBHN.

[snip]

I grabbed a copy of the firmware using the published svn link by David - AD5OO. The code seems a bit dated. The file, mesh-release, under trunk/files/etc says "1.0.0". Is that right?

One other thought, is it possible that the 554 default port is too low for linux and might be blocked as a system service? When I checked the firewall settings, I noticed that there are only a handful of ports listed.

I figured it out..

The problem was a bad LAN port on the power supply. I connected the bullet to a trended s44 poe switch and it booted. The IP address was 192.168.1.1. Since I had just flashed it, and never completed a reboot and setup, I guess it was correct.

Thanks for all the help

73 de mike

K6JAC, KG6SJT, K6WLS and myself installed two new BBHN nodes at K6JAC's QTH yesterday. They are on his tower at about the 30 ft level.

AG6QO-700 is a Ubiquiti AirGrid 20dB dish, pointed at the node at the Berryessa repeater site (AG6QO-500). AG6QO-800 is co-located with -700 and is a Ubiquiti Bullet with an 8dB Omni antenna to serve the local area.

For some reason, connection with the repeater site did not occur immediately as it did during preliminary ground tests earlier. AG6QO-500 is not being heard at all today.

K6WLS and I will be investigating that on Sunday. Meanwhile these new nodes are available to anyone who can hit them. Please note that these nodes are all running V1 of the BBHN firmware. Upgrade is planned after all planned nodes are communicating reliably.

Joe

AG6QO@AG6QO.#NCA.CA.USA.NOAM

https://groups.yahoo.com/neo/groups/SacMeshNet/info

Well from BBHN standpoint s specification as to what is in each "version" is a little weak, it's all documented in the code that is publically avaliable but has not been well defined on a webpage yet. One of those projects I haven't had much time to do but is relevant to the discussion currently being had on the v4 protocol specs. Some of these specs are not even set by us and would never be in our standards (for example in theory this network could run over a laser beam path instead of 802.11)

A full protocol specification would be a bit much to get into (you don't really want me to describe 802.11 in full gory detail do you? :) suffices to say for regulatory it can be described as  "An IP network as defined by IETF public standards  operating on top of an IEEE  documented  802.11 RF layer on <insert frequency here> at <insert channel width here> width with an OLSR routing daemon" (feel free to pull up the FULL encoding standards on these from the appropriate regulatory body)

It is correct that that the SSID packets do not contain any callsign details. There is no room in the protocol for this extra extra details and it is not needed either. Many hams in the past used this as a method to setup networks that belonged to them and only them (largely becaus Windows did not make it easy to identify in any other way) but am SSID is more of a group affiliation/ way to share frequencies (similar to a tone sql code) than it is an identification.

In BBHN identification is handled by the /usr/local/bin/fccid program that every 5 minutes runs, waits an offset amount of time (less then 5 minutes ) to help stagger identifications, and then sends a IP/UDP packet out with "ID: NodeName" on port 4919 to perform the actual identification. If you cared to see these you could use the tcpdump package to watch the RF interface.

In addition the OLSR stack sends out a correlation of IP address  and node callsigns thst extends across the entire network so one may corelate downstream as well.

With the fccid program and the fact we are running atop well defined documented standards (aka the FCC upon request to the IEEE can figure out how to demodulate the RF into a binary bit stream)  we perform the identification in a window that is less than 10 minutes in length between to keep the device compliant.

One of our local group have raised a question about SSID beacon packets. He believes that they do not contain "station ID" info required by Part 97 (Node Name).

I searched for a description of the entire protocol stack used by Broadband Hamnet firmware, and could not find one. Only very brief verbal references to TCP/IP (which I'm very familiar with) and less familiar with 802.11.

Does a detailed stack description exist? Can someone point me to it?

Specific question is: "Does the protocol stack, at some level, identify EVERY packet with callsign (Node Name)?"  But the full question is, is there ONE place one can look to find the entire stack explained?

Joe

AG6QO@AG6QO.#NCA.CA.USA.NOAM

I live in Northern VA and would prefer a face to face meeting.  I have just upgraded it to the V3 software but it is not configured nor bricked, it still has the standard username and password.  Contact me at my callsign at yahoo dot com.

If you are not nearby, you can send me a pre-paid address label for a USPS medium flat-rate priority mail box and I'll get it out the next day.

Rick

KL7BR

Arlington, VA

It took a long sleepless night but I found a very simple way to do it in minutes.

The short version: Upgrade with tomato firmware (a trx file). Upgrade from Tomato using a bin file for dd-wrt, linksys, or whatever you desire.

The long version: I couldn't remember my password for the router so I used this (http://www.broadband-hamnet.org/documentation/71-using-safe-mode-to-reset-a-forgotten-password.html) to reset it to "abc" so the username/password was root/abc. This allowed me access to the SETUP>ADMINISTRATION>CHOOSE FILE>UPLOAD area. Broadband-hamnet uses OpenWrt.. as you discovered OpenWrt will not support bin files for any web firmware uploads. Changing the bin to trx file seemed over my head (removing the header pun intended). So after searching the end of the Internet, I found Tomato Firmware. Specifically a blurb about renaming the tomato firmware file from trx to bin with the explanation that the bin would work without the header. Everyone needs bin but OpenWrt needs the trx file...

1. Simply download Tomato Firmware here: http://sourceforge.net/projects/tomatofirmware/?source=typ_redirect

2. Extract the tomato.trx file from the archive. Use the web interface to upload this file. My broadband-hamnet stated successful after uploading and installing. I renewed my connection to 192.168.1.1 and the Tomato Router username/password is root/admin.

3. Navigate the Tomato web interface to Administration>Upgrade. Simply upload the bin you wanted here just like before. In my sleep deprived state I went to the original linksys firmware and then to DD-WRT but any bin will do. The password for DD-WRT is also root/admin.

Glad to help,
Scott, KD4SIR

If that network led doesn't light up you have no chance at speaking to the node until it does.

That LED is controlled by hardware so even a crashed bricked node would still light it up (assuming the LED doesn't go bad obviously).  It is lit when a cable is plugged in and flashes off when packets are sent. It is the same as the LED on a switch that light up when you plug in a cable and turns off when you unplug a cable.

I recommend swapping out the cable between the injector and node, and the cable between the injector and the computer (make sure you plug the POE side to the node and not the computer)

If that doesn't light up with new/different cables you may want to try instead of plugging into your computer plug the cable from the LAN side of the injector into a switch and see if that works any better to rule out PC problems.

the led in question does not blink during boot.

none of the attempts worked

in recovery mode

network Ip set manually...

root@K3MMB-Gateway:/home/k3mmb/Downloads# ifconfig
eth0      Link encap:Ethernet  HWaddr 04:7d:7b:7e:55:2d  
inet addr:192.168.1.254  Bcast:192.168.1.255  Mask:255.255.255.0
inet6 addr: fe80::67d:7bff:fe7e:552d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:918 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B)  TX bytes:157406 (153.7 KiB)
Interrupt:43 Base address:0x6000

lo        Link encap:Local Loopback  
inet addr:127.0.0.1  Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING  MTU:16436  Metric:1
RX packets:337 errors:0 dropped:0 overruns:0 frame:0
TX packets:337 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:33650 (32.8 KiB)  TX bytes:33650 (32.8 KiB)

wlan1     Link encap:Ethernet  HWaddr 08:ed:b9:05:56:0f  
inet6 addr: fe80::aed:b9ff:fe05:560f/64 Scope:Link
UP BROADCAST MULTICAST  MTU:1500  Metric:1
RX packets:11143 errors:0 dropped:0 overruns:0 frame:6020
TX packets:6869 errors:56 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14382247 (13.7 MiB)  TX bytes:814272 (795.1 KiB)
Interrupt:17

root@K3MMB-Gateway:/home/k3mmb/Downloads# ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data.
From 192.168.1.254 icmp_seq=1 Destination Host Unreachable
From 192.168.1.254 icmp_seq=2 Destination Host Unreachable
From 192.168.1.254 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.1.20 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3014ms
pipe 3
root@K3MMB-Gateway:/home/k3mmb/Downloads#

The one pictured is a 15. I believe we upgraded to 60 watts and added a larger battery. It stayed on all night last night and went out this morning for an hour before the sun came up.

It doesn't sound bricked to me, this is the normal light pattern for a bootup.

What I find interesting is you don't mention the LED next to the power LED. That one should flash as packets are sent and received, if it isn't lit  your network cable isn't plugged in, has gone bad, or the port some how took an ESD shock (not likely on a work bench this is usually only seen on towers)   Might of come loose while moving cables around from the POE injector or computer.

Also the default IP address on "just flashed" is 192.168.1.1 (the 1.20 is when you are in firmware recovery mode only)