View Single Post
Old 01-31-2013, 01:07 PM   #1
knc1
Helpdesk Junkie
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 7,004
Karma: 6359394
Join Date: Feb 2012
Device: Too many.
USBnet installation under the new Launcher

This post is a continuation of the post here:
http://www.mobileread.com/forums/sho...&postcount=192

Grab the kindle-usbnet-0.7.N.zip package from:
http://www.mobileread.com/forums/sho...d.php?t=186645
Don't believe that title - that thread is also the home of the USBnetwork package.

un-zip the package to a local directory on your PC.
Read the README_FIRST.txt file. This is a test, you must pass it.
Is there anything mentioned in there about networking administration you don't know?
Well, like the author says, then don't use this package.

Place the 'install' package on root of USB storage, eject USB storage, un-plug the cable since you are about to mess with the cable's hardware interface . . . .
Do the usual: home -> menu -> settings -> menu -> update Kindle routine.

Conditions:
You have just installed the USBnetwork (version 0.7.N) package.
You did not change anything in its configuration file.
You are using the new Application Launcher.
Your host machine is running a Linux distribution with an unknown (here) amount of network automation.
(This remote is a Kpw running 5.3.3 firmware, some of the early v-2, and v-3 firmwares act a bit differently.)

Try the obvious (to a noob) thing - plug up the USB cable -

This may (most likely will) trigger the network automation on your host machine.
Using your network controls (usually an icon) force a disconnect on the newly found USB0 network device.
(Or otherwise club to death the automation with whatever big stick your distribution requires.)

The command (on your PC): ip link show
should still show the network device USB0 in its list (if not, you used too big of a club above).

Before trying to automate anything, either on the host PC or on the remote Kindle, you need to find out how to make it all work.

From the README_FIRST.txt file, you know that you need to assign an address at the PC end of the cable. The recommended addresses are shown in the following command:
Code:
core2quad ~ $ sudo ip address add 192.168.15.201 peer 192.168.15.244 dev usb0
Translation: A point-to-point link, address 192.168.15.201 at the PC end, expected address 192.168.15.244 at the remote end, using network device USB0.

The IPROUTE2 utility along with the kernel sets the link addresses and the routing.

Display that the routing is as expected:
Code:
core2quad ~ $ ip route
default via 169.254.0.4 dev eth0  proto static 
169.254.0.0/22 dev eth0  proto kernel  scope link  src 169.254.0.88  metric 1 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.15.244 dev usb0  proto kernel  scope link  src 192.168.15.201
It is only the last line of that report which we just set, any other lines may differ on your own machine.

Now display the status of the link:
Code:
core2quad ~ $ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:30:1b:bc:e5:7d brd ff:ff:ff:ff:ff:ff
6: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether ee:49:00:00:00:00 brd ff:ff:ff:ff:ff:ff
The link is down, and no carrier is detected. You aren't going to bring it up without "carrier detected".

Now toggle USBnetwork in Launcher.

NO GOOD - That doesn't work to bring it up (because of the no carrier condition)
Now disconnect USB cable (per ixtab).

toggle USBnetwork -
HERE:
plug in cable -
eject the storage device -
toggle USBnetwork -
and ....

See if you can bring up the PC end now:
Code:
core2quad ~ $ sudo ip link set up dev usb0
Display what that did for us:
Code:
core2quad ~ $ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:30:1b:bc:e5:7d brd ff:ff:ff:ff:ff:ff
7: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether ee:49:00:00:00:00 brd ff:ff:ff:ff:ff:ff
It LIVES! We have carrier now and the link is UP!

Is our routing what we expect?
Code:
core2quad ~ $ ip route show
default via 169.254.0.4 dev eth0  proto static 
169.254.0.0/22 dev eth0  proto kernel  scope link  src 169.254.0.88  metric 1 
169.254.0.0/16 dev eth0  scope link  metric 1000
No route (yet) which is as expected.

How about the address assignments?
Code:
core2quad ~ $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:30:1b:bc:e5:7d brd ff:ff:ff:ff:ff:ff
    inet 169.254.0.88/22 brd 169.254.3.255 scope global eth0
    inet6 fe80::230:1bff:febc:e57d/64 scope link 
       valid_lft forever preferred_lft forever
7: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether ee:49:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ec49:ff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever
That's looking good also (the Kindles don't do IPv6 (yet) but its there anyway thanks to the kernel).
So next we need to assign the end point addresses:
Code:
core2quad ~ $ sudo ip address add 192.168.15.201 peer 192.168.15.244 dev usb0
Same as the first try above, but this time the link interface is up and running.

Check our address assignments:
Code:
core2quad ~ $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:30:1b:bc:e5:7d brd ff:ff:ff:ff:ff:ff
    inet 169.254.0.88/22 brd 169.254.3.255 scope global eth0
    inet6 fe80::230:1bff:febc:e57d/64 scope link 
       valid_lft forever preferred_lft forever
7: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether ee:49:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.15.201 peer 192.168.15.244/32 scope global usb0
    inet6 fe80::ec49:ff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever
Just what we intended, and the README_FIRST.txt document described.

How about the routing, did that get setup as expected?
Code:
core2quad ~ $ ip route show
default via 169.254.0.4 dev eth0  proto static 
169.254.0.0/22 dev eth0  proto kernel  scope link  src 169.254.0.88  metric 1 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.15.244 dev usb0  proto kernel  scope link  src 192.168.15.201
Whoot! we have a network route to the Kindle.

Quick check if the link is passing packets:
Code:
core2quad ~ $ ping -c 3 192.168.15.244
PING 192.168.15.244 (192.168.15.244) 56(84) bytes of data.
64 bytes from 192.168.15.244: icmp_req=1 ttl=64 time=2.30 ms
64 bytes from 192.168.15.244: icmp_req=2 ttl=64 time=0.616 ms
64 bytes from 192.168.15.244: icmp_req=3 ttl=64 time=0.594 ms

--- 192.168.15.244 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.594/1.171/2.303/0.800 ms
Yup - the Kindle is talking back to us.

See what network services (ports) are now open on the Kindle:
Code:
core2quad ~ $ nmap 192.168.15.244

Starting Nmap 5.21 ( http://nmap.org ) at 2013-01-31 10:05 CST
Nmap scan report for 192.168.15.244
Host is up (0.014s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
23/tcp open  telnet

Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds
Just as expected (USBnetwork installs both SSHD and TELNETD).

Now - toggle it off with the launcher helper

Did the link go out of service?
Code:
core2quad ~ $ ping -c 3 192.168.15.244
PING 192.168.15.244 (192.168.15.244) 56(84) bytes of data.
^C
--- 192.168.15.244 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms
Yup, link is no longer passing packets.

Did the network stack detect the status change?
Code:
core2quad ~ $ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:30:1b:bc:e5:7d brd ff:ff:ff:ff:ff:ff
7: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether ee:49:00:00:00:00 brd ff:ff:ff:ff:ff:ff
Yup, network interface is now shown as down and dead.

Did the network stack clean up the routing table?
Code:
core2quad ~ $ ip route show
default via 169.254.0.4 dev eth0  proto static 
169.254.0.0/22 dev eth0  proto kernel  scope link  src 169.254.0.88  metric 1 
169.254.0.0/16 dev eth0  scope link  metric 1000
Yup, nothing being routed to the dead network interface device now.

Did the network stack clean up the address table?
Code:
core2quad ~ $ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:30:1b:bc:e5:7d brd ff:ff:ff:ff:ff:ff
    inet 169.254.0.88/22 brd 169.254.3.255 scope global eth0
    inet6 fe80::230:1bff:febc:e57d/64 scope link 
       valid_lft forever preferred_lft forever
7: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether ee:49:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ec49:ff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever
Sure enough our IPv4 address is gone.
(The IPv6 address is still there, but that is because of how IPv6 works its 'auto-configuration'.)

= = = =

Let Kindle go to sleep -
Cable is still connected -
USBnetwork was (and is) toggled off -

Wake the Kindle -
No carrier detected.

Toggle the USBnetwork in the launcher -
No carrier detected.
Try it a few more times, just to be sure -
No carrier detected.

Translation: Use THIS sequence:
Spoiler:

This order should work on all firmware versions.
Early firmwares, v-2 and v-3 may also work with the cable attached
  • un-plug cable (if still plugged in)
  • toggle USBnetwork ON in launcher
  • plug the cable
  • kill any automation (or configure yours to do: )
  • sudo ip link set up dev usb0 (It may already be up)
  • sudo ip address add 192.168.15.201 peer 192.168.15.244 dev usb0
  • use the networking until your done
  • un-plug cable
  • toggle USBnetwork OFF in launcher


HINT: Use the 'Prevent ScreenSaver' feature of the Launcher helpers to keep the device from going to sleep on you when you least expect it.

HINT: telnet 192.168.15.244
Requires no setup, no password, just works.

Last edited by knc1; 05-14-2014 at 02:34 PM.
knc1 is offline   Reply With Quote