Broadband-Hamnet™ Forum :: Bugs
Welcome Guest   [Register]  [Login]
 Subject :Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-06- 21:43:23 
w6nct
Member
Joined: 2014-07-16- 16:29:30
Posts: 12
Location

I tried to enter the details for the bug, but the Website logged me out before I could save it.

Since I could not mouse the text into this window, I am attaching a description as an attachment instead.

Since I don't see any indication of it after uploading it (as a text file), please contact me directly if you do not receive it.

Thank-you.

de Vern (W6NCT)

IP Logged
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-07- 00:17:33 
KG6JEI
Member
Joined: 2013-12-02- 19:52:05
Posts: 516
Location

I am not seeing an attachment on my side either.

IP Logged
Note: Most posts submitted from iPhone
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-08- 08:58:34 
w6nct
Member
Joined: 2014-07-16- 16:29:30
Posts: 12
Location
[Looks like I can now paste into input field, so will add original description of problem (below). I also sent it directly via eMail.] ====================================== I am sorry to draw attention to a possible shortcoming, because I am generally more than happy about what the development team has done thus far. Background: •For simplicity, I am shortening the node names, but all were based on user's call-sign and unique suffix. •All nodes were configured the same (e.g., matching SSIDs, in ad-hoc mode, running the v1.1.2 firmware, un-encoded, with vertically polarized antennas, and valid node names). •Node-101 was a standard Linksys (WRT54x), which we connected to a laptop using their LAN port connections and a standard CAT-5 Ethernet cable. •Node-850 was a Bullet with a 24dBi directional antenna, on a 6 ft. mast. It was powered through a CAT-5 Ethernet cable, using a 24 VDC (PoE) power interface. The other port of the power interface was unconnected, such that the node only interfaced using its Wifi radio link. •Node-851 was a Bullet with an omni-directional antenna, on a 15 ft. mast. It was powered through a CAT-5 Ethernet cable, using a 24 VDC (PoE) power interface. The other port on the power interface was unconnected, such that the node only interfaced using its Wifi radio link. •Node-S was positioned on a distant hilltop; and was believed to be a Bullet, with an unknown type of antenna. •Node-101 was placed on the roof of a vehicle, with the laptop inside; Node-850 was mounted on a mast, whose base-mount was affixed under the front tire of the vehicle; and Node-851 was initially positioned at the rear of the vehicle, and had a line-of-sight path to Node-S. •After power-up and initialization, Nodes -101, -850, and -851 could all connect directly to each other; and could see each others' status screens. •Prior to pointing Node-850's directional toward Node-S' location, none of the three local nodes could detect Node-S. Information specific to alleged bug: •The directional antenna connected to Node-850 was pointed toward Node-S. •After a small delay, Node-850 could see and connect to the Node-S as a current neighbor (as reported by its Mesh Status). •Node-101 could not detect Node-S as a current neighbor, but could see and connect to it as a remote node. •Believing that we had a receiver de-sense issue (for a non-related reason), we relocated Node-851 to a fence post behind the vehicle (approximately 40 ft. away, but still having a line-of-sight path to Node-S). •Node-851 reported that it could detect and connect to Node-S as a current neighbor; but when queried, Node-S did not also report Node-851 as its current neighbor. Node-851 and Node-101 were both listed as a remote nodes for Node-S. This seemed strange, so we investigated further. •We decided to power-off Node-850; and after a small delay, Node-851's mesh status changed to report Node-S by its IP address only (presumably because it didn't have sufficient signal amplitude to connect as a current neighbor). •This configuration was repeatable. •We believe that this is a BUG; whereas a distant node is mis-reported as a current neighbor (instead of a remote host) if it has sufficient local signal to detect its IP address, but not enough signal to connect or report its node name, AND another of its current neighbors DOES have sufficient signal level to connect to the distant node and display (and share) its node name. •This is not a critical BUG, and can easily be worked around. •Screen captures and additional details are available, if needed. Please Advise?
IP Logged
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-09- 18:47:15 
KG6JEI
Member
Joined: 2013-12-02- 19:52:05
Posts: 516
Location

If I understand the concern correctly (node with a path one way show as  a neighbor ). This sounds correct behavior to me.

The node is indeed a neighbor (as defined by our routing service olsrd). It is a neighbor with a 1 directional path.  Currently the software will not use such a route however it does keep track of it as a neighbor it can hear and could possibly become a bi directional neighbor if the RF path changed.


IP Logged
Note: Most posts submitted from iPhone
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-15- 18:38:20 
w6nct
Member
Joined: 2014-07-16- 16:29:30
Posts: 12
Location
[I started to enter this report a few minutes ago; but something timed out without my knowing; and when I hit SUBMIT it just went away (without sending it or saving it so that I could try again). I had to type it all back in again (via an external file with cut/paste. Grumble, grumble, grumble,...] SECONDARY QUESTION: can I adjust the timeout??? None the less, here it is again... (see below) ================================================================ Sorry; but I'm not sure that we are discussing the same situation (yet), or maybe I just don't understand enough about HamNet mesh to understand your response. To restate things, slightly differently, ... Our physical configuration during the test: Node-101 (i.e., a std. power Linksys with its std. low-gain omni-antennas), Node-850 (i.e., a std. power Bullet with a 24 dBi uni-directional antenna pointed at Node-S, line of sight with no obstructions), and Node-851 (i.e., a Bullet with a 15 dBi omni-directional antenna) were all within a small radius on top of Mountain-top(1); and Node-S was by itself on a separate Mountain-top(2) (i.e., presumably with its uni-directional antenna pointing at the location on Mountain-top(1), where all three of the other nodes were setup). The case we had was that, at the same time and physical configuration, ... --- Node-850's antenna was pointing at Node-S, and vice versa. --- Node-850's Mesh Status indicated Current Neighbors to be Node-101, Node-851, and Node-S; but No Remote Nodes. I was under the impression that this meant that Node-850 could talk (directly and bi-directionally) to each of the other three nodes. Correct? This Node Status makes sense to me, given the physical situation. --- Node-S' Mesh Status indicated Current Neighbors to be Node-850 (and Node-S ?). It also indicated Remote Nodes of Node-101 and Node-851. I was under the impression that this meant that Node-S could only talk directly to Node-850 (bi-directionally); but could communicate indirectly (yet bi-directionally) to Node-101 and Node-851 (i.e., via Node-850). Correct? This Node Status makes sense to me, given the physical configuration (i.e., assuming that the omni-directional antennas on Node-101 and Node-851 lacked sufficient signal strength (and gain) to reach Node-S directly, and that Node-850's connection could relay). I don't quite understand why Node-S' Mesh Status included itself as a Current Neighbor (?); perhaps you can explain that (i.e., separate from the primary issue/concerns below). --- Node-851's Mesh Status initially indicated Current Neighbors to be Node-101, Node-850, and Node-S; with No Remote Nodes. I was under the impression that this meant that Node-851 thought that it could directly talk (bi-directionally) to each of the other three nodes (including Node-S). Correct? This Node Status surprised me in that (1) it didn't match the status reported by Node-S, and (2) I didn't think that its omni-directional (signal and gain) was enough to reach Node-S' site. --- To test the connection status ambiguity, we powered OFF Node-850; everything else remained the same, physically and operationally. After a delay, we got the following... --- Node-S's Mesh Status indicated NO Current Neighbors and NO Remote Nodes. I was under the impression that this meant that Node-S couldn't really talk (directly and bi-directionally) to either Node-101 or Node-851. Correct? This Node Status made sense to me, given the physical configuration and Node-S' previous Mesh Status (i.e., assuming that the omni-directional antennas on Node-101 and Node-851 lacked sufficient strength to reach Node-S directly, and that Node-850's connection was no longer available to relay). --- Node-851's Mesh Status indicated Current Neighbors to only be Node-101; with No Remote Nodes. I was under the impression that this meant that Node-851 really couldn't talk (directly and bi-directionally) to Node-S; and that the prior Mesh Status information was reported incorrectly. Does this make sense, or am I missing something? I hope that I clearly restated the configuration, operational steps, and Mesh Status ambiguity of our concern. If not, I can also send some supportive screen shots showing the Mesh Status. Respectfully, de Vern (W6NCT)
IP Logged
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-15- 18:39:56 
w6nct
Member
Joined: 2014-07-16- 16:29:30
Posts: 12
Location
... also how can I get it to retain white-space in my response? When it strips it, it makes it much harder to read. Thx. <<< vern >>>
IP Logged
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-15- 19:29:26 
K6AH
Member
Joined: 2012-03-05- 10:47:45
Posts: 181
Location: San Diego, CA

If you first click POST REPLY it opens an editor window which more formatting features... and it's WYSIWYG with a preview feature.

Andre, K6AH

IP Logged
Member of:
Beta Test Team
San Diego Mesh Working Group
Running 3.0.1
 Subject :Re:Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbo.. 2014-08-15- 21:25:31 
KG6JEI
Member
Joined: 2013-12-02- 19:52:05
Posts: 516
Location
Subject :Re:Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor

What sort of hardware is Node S?  Without that we are just taking shots in the dark.

"Node-850's Mesh Status indicated Current Neighbors to be Node-101, Node-851, and Node-S; but No Remote Nodes. I was under the impression.... was under the impression that this meant that Node-850 could talk (directly and bi-directionally)" This does not necessarily mean the connection is bi directional., just that Node-850 can see packets from Node-S. 

Ubiquiti hardware has a better receiver, it is very possible that even without any noise from wifi devices that Node-850 can see Node-S's beacons even if it can't establish a bidirectional iink,  This would show up as having an LQ value in the Mesh Status screen, you would need to look at the OLSR Status to see if its bi directional or not.

"but could communicate indirectly (yet bi-directionally) to Node-101 and Node-851 (i.e., via Node-850). Correct?"  Generally true, of course its possible contact may not be possible if a link in the path is overloaded, or a high ETX path.  An single hop ETX of 2.0 means a 50% chance the packet won't make it . A ETX of 4 is up to 75% chance of loss on round trip.  LQ can be high in one direction and very low in another direction. (one way UDP streams wouldn't have an issue with this for example)

" To test the connection status ambiguity, we powered OFF Node-850; everything else remained the same, physically and operationally. After a delay, we got the following... --- Node-S's Mesh Status indicated NO Current Neighbors and NO Remote Nodes. I was under the impression that this meant that Node-S couldn't really talk (directly and bi-directionally) to either Node-101 or Node-851"

This makes sense if its a VERY low connection (very low LQ -- You don't specify ) which your getting a lot of feed from node 850, and just enough from Node S to know its there. There is some level of bidirectional required for everything to exchange correctly at the low levels  (olsr secure attack prevention code) to get name data, and to exchange some keys. It may be that the traffic is going via 850 for the majority and were just seeing the beacons and able to correctly decode them with the additional data provided via 850.

An output of telnet localnode 2006  and a copy of your olsr status all page may provide some additional details rather than us taking guesses.

"I don't quite understand why Node-S' Mesh Status included itself as a Current Neighbor (?); perhaps you can explain that (i.e., separate from the primary issue/concerns below)."

I didn't see that in your initial inquiry , the output of the above data would also help on this one as well to see what is going on.



[w6nct 2014-08-15- 13:38:20]:

[I started to enter this report a few minutes ago; but something timed out without my knowing; and when I hit SUBMIT it just went away (without sending it or saving it so that I could try again). I had to type it all back in again (via an external file with cut/paste. Grumble, grumble, grumble,...] SECONDARY QUESTION: can I adjust the timeout??? None the less, here it is again... (see below) ================================================================ Sorry; but I'm not sure that we are discussing the same situation (yet), or maybe I just don't understand enough about HamNet mesh to understand your response. To restate things, slightly differently, ... Our physical configuration during the test: Node-101 (i.e., a std. power Linksys with its std. low-gain omni-antennas), Node-850 (i.e., a std. power Bullet with a 24 dBi uni-directional antenna pointed at Node-S, line of sight with no obstructions), and Node-851 (i.e., a Bullet with a 15 dBi omni-directional antenna) were all within a small radius on top of Mountain-top(1); and Node-S was by itself on a separate Mountain-top(2) (i.e., presumably with its uni-directional antenna pointing at the location on Mountain-top(1), where all three of the other nodes were setup). The case we had was that, at the same time and physical configuration, ... --- Node-850's antenna was pointing at Node-S, and vice versa. --- Node-850's Mesh Status indicated Current Neighbors to be Node-101, Node-851, and Node-S; but No Remote Nodes. I was under the impression that this meant that Node-850 could talk (directly and bi-directionally) to each of the other three nodes. Correct? This Node Status makes sense to me, given the physical situation. --- Node-S' Mesh Status indicated Current Neighbors to be Node-850 (and Node-S ?). It also indicated Remote Nodes of Node-101 and Node-851. I was under the impression that this meant that Node-S could only talk directly to Node-850 (bi-directionally); but could communicate indirectly (yet bi-directionally) to Node-101 and Node-851 (i.e., via Node-850). Correct? This Node Status makes sense to me, given the physical configuration (i.e., assuming that the omni-directional antennas on Node-101 and Node-851 lacked sufficient signal strength (and gain) to reach Node-S directly, and that Node-850's connection could relay). I don't quite understand why Node-S' Mesh Status included itself as a Current Neighbor (?); perhaps you can explain that (i.e., separate from the primary issue/concerns below). --- Node-851's Mesh Status initially indicated Current Neighbors to be Node-101, Node-850, and Node-S; with No Remote Nodes. I was under the impression that this meant that Node-851 thought that it could directly talk (bi-directionally) to each of the other three nodes (including Node-S). Correct? This Node Status surprised me in that (1) it didn't match the status reported by Node-S, and (2) I didn't think that its omni-directional (signal and gain) was enough to reach Node-S' site. --- To test the connection status ambiguity, we powered OFF Node-850; everything else remained the same, physically and operationally. After a delay, we got the following... --- Node-S's Mesh Status indicated NO Current Neighbors and NO Remote Nodes. I was under the impression that this meant that Node-S couldn't really talk (directly and bi-directionally) to either Node-101 or Node-851. Correct? This Node Status made sense to me, given the physical configuration and Node-S' previous Mesh Status (i.e., assuming that the omni-directional antennas on Node-101 and Node-851 lacked sufficient strength to reach Node-S directly, and that Node-850's connection was no longer available to relay). --- Node-851's Mesh Status indicated Current Neighbors to only be Node-101; with No Remote Nodes. I was under the impression that this meant that Node-851 really couldn't talk (directly and bi-directionally) to Node-S; and that the prior Mesh Status information was reported incorrectly. Does this make sense, or am I missing something? I hope that I clearly restated the configuration, operational steps, and Mesh Status ambiguity of our concern. If not, I can also send some supportive screen shots showing the Mesh Status. Respectfully, de Vern (W6NCT)

IP Logged
Note: Most posts submitted from iPhone
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-16- 13:52:02 
w6nct
Member
Joined: 2014-07-16- 16:29:30
Posts: 12
Location
Hi Andre (K6AH), QUESTION: Is that handled differently from "Quick Reply"? I'm not sure which of the two I used, but what I typed in, and how it looked when I hit "Submit" isn't how it looks now, when I read my response in the thread. All but the minimum white-space has been stripped. So something is somehow over-riding the WYSIWYG. On top of that, (the first time I tried entering my message (both this recent time and at least one time prior) my session apparently timed out even though I was actively typing and editing in the response-input window; and it wasn't apparent until I hit "Submit". After hitting "Submit" the window and my text just disappeared, no error, no nothing. I had to log back in to resubmit it; and in both cases I had to re-type it outside the session (e.g., in an text editor) and cut/past it into the Response window. It is frustrating! <<< vern >>>
IP Logged
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-16- 14:43:08 
w6nct
Member
Joined: 2014-07-16- 16:29:30
Posts: 12
Location

[Posted wit Post A Reply, this time; as opposed to Quick Response] [Cut/Past no longer works for me, which make typing much slower]


Hi Conrad (KG6JEI),

I'm pretty sure that Node-S is a Bullet; and at the time of the test, it may have been using a 24 dBi directional (screen-dish type) antenna.  I'll have to check with its owner to be sure about the antenna, as it is not my node, and he was making configuration changes a couple days prior to our test.

LQ values weren't constant or even very stable; but were typically in the 63-100% range at the times that I noted them in this test sequence.  Node-S indicated Node-850 at 100%, with Remote Node-101 ETX=3.12 and Node-851 ETX=2.97.  One of the captures I have for Node-850 shows Node-101 at LQ=82%, Node-851 at LQ=68% (even though they were next to each other), and Node-S at LQ=63%.  Other evidence seemed to indicate that the two bullet nodes may have been de-sensing each other a little (e.g., numbers improved when I moved them farther apart, and when I turned off one of them). 

Thank-you for the extra information, I'll try to capture more statuses the next time I test there.  Hopefully that will paint a more complete picture.

Is there any document to tell us how to read the OLSR status screens, and how to interpret ETX and LQ information?  There is so much information on the Web-site I haven't found it yet.

I was unaware that I could telnet to the other nodes, thus far, I have only been selecting the other nodes via the Mesh Status, then traversing their menus.  Is that functionally the same?

Thanks again for the info.  Next time I go up to test, I'll try to get more screen captures.

de Vern (W6NCT)


IP Logged
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-16- 15:08:06 
w6nct
Member
Joined: 2014-07-16- 16:29:30
Posts: 12
Location
Hi again Andre, I just realized, yes. they are different. The Quick Reply is stripping the whitespace; but the Post Reply doesn't (at least for me). --- I also noted that the Quick Reply has no obvious way to preview or add attachments; but with it I am able to cut/paste. In contrast, the Post Reply says that it has a way to add Attachments, but it doesn't work for me, (and doesn't give any errors either); and I can't cut/paste in the Post Reply window either. --- I haven't figured out if both mechanisms will log me out (i.e., without telling me, while I am typing in a response); and I don't recall which I was using when it did it to me the two times before (I'm guessing that I was using the Quick Reply when I was getting logged out, but am not sure). Thanks for the info. Maybe I can figure out why these aren't working for me, assuming that it isn't a Web-page bug(?). Regards, de Vern (W6NCT)
IP Logged
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-16- 22:41:09 
K6AH
Member
Joined: 2012-03-05- 10:47:45
Posts: 181
Location: San Diego, CA
I have a hard time devoting resources to doing work in this area. We plan an upgrade to the web site. In the mean time I'd recommend drafting the message in Word or another editor and pasting it into the web page. Andre, K6AH
IP Logged
Member of:
Beta Test Team
San Diego Mesh Working Group
Running 3.0.1
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-18- 14:02:50 
K6AH
Member
Joined: 2012-03-05- 10:47:45
Posts: 181
Location: San Diego, CA

Sorry, after re-reading my last reply... it was a little terse.  We are working on an upgrade of the BBHN web services and expect the upgrade to be much improved... including searches of the Forum.  In light of this, and the fact that we didn't write it, it's difficult to justify even looking into the current editor.

Others seem to have gotten around issues with it, so if it continues to frustrate you, then perhaps using another editor would save some of the aggravation.

73,

Andre, K6AH


IP Logged
Member of:
Beta Test Team
San Diego Mesh Working Group
Running 3.0.1
 Subject :Re:Bug in v1.1.2 whereas it mis-reports a node as a current neighbor.. 2014-08-18- 18:29:39 
w6nct
Member
Joined: 2014-07-16- 16:29:30
Posts: 12
Location
No worries. I often remind myself that this (i.e., Amateur Radio) is a "hobby" and many of its operators (including those that have already done so much to make the HamNet Mesh a reality) also have "a day job", family, and perhaps one or two other priorities that compete for any available time. I was mostly wanting to make sure that "someone" knew what I had learned about the anomalies I saw. Unfortunately, I am not a Web-page developer, or I might have offered to help fix it; as it is, I'm fine with patiently waiting for any improvements, and continuing to use work-arounds until things improve. I do have a little experience in C and networking; so who knows, maybe I could help the group in other ways, a little farther down the line. Thx anyway for the suggestions. de Vern (W6NCT)
IP Logged
Page # 


Powered by ccBoard


SPONSORED AD: