Toshiba TV29C90 problem; Image fades to black...

[Clément Durand]

Jeff Liebermann wrote, on Mon, 11 Aug 2014 09:43:50 -0700:

#!/bin/bash
test_with_ping()
{
ping -c 1 $1 > /dev/null
[ $? -eq 0 ] && echo $IP,UP
[ $? -eq 1 ] && echo $IP,dn
}

for IP in 192.168.1.{1..254}
do
test_with_ping $IP & disown # run in background
done

Use "nohup" if your bash doesn't do "disown".

I think I can figure out the IP addresses connected to the home broadband
router by looking for src=192.168.1.XXX addresses in the previously
mentioned /proc/net/nf_conntrack file.

I did try the script on the Ubiquiti Rocket M2 2.5GHz radio, but, bash
wasn't found (so I changed the shell to "ash") and neither "disown" nor
"nohup" were found.

The script did run, but it didn't output anything (so I need to debug it
further).

But, I think the main issue now is to glean all the information I need
out of the /proc/net/nf_conntrack file because it *seems* to contain
every IP address that goes in and out of the rooftop radio.

While this is WISP, for people with DSL or cable, logging into that
rooftop transceiver would be equivalent to logging into their modem.

 

[Clément Durand]

ClĂŠment Durand wrote, on Mon, 11 Aug 2014 19:46:01 +0000:

> Both iwlist & iwconfig exist, so I will try to learn their syntax.

Running iwconfig first, it tells me "ath0" is the NIC of interest:

$ ssh 192.168.1.20 -l ubnt

XM.v5.5.8# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
eth1 no wireless extensions.
wifi0 no wireless extensions.
br0 no wireless extensions.
ath0
IEEE 802.11ng ESSID:"ROCKET_M2" Nickname:"Rocket_WiFi"
Mode:Managed Frequency:2.417 GHz Access Point: 00:AF:00:BFA:48
Bit Rate:104 Mb/s Tx-Power=26 dBm Sensitivity:0/0
Retryff RTS thrff Fragment thrff
Encryption key:0922-02A0-4792-CBFA-A89F-1CDC
Security mode:restricted
Power Managementff
Link Quality=40/94 Signal level=-56 dBm Noise level=-88 dBm
Rx invalid nwid:7 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

Then, running "iwlist ath0", I find out some information.

This looks like it gives me the local access points nearby:

XM.v5.5.8# iwlist ath0 ap
ath0 Peers/Access-Points in range:
DA:8FC:14:E2:BC Quality=46/94 Signal level=-50 dBm Noise level=-96 dBm
10:57:22:9F:AC:5E Quality=41/94 Signal level=-55 dBm Noise level=-88 dBm
10:90:48:69:92:33 Quality=22/94 Signal level=-74 dBm Noise level=-88 dBm
CC:C8:55:8C:6F:41 Quality=18/94 Signal level=-78 dBm Noise level=-88 dBm
CA:8F:15:27:97:68 Quality=18/94 Signal level=-78 dBm Noise level=-96 dBm
61:3A:4C:E5:B91 Quality=16/94 Signal level=-80 dBm Noise level=-88 dBm
91:72:4F:1F:91:1C Quality=16/94 Signal level=-80 dBm Noise level=-88 dBm
15:80:4E:69:92:34 Quality=16/94 Signal level=-80 dBm Noise level=-88 dBm
10:15:8D:AC:03:88 Quality=15/94 Signal level=-81 dBm Noise level=-88 dBm
F11:F9:12:9D:1E Quality=15/94 Signal level=-81 dBm Noise level=-88 dBm
21:C9:80:F3:98:7C Quality=10/94 Signal level=-86 dBm Noise level=-88 dBm
1B:12:C6:22:24:9F Quality=09/94 Signal level=-87 dBm Noise level=-88 dBm
10:1C:63:2B:4F:47 Quality=09/94 Signal level=-87 dBm Noise level=-88 dBm
F1:13:4E:10:35:4F Quality=09/94 Signal level=-87 dBm Noise level=-88 dBm
18:0F:C3:F30:66 Quality=07/94 Signal level=-89 dBm Noise level=-96 dBm
1A:23:87:1C:F7:17 Quality=07/94 Signal level=-89 dBm Noise level=-96 dBm

This seems to list the rooftop radio transmit power:
XM.v5.5.8# iwlist ath0 txpower
ath0 8 available transmit-powers :
10 dBm (10 mW)
16 dBm (39 mW)
18 dBm (63 mW)
20 dBm (100 mW)
22 dBm (158 mW)
24 dBm (251 mW)
26 dBm (398 mW)
28 dBm (630 mW)
Current Tx-Power=24 dBm (251 mW)

This seems to scan for all the WiFi routers in the vicinity of the rooftop
radio:
XM.v5.5.8# iwlist ath0 scanning
It lists dozens of "cells", here's just one example:
Cell 02 - Address: 00:A0:55:AC:83:2A
ESSID:"Netgear"
Mode:Master
Frequency:2.417 GHz (Channel 2)
Quality=15/94 Signal level=-81 dBm Noise level=-88 dBm
Encryption keyn
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Extra:bcn_int=100
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : CCMP TKIP
Authentication Suites (1) : PSK
Extra:mtik_ie=really long number

In summary, these two commands (iwconfig & iwlist) are interesting,
as they provide information about signal strengths of nearby
access points, none seem to tell me which PCs are attached to the
home broadband router, nor what destination IP addresses those
devices are going to.

Nice commands otherwise!

 

[Jeff Liebermann]

On Mon, 11 Aug 2014 10:10:05 +0000 (UTC), Clément Durand
<ClementDurand@nowhere.example.com> wrote:

I'm surprised Jeff Liebermann hasn't responded, since he knows
everything about setting up WiFi security,

I don't do security. I hate security. I'm also busy, lazy, bored,
and playing with a few new toys and software. However, I don't have a
Ubiquiti M2 handy to test my guesswork.

Try:
arp -a
and see what it produces. You might get lucky.

Also, play with iwlist and iwconfig to see if they show connected
wireless devices (by MAC address).

Otherwise, try a bash script that pings everything in your IP block.
Something like this (untested):

#!/bin/bash
test_with_ping()
{
ping -c 1 $1 > /dev/null
[ $? -eq 0 ] && echo $IP,UP
[ $? -eq 1 ] && echo $IP,dn
}

for IP in 192.168.1.{1..254}
do
test_with_ping $IP & disown # run in background
done

Use "nohup" if your bash doesn't do "disown". To run 254 IP's, at
about 1 second per IP, will take about 5 minutes. There's also no
guarantee that the connected machine will respond to an ICMP ping
request.

Are you perhaps trying to build a network map from scratch? If so,
there are network mapping tools that will do the heavy lifting for
you.

"Russia Bans Anonymous Access To Wi-Fi"
<http://cellular-news.com/story/Regulatory/66778.php>



--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

 

[Clément Durand]

ClĂŠment Durand wrote, on Tue, 12 Aug 2014 02:25:20 +0000:

> That's OK, but often it gives nothing useful.

nslookup is ok, but most of the time, nslookup reports nothing.



tail /proc/net/nf_conntrack|awk '{print $7}'
src=74.125.103.57
src=157.55.135.18
src=173.194.25.148
src=23.235.255.22


tail /proc/net/nf_conntrack|awk '{print $7}'|sed -e 's/src=/nslookup /'
nslookup 74.125.103.57
nslookup 157.55.135.18
nslookup 173.194.25.148
nslookup 23.235.255.22

tail /proc/net/nf_conntrack|awk '{print $7}'|sed -e 's/src=/nslookup /'>/tmp/script
chmod u+x /tmp/script
/tmp/script

The result is that all of those IP addresses come up blank with nslookup.

Is there a better Linux command line tool for reverse IP lookups?

NOTE: These are not available on the Ubiquiti Rocket M2 radio.
dig +noall +answer -x 74.125.20.188
host 74.125.20.188
getent hosts 74.125.20.188
nbstat -a 74.125.20.188

 

[Jeff Liebermann]

On Mon, 11 Aug 2014 19:46:01 +0000 (UTC), Clément Durand
<ClementDurand@nowhere.example.com> wrote:

>-sh: arp: not found

Try:
cat /proc/net/arp
or:
ip neigh show dev br0
br0 might be eth0 or something else if your M2 is setup as a router.

I'm mainly trying to understand what's going on, by looking at
whatever information is available to me as I log into the rooftop
radio.

One must suffer before enlightenment.

Some of the key stuff I'm trying to figure out remotely is what
IP addresses are connected to the home broadband router,

<http://home.comcast.net/~jay.deboer/airsnare/>

and, what
destination IP addresses those clients are attempting to visit.

I usually use SNMP in the router in order to get that info.
If (and only if) your Ubiquiti is setup as a bridge, you can sniff the
traffic between the wireless bridge and the router (on the router WAN
port), and get the same information. Insert a HUB (not a SWITCH)
between the Ubiquiti M2 and your unspecified router. Add a PC running
WireShark or your favorite sniffer software, and you should get
something useable.

You can also sniff just the HTTP traffic with:
<http://www.nirsoft.net/utils/http_network_sniffer.html>
Take a good look at Nir Sofer's tools. They're quite useful:
<http://www.nirsoft.net>

I think I have made headway on finding the home broadband router
IP address by lookint at the /etc/dnsmasq.conf file.

Go thee unto Google at:
https://www.google.com
Inscribe into the designated search box the words of empowerment:
"what is my IP"
Through the magic of Google, your WAN IP address will be displayed.

I think there's a ton of information about the destination IP
addresses in the /proc/net/nf_conntrack file.

Dunno. I don't have any Ubiquiti hardware handy to test it.

So, I have a long way to go ... but every bit of advice helps,
and, I, for my part, will echo back what I've learned to the
group by way of payback.

Learn by destroying, which means that if you haven't broken something,
you don't really understand how it works.

<http://www.darkreading.com/application-security/10-free-or-low-cost-network-discovery-and-mapping-tools/d/d-id/1141182>

Now, go away so I can get some paying work done.

--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

 

In sci.electronics.repair Clément Durand <ClementDurand@nowhere.example.com> wrote:
> nslookup is ok, but most of the time, nslookup reports nothing.

It isn't a requirement that any given IP address also has a DNS entry;
it's OK for nslookup to have no answer for some IP addresses. Almost
any given IP address *should* have a "whois" record, which indicates
who that block of addresses is assigned to. The command-line tool
whois can be used to look this up.

The simplest query is like this:

whois 74.125.103.57

which tells me that that IP address is in a block assigned to Google.
If you don't have the command-line 'whois' tool on your radio, a desktop
Linux distribution will. There are also many online 'whois' tools that
can be used from a web browser. I don't know if Windows ships with a
whois tool or not.

> src=157.55.135.18

Microsoft.

> src=173.194.25.148

Google again.

> src=23.235.255.22

This is part of a big block (23.235.224.0/19) assigned to Secured
Servers LLC in Tempe, Arizona. Secured Servers has in turn "sublet"
some of this block (23.235.255.0/24) to MC Pro Hosting of Fort
Lauderdale, FL. (See the "Found a referral..."

Matt Roberds

 

[Clément Durand]

mroberds wrote, on Tue, 12 Aug 2014 03:52:57 +0000:

whois 74.125.103.57

which tells me that that IP address is in a block assigned to Google.
If you don't have the command-line 'whois' tool on your radio, a desktop
Linux distribution will.

Hi Matt,

Thanks for suggesting "whois" and for running the tests.

I just logged into the rooftop radio to test if "whois" is there:

$ ssh 191.168.1.20 -l ubnt -p 22 (login=ubnt, ssh port=22)

BusyBox v1.11.2 (2014-02-05 18:21:05 EET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

XM.v5.5.8# whois 74.125.103.57
-sh: whois: not found

Drat. As you had surmised, "whois" isn't on the radio linux.

But, you're right. The "whois" command worked just fine on
a desktop Linux, so, what I can do is somehow figure out how to
"rcp" the radio /proc/net/nf_conntrack to my Linux machine.

I tried "rcp" & "ftp" but neither was found on the Radio Linux.

Do you know of a way to get the entire /proc/net/nf_conntrack
over to my Linux machine?

 

In sci.electronics.repair Clément Durand <ClementDurand@nowhere.example.com> wrote:

Do you know of a way to get the entire /proc/net/nf_conntrack
over to my Linux machine?

Since you can ssh into the radio, scp from the desktop Linux machine
might work:

$ scp -P 22 ubnt@191.168.1.20:/proc/net/nf_conntrack nf_conntrack

This should give you a copy of the radio's nf_conntrack file in the
current directory on the desktop Linux box.

Otherwise, you might be able to do something like this, starting on
the desktop box:

desktop$ script conntrack.txt
Script started, file is conntrack.txt
desktop$ ssh 191.168.1.20 -l ubnt -p 22
radio# cat /proc/net/nf_conntrack
[contents of file appear here]
radio# logout
desktop$ exit
Script done, file is conntrack.txt

This will put everything that came to the screen in conntrack.txt on the
desktop box. It will include control characters and stuff, so you'll
have to edit that out of conntrack.txt with your favorite text editor
before proceeding.

Matt Roberds

 

[Clément Durand]

mroberds wrote, on Tue, 12 Aug 2014 15:37:49 +0000:

scp from the desktop Linux machine might work:

$ scp -P 22 ubnt@191.168.1.20:/proc/net/nf_conntrack nf_conntrack

Hi Matt,
The scp command, from Linux, worked perfectly.

Otherwise, you might be able to do something like this,
desktop$ script conntrack.txt

Thanks Matt, as that's a very nice command!
It has a lot of funky characters in the results, but other
than that, it's a really nice trick!

1. Start the script on the Linux laptop:
$ script /tmp/net.script
2. Log into the rooftop modem (transceiver):
$ ssh -p 2200 -l ubnt 192.168.1.20
3. Spit out the file:
# cat /proc/net/nf_conntrack nf_conntrack
4. Exit out of the radio
# exit
5. Exit out of the script
$ exit
6. Strip the funky characters out of the results:
$ col -b /tmp/net.script > /tmp/net.txt

 

[Clément Durand]

Jeff Liebermann wrote, on Mon, 11 Aug 2014 16:19:40 -0700:

> Now, go away so I can get some paying work done.

Thanks for your help. I do appreciate it.
Since the documentation on interpreting the nf_conntrack file
was so dismal, I wrote my own documentation, from many sources.

Here is it, as payback, for all the help from others.

Here's my first attempt at an interpretation of a sample line from my nf_conntrack file:

ipv4 2 tcp 6 56808 ESTABLISHED src=72.167.183.54 dst=69.63.240.15 sport=80 dport=49437 [UNREPLIED] src=69.63.240.15 dst=72.167.183.54 sport=49437 dport=80 mark=0 use=2
My interpretation:
An ESTABLISHED TCP connection from source host 72.167.183.54, port 80
To destination host 69.63.240.15, port 49437
From which responses are sent to host 72.167.183.54, port 49437
Timing out in 56808 seconds (i.e., more than 15 hours)
UNREPLIED means traffic hasn't been seen in the response direction yet
In addition, the:
Network layer protocol name is ipv4
Network layer protocol number is 2
Transmission layer protocol name is tcp
Transmission layer protocol number is 6
Seconds until the entry is invalidated is 56808 (i.e., more than 15 hours)


Here is another attempt at interpreting an example from my nf_conntrack log file:

ipv4 2 icmp 1 16 src=142.28.53.15 dst=10.50.0.241 type=8 code=0 id=39196 src=10.50.0.241 dst=142.28.53.15 type=0 code=0 id=39196 mark=0 use=2
My interpretation:
An ICMP echo request packet from source host 142.28.53.15
To destination host 10.50.0.241
With an expected echo reply packet from source hosts 10.50.0.241
To destination host 142.28.53.15
Timing out in 16 seconds
In addition, the:
Network layer protocol name is ipv4
Network layer protocol number is 2
Transmission layer protocol name is icmp
Transmission layer protocol number is 1
Seconds until the entry is invalidated is 16 seconds


It seems both ip_conntrack & nf_conntrack are similar in format, where nf_conntrack simply has two extra columns at the beginning of each line, so this list below attempts to describe the first six nf_conntrack columns, as I understand them:

1. Network layer protocol name (e.g., ipv4)
2. Network layer protocol number (e.g., 2)
3. Transmission layer protocol name (e.g., tcp)Transmission layer protocol number (e.g., 6)
4. Seconds until the entry is invalidated (e.g., 75114)
5. The connection state (e.g., ESTABLISHED, but this is not always there for all protocols)

It seems that the #5 connection state can be any of the following:

DCCP

CLOSEREQ
CLOSING
IGNORE
INVALID
NONE
OPEN
PARTOPEN
REQUEST
RESPOND
TIME_WAIT

SCTP

CLOSED
COOKIE_ECHOED
COOKIE_WAIT
ESTABLISHED <== many of mine were this
NONE
SHUTDOWN_ACK_SENT
SHUTDOWN_RECD
SHUTDOWN_SENT

TCP

CLOSE
CLOSE_WAIT
ESTABLISHED
FIN_WAIT
LAST_ACK
NONE
SYN_RECV
SYN_SENT
SYN_SENT2
TIME_WAIT <== many of mine were this

The rest of the columns are apparently either of the format KEY=VALUE or they represent FLAGs.

KEY=VALUE examples:

src=123.456.789.001
dst=123.456.789.002
sport=80 (tcp & udp only)
dport=54259 (tcp & udp only)
mark=0 (if CONFIG_NF_CONNTRACK_MARK is enabled)
use=2
type=0 (for icmp only)
code=0 (for icmp only)
id=39196 (for icmp only)
bytes (if accounting is enabled)
delta-time (if CONFIG_NF_CONNTRACK_TIMESTAMP is enabled)
packets (if accounting is enabled, request and response)
secctx (if CONFIG_NF_CONNTRACK_SECMARK is enabled)
zone (if CONFIG_NF_CONNTRACK_ZONES is enabled)

Note that the response destination host can differ from the request source host when the request source address has been masqueraded by the response destination host.

FLAG examples:

[ASSURED]: Traffic has been seen in both directions (request & response)
[UNREPLIED]: Traffic has not been seen in the response direction yet
-----
ESTABLISHED (connection state)
TIME_WAIT (connection state)

 

[HASM]

ClĂŠment Durand <ClementDurand@nowhere.example.com> writes:

$ ssh 191.168.1.20 -l ubnt -p 22 (login=ubnt, ssh port=22)
I tried "rcp" & "ftp" but neither was found on the Radio Linux.
Do you know of a way to get the entire /proc/net/nf_conntrack
over to my Linux machine?

Have you tried scp from the machine where you ssh from?
scp ubnt@191.168.20:/proc/net/nf_conntrack
-- HASM

 

I am having the same problem. Sound is great on tape monitor, but got hardly anything on radio or aux.

Do you have those files you sent to the other guy who had this problem

 

[Trevor Wilson]

On 13/08/2014 6:46 AM, beaucarbert@gmail.com wrote:

I am having the same problem. Sound is great on tape monitor, but got hardly anything on radio or aux.

Do you have those files you sent to the other guy who had this problem

**Connect your tape deck correctly. Refer to your instruction manual.
You have probably transposed your inputs and outputs.

--
Trevor Wilson www.rageaudio.com.au

 

[William Sommerwerck]

wrote in message news:9935c89e-9ed4-4fac-a8fd-c3ce8bf2ac25@googlegroups.com...

> Sound is great on tape monitor, but got hardly anything on radio or aux.

Sounds like a busted tape monitor switch, that isn't passing the non-tape
inputs.

Try hooking another amp to the Tape Rec outputs, and see whether they play.

 

[Elechi Amadi]

On Wed, 13 Aug 2014 00:53:38 -0500, Elechi Amadi wrote:

Here's a picture of the OEM EP-TA10JWS charger, showing the 5.3 volts!
http://www.amazon.com/Samsung-Galaxy-Travel-Charger-EP-TA10JWS/dp/B00H8482KQ

What I'm worried about is that I can't find a car adapter that
is 5.3 volts and 2.0 amps or more.

Actually, that's the wrong picture.
Here's the right picture showing 5.3 volts at 2.0 amps output.
http://www.wirelessground.com/samsung-galaxy-note-3-travel-charger-2-amp.html

 

[Elechi Amadi]

On Wed, 13 Aug 2014 01:26:35 -0400, nospam wrote:

usb must be 5v +- 0.25v, or 4.75-5.25v, which means the oem charger is
not usb compliant.

Here's a picture of the OEM EP-TA10JWS charger, showing the 5.3 volts!
http://www.amazon.com/Samsung-Galaxy-Travel-Charger-EP-TA10JWS/dp/B00H8482KQ

What I'm worried about is that I can't find a car adapter that
is 5.3 volts and 2.0 amps or more.

 

[Helmer Bengtsson]

As for the title question, I never myself could figure out the difference.
If you know, tell me because it makes no sense class 1 or class 2 except
from a driver perspective.

 

[nospam]

In article
<10537$53eafd62$43da7656$16936@nntpswitch.blueworldhosting.com>, Elechi
Amadi <ElechiAmadi@example.com> wrote:

usb must be 5v +- 0.25v, or 4.75-5.25v, which means the oem charger is
not usb compliant.

Here's a picture of the OEM EP-TA10JWS charger, showing the 5.3 volts!
http://www.amazon.com/Samsung-Galaxy-Travel-Charger-EP-TA10JWS/dp/B00H8482KQ

€ Input: 100-240V ~ 50-60Hz, 0.35A / Output: 5.0V=== 2.0A

from the comments, there seems to be more than one version

What I'm worried about is that I can't find a car adapter that
is 5.3 volts and 2.0 amps or more.

don't worry about it. it doesn't matter.

5.3v is noncompliant.

all adapters will be 5v (or sometimes 5.1v). it makes no difference.

 

[Elechi Amadi]

On Wed, 13 Aug 2014 02:05:31 -0400, nospam wrote:

> Input: 100-240V ~ 50-60Hz, 0.35A / Output: 5.0V=== 2.0A

I had referenced the wrong charger.
The OEM charger for the Note III is 5.3 volts, 2.0 Amps.
http://forum.xda-developers.com/showthread.php?t=2504456

I can't find a 5.3 volt adapter for the car.

 

[Helmer Bengtsson]

The move to USB 3.0 only affects charge rates connected to a PC.

2.x is limited to 500mA while 3.x is 900mA I think.

Both standards use 5V, but 2A AC chargers often run a bit higher at 5.3V.
The chargers don't directly adhere to either USB spec and basically
trigger fast charge the same as before, by shorting out or putting a
fixed resistance between the data pins.

My old HP TouchPad USB 5.3V/2A charger with 2.0 cord charges my Note 3
just as fast as the Samsung 5.3V/2A adapter with USB 3.0 cord does.

If you look closely, you'll notice that the "USB 3.0" Samsung charger
doesn't actually have the extra 3.0 pins, it uses a 2.0 port. That's
because for pure charging devices the standard doesn't matter, only the
current and voltage rating and that it shorts the data pins.