Charles, thank you very much for your informative reply. I would never have discovered this on my own.
I think that your first hypothesis is correct - Chrome seems to run Android in its own virtual machine, with private IP addressing (100.115.92.*). This seems to be confirmed by the Chrome Connection Forwarder app, which reports the following addresses on my system:
100.115.92.2 (Android)
127.0.0.1 (Localhost)
192.168.1.6 (wlan0)
Apparently Chrome runs NAT for connections originating within Android, which permits connections out, but apparently not incoming connections, since that would require Chrome to act a router and advertise the private address space. Presumably one could add a NAT rule to redirect to the private address and I tried to use this app to do that, but it wouldn't work. Can't really work out why, because I don't really know what this app actually does.
Bottom line is that no matter how I played with the app, I couldn't get CC to find the Calibre WIFI server. It was able, however, to find and connect with Calibre running as a content server, presumably because this is a pull service, initiated by CC, rather than the WIFI connection, which is a push connection initiated by the Calibre server.
It seems to me that this (recent?) approach by Chrome to fully isolate Android and essentially treat it as a discrete app, rather than as a fully open OS could break lots of things, besides Calibre - e.g. any Android app which requires incoming connections, such as a synch service. If this is correct, I hope that the Chrome/Android folks will put in hooks for workarounds, like static routes and NAT.
Anyone have any information on this issue or any other insight into how to solve the WIFI connection problem? Right now, I'm starting to think that my experiment of using a Chromebook as an ebook reader may have been a mistake...
