|
Broadband-Hamnet™ Forum |
|
|
|
|
|
|
Subject :Re:Running ubiquiti nodes on batteries..
2014-10-25- 20:33:46
|
|
|
9h1bw |
|
Member |
 |
Joined: 2014-10-12- 07:26:44
Posts: 4
Location: |
|
|
|
Forum :
Hardware
Topic :
Running ubiquiti nodes on batteries
Thank you both for your replies. Being a novice I am assuming that an injector is a device which plugs into the Poe which allows a way of feeding power to the system from an external source. This is an excellent way of doing it but I would have to ensure the pin connections are properly observed. To date I have not found ubiquiti as being forward in providing technical information on their products. Can you suggest a site I can use for the purpose.
having said this the second option of feeding the node with 12volts or 24volts for that matter, need a detailed explanation of how to go about it. I would be obliged to receive more information regarding the matter. thank you again.
chris 9h 1bw. |
IP Logged
|
|
|
|
|
|
Subject :Re:Re:Re:Re:Re:Virtual Tunnels..
2014-10-25- 09:55:23
|
|
|
KG6JEI |
|
Member |
 |
Joined: 2013-12-02- 19:52:05
Posts: 516
Location: |
|
|
|
Forum :
General
Topic :
Virtual Tunnels
You would need that block on 100% of the nodes in the mesh network, not just the gateway nodes. In otherwords it would have to be in mainline. I'm not sure I see that happening, I know I would personally oppose such a patch on the grounds it interferes with global internet routing.
Every node will need to see the IP address as part of the routing table method for how OLSRD works it goes out in the MID packets (and it has to be in them) to advertise route paths. Every node on the network can connect to the WAN and would possibly forward the packet out to the WAN this is why the block would have to be on 100% of the nodes and not just the GW nodes.
Unless your planning on heavily modifying OLSRD to have each node remove some of the data (and I'm not sure how much that would confuse the daemon off hand if one node knows the route fully and the others don't)
[SM7I 2014-10-25- 09:21:34]: Well, I agree with you partly, but it´s a small issue to address by the means of some extra code to implement as a failsafe to ensure that 1.1.1.0/24, 1.2.3.0/24 and so on, never reaches the WAN or RF interfaces of the nodes.
This is something that I can implement rather quickly and will do so during next week.
Our GRE solution is implemented in a "package" like way, so this extra code will be part of future releases. The rather small footprint of this solution gives us the benefit of having som more addendum of different features without growing significantly in code. For example, we have already implemented the UCSD ripd connection for anyone wanting to use it. It´s still small enough to be harboured in the GL model though :)
As I said before, the recomendation is to use RFC private address-spaces, but I see this addition of code as a failsafe.
[KG6JEI 2014-10-25- 08:44:45]: I'm not sure you can guarantee that.
As I noted we do not filter on the mesh nodes the 1.1.1.0/24 network. (Nor do I believe we should as it's a public network that could be put into service)
I can speak for myself and say in my current network setup leakage is 100% possible. Even with my Checkpoint/Palo Alto/Cisco/Custom firewalls in line 1.1.1.0/24 doesn't appear to be in my bogon lists by quick glance (likely because it is technically allocated)
Every mesh node advertises it's VPN IP address as one of it's IP's. This shows up in links on various pages of the BBHN/OLSR UI.
An example leakage possibility:
If the route goes down all of a sudden the fallback would be to send the packet out the nearest WAN GW. This by definition is leakage by crossing the bearer from BBHN to Local "WAN" network. Most home routers will likely not block it and on corporate routers it's not suppose to be blocked either. This causes further leakage into the routed internet.
Here is what happened in the past: "While network 1.0.0.0/8 was an unallocated and unadvertised network any such traffic directed to an address in this block that “leaked” into the public Internet would follow a “default” routing path to the point where there was a “default-free” routing element, where the traffic would be discarded. As soon as any such address in 1.0.0.0/8 was advertised as reachable into the public Internet, instead of being discarded as the boundary of the default-free zone (DFZ), the packets would be passed onto the destination rather than being discarded."
As seen once they advertised it it was routed. Also I notice you have a USA tunnel, can you guarantee that persons ISP won't route it ? How about every other node on that users mesh and their ISP's ? What about nodes that VPN into a node that's connected via rf to another node to another to one on the tunnel? As you can see this very quickly becomes a can of worms that becomes hard without positive control over 100% of the nodes in the system. Will it physically harm anyone, no, has it caused APNIC to declare space unusable,for the time being yes, will it likely be a lot of leaked traffic, no-but a lot of small traffic adds up to 800mbps spikes.
And yes I believe Google was brought in for some capacity based on that doc to help test, what they are/were testing I don't know, but if APNIC told them to do something then it's within APNICS's authority to do so as the allocating authority (I see the advert is currently associated to Google under their AS15169 in the BGP tables: http://bgp.he.net/AS15169#_prefixes ). Google does make sense in a lot of regards due to their number of peering points, get the data off the 'uncontrolled' net as quickly as possible and into the 'controlled' infrastructure where it can be accounted for sooner reducing the chances of some router blocking it giving false readings.
**note: not intended to be a fight, just trying to point out why I am concerned about this as a networking person who has spent a fair amount of time with the BBHN code, and why in a global project like this some assumptions that have been made can't be made and why we should avoid this from the start rather than risk issues in 5 years.
[SM7I 2014-10-25- 03:50:19]: KG6JEI
We always encourage hams to follow RFC, but in the end it´s up to everyone to decide what fits into their existing IP -plan. In this case it´s of no big issue since the IP´s will never be exposed to the Internet, only through the tunnel.
Also here, with my ISP, this particular IP network is not routed outside by them. And from what I understand this IP network is used isolated by Google to perform certain scientific tests.
But, once again. We encourage hams to follow RFC for private address-spaces suitable fo their needs.
[KG6JEI 2014-10-24- 06:15:20]: Darryl: (Oops while I was typing Joe got to you so I've cleared my comment) SM7I: I took a look at your link. I'm concerned about the address space you are using for your VPN service and how it does not match reasonable internet standards. 1.1.1.0/24 is a public address space and should not be used on the mesh nodes without and assigned allocation from APNIC. The nodes are not configured to block routing 1.1.1.0/24 out to the public internet. You may be causing packet leakage by operating in this manner. APNIC has had serious issues with this http://www.potaroo.net/studies/1slash8/1slash8.pdf perhaps moving the the 172.31.x.x space BBHN is promoting for VPN's would be wise. |
IP Logged
|
Note: Most posts submitted from iPhone |
|
|
|
|
|
Subject :Re:Running ubiquiti nodes on batteries..
2014-10-25- 09:24:52
|
|
|
AE5CA |
|
Member |
 |
Joined: 2012-05-19- 21:52:33
Posts: 81
Location: |
|
|
|
Forum :
Hardware
Topic :
Running ubiquiti nodes on batteries
I would caution you to verify the pin out of your POE injector. There are several different schemes in use and if your injector puts the voltage on the wrong pins it releases the "blue magic smoke" that makes the nodes work. I have used several ubnt nodes running of a 12 vdc battery with no problems. If you are using 12v I would suggest you keep your cable distances shorter. Clint, AE5CA
|
IP Logged
|
|
|
|
|
|
Subject :Re:Re:Re:Re:Virtual Tunnels..
2014-10-25- 09:21:34
|
|
|
SM7I |
|
Member |
 |
Joined: 2012-04-30- 14:56:55
Posts: 79
Location: JO65mo |
|
|
|
Forum :
General
Topic :
Virtual Tunnels
Well, I agree with you partly, but it´s a small issue to address by the means of some extra code to implement as a failsafe to ensure that 1.1.1.0/24, 1.2.3.0/24 and so on, never reaches the WAN or RF interfaces of the nodes.
This is something that I can implement rather quickly and will do so during next week.
Our GRE solution is implemented in a "package" like way, so this extra code will be part of future releases. The rather small footprint of this solution gives us the benefit of having som more addendum of different features without growing significantly in code. For example, we have already implemented the UCSD ripd connection for anyone wanting to use it. It´s still small enough to be harboured in the GL model though :)
As I said before, the recomendation is to use RFC private address-spaces, but I see this addition of code as a failsafe.
[KG6JEI 2014-10-25- 08:44:45]: I'm not sure you can guarantee that.
As I noted we do not filter on the mesh nodes the 1.1.1.0/24 network. (Nor do I believe we should as it's a public network that could be put into service)
I can speak for myself and say in my current network setup leakage is 100% possible. Even with my Checkpoint/Palo Alto/Cisco/Custom firewalls in line 1.1.1.0/24 doesn't appear to be in my bogon lists by quick glance (likely because it is technically allocated)
Every mesh node advertises it's VPN IP address as one of it's IP's. This shows up in links on various pages of the BBHN/OLSR UI.
An example leakage possibility:
If the route goes down all of a sudden the fallback would be to send the packet out the nearest WAN GW. This by definition is leakage by crossing the bearer from BBHN to Local "WAN" network. Most home routers will likely not block it and on corporate routers it's not suppose to be blocked either. This causes further leakage into the routed internet.
Here is what happened in the past: "While network 1.0.0.0/8 was an unallocated and unadvertised network any such traffic directed to an address in this block that “leaked” into the public Internet would follow a “default” routing path to the point where there was a “default-free” routing element, where the traffic would be discarded. As soon as any such address in 1.0.0.0/8 was advertised as reachable into the public Internet, instead of being discarded as the boundary of the default-free zone (DFZ), the packets would be passed onto the destination rather than being discarded."
As seen once they advertised it it was routed. Also I notice you have a USA tunnel, can you guarantee that persons ISP won't route it ? How about every other node on that users mesh and their ISP's ? What about nodes that VPN into a node that's connected via rf to another node to another to one on the tunnel? As you can see this very quickly becomes a can of worms that becomes hard without positive control over 100% of the nodes in the system. Will it physically harm anyone, no, has it caused APNIC to declare space unusable,for the time being yes, will it likely be a lot of leaked traffic, no-but a lot of small traffic adds up to 800mbps spikes.
And yes I believe Google was brought in for some capacity based on that doc to help test, what they are/were testing I don't know, but if APNIC told them to do something then it's within APNICS's authority to do so as the allocating authority (I see the advert is currently associated to Google under their AS15169 in the BGP tables: http://bgp.he.net/AS15169#_prefixes ). Google does make sense in a lot of regards due to their number of peering points, get the data off the 'uncontrolled' net as quickly as possible and into the 'controlled' infrastructure where it can be accounted for sooner reducing the chances of some router blocking it giving false readings.
**note: not intended to be a fight, just trying to point out why I am concerned about this as a networking person who has spent a fair amount of time with the BBHN code, and why in a global project like this some assumptions that have been made can't be made and why we should avoid this from the start rather than risk issues in 5 years.
[SM7I 2014-10-25- 03:50:19]: KG6JEI
We always encourage hams to follow RFC, but in the end it´s up to everyone to decide what fits into their existing IP -plan. In this case it´s of no big issue since the IP´s will never be exposed to the Internet, only through the tunnel.
Also here, with my ISP, this particular IP network is not routed outside by them. And from what I understand this IP network is used isolated by Google to perform certain scientific tests.
But, once again. We encourage hams to follow RFC for private address-spaces suitable fo their needs.
[KG6JEI 2014-10-24- 06:15:20]: Darryl: (Oops while I was typing Joe got to you so I've cleared my comment) SM7I: I took a look at your link. I'm concerned about the address space you are using for your VPN service and how it does not match reasonable internet standards. 1.1.1.0/24 is a public address space and should not be used on the mesh nodes without and assigned allocation from APNIC. The nodes are not configured to block routing 1.1.1.0/24 out to the public internet. You may be causing packet leakage by operating in this manner. APNIC has had serious issues with this http://www.potaroo.net/studies/1slash8/1slash8.pdf perhaps moving the the 172.31.x.x space BBHN is promoting for VPN's would be wise. |
IP Logged
|
IT infrastructure and security professional |
|
|
|
|
|
Subject :Re:Re:Re:Virtual Tunnels..
2014-10-25- 08:44:45
|
|
|
KG6JEI |
|
Member |
 |
Joined: 2013-12-02- 19:52:05
Posts: 516
Location: |
|
|
|
Forum :
General
Topic :
Virtual Tunnels
I'm not sure you can guarantee that.
As I noted we do not filter on the mesh nodes the 1.1.1.0/24 network. (Nor do I believe we should as it's a public network that could be put into service)
I can speak for myself and say in my current network setup leakage is 100% possible. Even with my Checkpoint/Palo Alto/Cisco/Custom firewalls in line 1.1.1.0/24 doesn't appear to be in my bogon lists by quick glance (likely because it is technically allocated)
Every mesh node advertises it's VPN IP address as one of it's IP's. This shows up in links on various pages of the BBHN/OLSR UI.
An example leakage possibility:
If the route goes down all of a sudden the fallback would be to send the packet out the nearest WAN GW. This by definition is leakage by crossing the bearer from BBHN to Local "WAN" network. Most home routers will likely not block it and on corporate routers it's not suppose to be blocked either. This causes further leakage into the routed internet.
Here is what happened in the past: "While network 1.0.0.0/8 was an unallocated and unadvertised network any such traffic directed to an address in this block that “leaked” into the public Internet would follow a “default” routing path to the point where there was a “default-free” routing element, where the traffic would be discarded. As soon as any such address in 1.0.0.0/8 was advertised as reachable into the public Internet, instead of being discarded as the boundary of the default-free zone (DFZ), the packets would be passed onto the destination rather than being discarded."
As seen once they advertised it it was routed. Also I notice you have a USA tunnel, can you guarantee that persons ISP won't route it ? How about every other node on that users mesh and their ISP's ? What about nodes that VPN into a node that's connected via rf to another node to another to one on the tunnel? As you can see this very quickly becomes a can of worms that becomes hard without positive control over 100% of the nodes in the system. Will it physically harm anyone, no, has it caused APNIC to declare space unusable,for the time being yes, will it likely be a lot of leaked traffic, no-but a lot of small traffic adds up to 800mbps spikes.
And yes I believe Google was brought in for some capacity based on that doc to help test, what they are/were testing I don't know, but if APNIC told them to do something then it's within APNICS's authority to do so as the allocating authority (I see the advert is currently associated to Google under their AS15169 in the BGP tables: http://bgp.he.net/AS15169#_prefixes ). Google does make sense in a lot of regards due to their number of peering points, get the data off the 'uncontrolled' net as quickly as possible and into the 'controlled' infrastructure where it can be accounted for sooner reducing the chances of some router blocking it giving false readings.
**note: not intended to be a fight, just trying to point out why I am concerned about this as a networking person who has spent a fair amount of time with the BBHN code, and why in a global project like this some assumptions that have been made can't be made and why we should avoid this from the start rather than risk issues in 5 years.
[SM7I 2014-10-25- 03:50:19]: KG6JEI
We always encourage hams to follow RFC, but in the end it´s up to everyone to decide what fits into their existing IP -plan. In this case it´s of no big issue since the IP´s will never be exposed to the Internet, only through the tunnel.
Also here, with my ISP, this particular IP network is not routed outside by them. And from what I understand this IP network is used isolated by Google to perform certain scientific tests.
But, once again. We encourage hams to follow RFC for private address-spaces suitable fo their needs.
[KG6JEI 2014-10-24- 06:15:20]: Darryl: (Oops while I was typing Joe got to you so I've cleared my comment) SM7I: I took a look at your link. I'm concerned about the address space you are using for your VPN service and how it does not match reasonable internet standards. 1.1.1.0/24 is a public address space and should not be used on the mesh nodes without and assigned allocation from APNIC. The nodes are not configured to block routing 1.1.1.0/24 out to the public internet. You may be causing packet leakage by operating in this manner. APNIC has had serious issues with this http://www.potaroo.net/studies/1slash8/1slash8.pdf perhaps moving the the 172.31.x.x space BBHN is promoting for VPN's would be wise. |
IP Logged
|
Note: Most posts submitted from iPhone |
|
|
|
|
|
Subject :Re:Advice on a large emergency mesh network in SW Minnesota..
2014-10-25- 07:27:19
|
|
|
W0ZZY |
|
Member |
 |
Joined: 2014-04-01- 20:43:52
Posts: 2
Location: SW Minnesota |
|
|
|
Forum :
General
Topic :
Advice on a large emergency mesh network in SW Minnesota
Well, it would appear that MnSwept is going a different direction with their data communications. Honestly, this is kind of a relief for me. However, several members of our local Ham community are still very excited about BBHN and are ready to start a much more local network networking between three towns 7 and 12 miles apart. We still need to cover a fair amount of ground, but since this is simply for the love of the hobby I'm really looking forward to it. Andre, thanks for pointing me in the right direction with BBHN and Radio Mobile. I just wanted to give you an update since you were generous enough to give me some of your time (especially when you were on vacation) Thanks for your help so far, and I'm sure i'll be back soon with more questions. |
IP Logged
|
Last Edited On: 2014-10-25- 07:31:19 By W0ZZY for the Reason
|
|
|
|
|
|
Subject :Re:Re:Virtual Tunnels..
2014-10-25- 03:50:19
|
|
|
SM7I |
|
Member |
 |
Joined: 2012-04-30- 14:56:55
Posts: 79
Location: JO65mo |
|
|
|
Forum :
General
Topic :
Virtual Tunnels
KG6JEI
We always encourage hams to follow RFC, but in the end it´s up to everyone to decide what fits into their existing IP -plan. In this case it´s of no big issue since the IP´s will never be exposed to the Internet, only through the tunnel.
Also here, with my ISP, this particular IP network is not routed outside by them. And from what I understand this IP network is used isolated by Google to perform certain scientific tests.
But, once again. We encourage hams to follow RFC for private address-spaces suitable fo their needs.
[KG6JEI 2014-10-24- 06:15:20]: Darryl: (Oops while I was typing Joe got to you so I've cleared my comment) SM7I: I took a look at your link. I'm concerned about the address space you are using for your VPN service and how it does not match reasonable internet standards. 1.1.1.0/24 is a public address space and should not be used on the mesh nodes without and assigned allocation from APNIC. The nodes are not configured to block routing 1.1.1.0/24 out to the public internet. You may be causing packet leakage by operating in this manner. APNIC has had serious issues with this http://www.potaroo.net/studies/1slash8/1slash8.pdf perhaps moving the the 172.31.x.x space BBHN is promoting for VPN's would be wise. |
IP Logged
|
IT infrastructure and security professional |
|
|
|
|
|
Subject :Re:Running ubiquiti nodes on batteries..
2014-10-25- 03:31:19
|
|
|
K6AH |
|
Member |
 |
Joined: 2012-03-05- 10:47:45
Posts: 181
Location: San Diego, CA |
|
|
|
Forum :
Hardware
Topic :
Running ubiquiti nodes on batteries
Don't bother. Passive injectors are cheap. Check out http://www.ebay.com/itm/passive-POE-injector-Wall-Mount-for-Mikrotik-Tranzeo-OpenMesh-Ubiquiti-9-48V-1A-/171212542706?pt=US_Network_Switch_Power_Supplies&hash=item27dd1012f2.
Can't beat the $3 price either. Andre, K6AH |
IP Logged
|
Member of:
Beta Test Team
San Diego Mesh Working Group
Running 3.0.1 |
|
|
|
|
|
Subject :Running ubiquiti nodes on batteries..
2014-10-25- 02:28:42
|
|
|
|
|
|
|
Subject :Re:adding ubiquiti nsm2 to 7 node wrt54-on-1.0.0..
2014-10-24- 18:04:05
|
|
|
ag6if |
|
Member |
 |
Joined: 2014-10-03- 13:53:22
Posts: 6
Location: |
|
|
|
Forum :
UBNT Firmware
Topic :
adding ubiquiti nsm2 to 7 node wrt54-on-1.0.0
Thanks Clint,
my first NSM2 came in today, what a beauty! I have a 2nd on order already.
cant wait to try a link.
I bought a few $3 POE injectors from ebay and this works great also. Takes the same 12v plug as the WRT and I already have powerpole cables aplenty.
Andre, sure would be nice to get a link to your location from mine.
Need that one good spot for a bridge..looking.
73
Jim |
IP Logged
|
|
|
|
|
|
Subject :Re:Hamnet access..
2014-10-24- 17:58:16
|
|
|
ag6if |
|
Member |
 |
Joined: 2014-10-03- 13:53:22
Posts: 6
Location: |
|
|
|
Forum :
Hardware
Topic :
Hamnet access
Yes, I run mine this way using a ver5+ WRT54.
The ver5+ wifi router must be pass-throu mode and not handling it's own DHCP or nat. Set the Mesh WRT to at least 5 host direct, or even 13 if you plan on connecting many devices throu the non mesh WRT.
73 Jim AG6IF |
IP Logged
|
|
|
|
|
|
Subject :Re:Virtual Tunnels..
2014-10-24- 10:54:16
|
|
|
|
|
|
|
Subject :Re:Re:Re:Re:Virtual Tunnels..
2014-10-24- 09:10:46
|
|
|
|
|
|
|
Subject :Re:Re:Re:Re:Virtual Tunnels..
2014-10-24- 06:23:56
|
|
|
VA7WPN |
|
Member |
 |
Joined: 2013-04-29- 12:21:43
Posts: 60
Location: BC, Canada |
|
|
|
Forum :
General
Topic :
Virtual Tunnels
The "http://44.140.236.17:8080" URL worked for me this time, This weekend, Im going to be boxing up a WRT54GS, along with a Ras-Pi, and trying out some of this tunneling, along with voip. I want to find out what we REALY can do with this equipment and tech. Iv been thinking of useing a similar system to monitor wireless Game-Cams where I hunt.
Like so I can pull up to the road, flip on my laptop, and download the photos / video's from the AP's. As well as monitor the areas so I know where the animals currently are. Sound like cheating, but will feed my family! |
IP Logged
|
|
|
|
|
|
Subject :Re:Virtual Tunnels..
2014-10-24- 06:15:20
|
|
|
KG6JEI |
|
Member |
 |
Joined: 2013-12-02- 19:52:05
Posts: 516
Location: |
|
|
|
Forum :
General
Topic :
Virtual Tunnels
Darryl: (Oops while I was typing Joe got to you so I've cleared my comment) SM7I: I took a look at your link. I'm concerned about the address space you are using for your VPN service and how it does not match reasonable internet standards. 1.1.1.0/24 is a public address space and should not be used on the mesh nodes without and assigned allocation from APNIC. The nodes are not configured to block routing 1.1.1.0/24 out to the public internet. You may be causing packet leakage by operating in this manner. APNIC has had serious issues with this http://www.potaroo.net/studies/1slash8/1slash8.pdf perhaps moving the the 172.31.x.x space BBHN is promoting for VPN's would be wise. |
IP Logged
|
Note: Most posts submitted from iPhone |
|
|
|
|
|
Subject :Re:Re:Re:Re:Virtual Tunnels..
2014-10-24- 06:02:02
|
|
|
k5dlq |
|
Member |
 |
Joined: 2012-05-11- 08:05:13
Posts: 233
Location: Magnolia, TX USA |
|
|
|
Forum :
General
Topic :
Virtual Tunnels
I running the server on WRT54GSv2.
However, I currently have the firewall disabled (/etc/init.d/firewall stop) and still get the port "698 unreachable" coming from my tun1 interface. |
IP Logged
|
Darryl - K5DLQ
www.aredn.org |
|
|
|
|
|
Subject :Re:Re:Re:Re:Virtual Tunnels..
2014-10-24- 05:56:35
|
|
|
AE6XE |
|
Member |
 |
Joined: 2013-11-05- 00:09:51
Posts: 116
Location: |
|
|
|
Forum :
General
Topic :
Virtual Tunnels
Darryl, If this is UBNT hardware, check out the upload in an earlier post in this thread. I posted a tar file with the /etc/config/firewall settings for all the ports to work. Essentially, clone the dtdlink firewall settings. |
IP Logged
|
|
|
|
|
|
Subject :Re:Re:Re:Re:Virtual Tunnels..
2014-10-24- 05:17:33
|
|
|
|
|
|
|
Subject :Re:Virtual Tunnels..
2014-10-23- 21:14:02
|
|
|
SM7I |
|
Member |
 |
Joined: 2012-04-30- 14:56:55
Posts: 79
Location: JO65mo |
|
|
|
Forum :
General
Topic :
Virtual Tunnels
VA3WPN
Try again, there was a slight routingissue, but it´s taken care of now. |
IP Logged
|
Last Edited On: 2014-10-23- 21:14:31 By SM7I for the Reason
|
IT infrastructure and security professional |
|
|
|
|
|
Subject :Re:Virtual Tunnels..
2014-10-23- 16:54:33
|
|
|
KG6JEI |
|
Member |
 |
Joined: 2013-12-02- 19:52:05
Posts: 516
Location: |
|
|
|
Forum :
General
Topic :
Virtual Tunnels
Daryl: start at the simple parts, verify ping , verify olsr packets being recieved and transmitted (tcpdump) etx on the interface first and work your way up. OLSR has to have the data before routing can become a question and so on so work the issue from the bottom up or top down on each item. |
IP Logged
|
Note: Most posts submitted from iPhone |
|
|
|
|