USBnet installation under the new Launcher

knc1 · 01-31-2013, 12:07 PM

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

Grab the kindle-usbnet-0.7.N.zip package from:
https://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:

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.

twobob · 01-31-2013, 03:04 PM

Excellent write up. I may nudge Niluje to link to it.

Blinder

knc1 · 01-31-2013, 04:10 PM

Quote:

Originally Posted by twobob

Excellent write up. I may nudge Niluje to link to it.

Blinder

Thanks.
Maybe it is the "doing the obvious" that is tripping up some people, it caught me.

twobob · 01-31-2013, 05:53 PM

Quote:

Originally Posted by knc1

Thanks.
Maybe it is the "doing the obvious" that is tripping up some people, it caught me.

Meh. I have to agree. Get's me every time that "Obvious" stuff...

Don't even get me started on "Common Sense", if I had a nickel for every time someone with none bandied that term about...

What you describe is, of course, the bread and butter cornerstone of worked use-case research

Armed with the weapon of the README and the HOWTO the developer attempts to guide his flock. But if the gambolling group are in "tldr;" mode that day? You're Flocked.

Here's one more - elucidating - "README!!!".... Let's hope the right persons read it.

NiLuJe · 02-01-2013, 01:03 PM

I'm assuming all of this came from trying to switch with a cable plugged in ^^ ?

FWIW, it does still work on 'older' devices (FW 2.x & 3.X), where the script doesn't rely on volumd, and does the switch itself. On newer devices, we *have* to go through volumd, and the bunch of checks I added to make sure the interface comes up at the expected time and on the expected IP, make it impossible to do it while the Kindle is plugged (in which case the hack ends up shouting an eips warning on the bottom of the screen after a dozen seconds, IIRC).

knc1 · 02-01-2013, 01:29 PM

Quote:

Originally Posted by NiLuJe

I'm assuming all of this came from trying to switch with a cable plugged in ^^ ?

FWIW, it does still work on 'older' devices (FW 2.x & 3.X), where the script doesn't rely on volumd, and does the switch itself. On newer devices, we *have* to go through volumd, and the bunch of checks I added to make sure the interface comes up at the expected time and on the expected IP, make it impossible to do it while the Kindle is plugged (in which case the hack ends up shouting an eips warning on the bottom of the screen after a dozen seconds, IIRC).

I'll correct the note about the firmware version not making a difference.
Otherwise - it is written in the order that a noob would probably stumble through on their own. I did.

twobob · 02-01-2013, 01:31 PM

Quote:

Originally Posted by NiLuJe

I'm assuming all of this came from trying to switch with a cable plugged in ^^ ?

FWIW, it does still work on 'older' devices (FW 2.x & 3.X), where the script doesn't rely on volumd, and does the switch itself. On newer devices, we *have* to go through volumd, and the bunch of checks I added to make sure the interface comes up at the expected time and on the expected IP, make it impossible to do it while the Kindle is plugged (in which case the hack ends up shouting an eips warning on the bottom of the screen after a dozen seconds, IIRC).

Quote:

Originally Posted by knc1

I'll correct the note about the firmware version not making a difference.
Otherwise - it is written in the order that a noob would probably stumble through on their own. I did.

The list of people who stumble on this - or other networking related issues - is innumerable. Thanks for outlining the specific technical differences.

Thanks for the walkthrough

knc1 · 02-01-2013, 01:34 PM

Quote:

Originally Posted by knc1

I'll correct the note about the firmware version not making a difference.
Otherwise - it is written in the order that a noob would probably stumble through on their own. I did.

PS: Open the spoiler - that is the "cheat sheet" version - which does not contradict the already published guides.

NiLuJe · 02-01-2013, 01:44 PM

That said, I'm still not *quite* certain who the exact culprit is in this instance...

I know it stems from the failure to load/unload the relevant kernel modules, as that, at least, is made pretty obvious by the kernel shouting at us, but the timing is a bit iffy, and the exact error varies wildly between devices, and, as ixtab said, the network interface *sometime* does finally come up, albeit on the default IP, so I kinda stopped looking for a definitive answer and just worked-around it by never toggling with a cable plugged in

.

DuckieTigger · 02-01-2013, 08:49 PM

Quote:

Originally Posted by knc1

Don't believe that title - that thread is also the home of the USBnetwork package, see:
https://www.mobileread.com/forums/att...4&d=1359259239

That link does not work. Direct links to (other peoples) attachments is not recommended, as they may change without you knowing about. Only linking to the post is somewhat safer.

knc1 · 02-01-2013, 09:19 PM

Quote:

Originally Posted by DuckieTigger

That link does not work. Direct links to (other peoples) attachments is not recommended, as they may change without you knowing about. Only linking to the post is somewhat safer.

Click link on prior line.

02-01-2013, 01:44 PM	#9
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	That said, I'm still not quite certain who the exact culprit is in this instance... I know it stems from the failure to load/unload the relevant kernel modules, as that, at least, is made pretty obvious by the kernel shouting at us, but the timing is a bit iffy, and the exact error varies wildly between devices, and, as ixtab said, the network interface sometime does finally come up, albeit on the default IP, so I kinda stopped looking for a definitive answer and just worked-around it by never toggling with a cable plugged in . Last edited by NiLuJe; 02-01-2013 at 01:46 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Help needed - USBNet/SSH	_Abahd_	Kindle Developer's Corner	1	08-06-2012 02:20 PM
Connecting to internet throug my computer with usbNet, KT	dogcalas	Kindle Developer's Corner	17	05-15-2012 03:06 PM
How to connect to kt with usbnet	Emrexcem	Kindle Developer's Corner	2	02-16-2012 02:02 PM
Kindle Touch - Trying to install Simple USBNet	chronosoft	Kindle Developer's Corner	15	02-11-2012 07:14 PM
Dreaming of usbnet	GregorRichards	iRex Developer's Corner	5	06-07-2011 05:14 AM

01-31-2013, 03:04 PM	#2
twobob ( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Týr Posts: 6,586 Karma: 6299991 Join Date: Jun 2012 Location: uti gratia usura (Yao ying da ying; Mo ying da yieng) Device: PW-WIFI\|K5-3G+WIFI\| K4\|K3-3G\|DXG\|K2\| Rooted Nook Touch	Excellent write up. I may nudge Niluje to link to it. Blinder

02-01-2013, 01:03 PM	#5
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	I'm assuming all of this came from trying to switch with a cable plugged in ^^ ? FWIW, it does still work on 'older' devices (FW 2.x & 3.X), where the script doesn't rely on volumd, and does the switch itself. On newer devices, we have to go through volumd, and the bunch of checks I added to make sure the interface comes up at the expected time and on the expected IP, make it impossible to do it while the Kindle is plugged (in which case the hack ends up shouting an eips warning on the bottom of the screen after a dozen seconds, IIRC).