CC stuck with incorrect device address

[pugsley1]

Hi Folks,

I've run into an odd problem with CC running on my HP x360 Convertible 2-in-1 Chromebook. The chromebook is getting its IP address from DHCP over WiFi - currently 192.168.1.6 - as usual. But when I check with the settings on CC for WiFi connection, it reports "This device's IP address is 100.115.92.10".

No idea where this came from, and needless to say, I can't connect with my Calibre server (192.168.1.3). I've both restarted CC and the chromebook, and disconnected and reconnected from WiFi, multiple times, but CC keeps reporting this strange device address.

Any assistance on this issue would be much appreciated. I'm at my wit's end.

Thanks!

[chaley]

CC reports the IP address that Android gives it. I see 3 possibilities for why Android is doing that.

• Because you running Android over Chrome, you are probably seeing the issue described here. One possible fix is to manually enter the server's IP address into CC (I have doubts that this will work). Another is the one discussed in this post.
• The address 100.115.92.10 is a private IP address assigned to the Shared Address Space. This private space is used by carriers to avoid collisions with the more common private addresses (10., 172.16, and 192.168). The fact that CC is seeing this address implies that:
  • You are connecting using a VPN (virtual private network)
  • You are connecting via a roaming scheme provided by your ISP that allows you to use other peoples' WiFi.
  • WiFi isn't connected at all and you are seeing the cell system IP address.
• Another possibility is that you set up a fixed IP address sometime in the past.

[pugsley1]

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...

[chaley]

If the Chromebook is doing NAT for the Android VM then it is acting like a router. That is the way NAT works -- routing address:port to internal-address:internal-port.

Both the content server and wireless device connections are initiated by the client. If one works then the other should too unless the Chromebook is recognizing HTTP and handling it differently, which I doubt.

In a NAT situation there is no hope that CC will be able to auto-find the calibre server. Auto-connect uses broadcast UDP and MDNS. The NAT router (the Chromebook) will not propogate these packets. However, entering the calibre server IP address and port into the Wireless Device parameters should work if the content server connection works.

Things to check:

• Is the wireless driver in calibre actually started?
• Are you using a reserved port for the wireless device (<1024)?
• Has your antivirus changed and is now blocking the connection?
• Do you see any evidence of a "SmartDevice" connection in a calibre debug log?
• On the device, connect to the wireless device using a web browser, something like 192.168.1.6:9090 where "9090" is replaced by the port you use. You should see "invalid response", and there should be a lot of chatter in the calibre debug log. If you don't see this but connecting to content server manually (something like 192.168.1.6:8080) does work then something on the calibre machine is blocking wireless device connections.

[crane3]

Could the problem is HP's implementation?

I have a Dell-Inspiron chrombook 14 & "just" did a connect to Calibre from another room; no problem. Had CC retrieve the unlisted ebooks as never did much after the initial install because of the lack of "install from unknown sources" in stable mode; did read somewhere Chrome OS will have that in ver 80 & so 'next month'(?) will try to install Tachiyomi as my manga reader.

I was running in stable mode of Chrome OS 78 & upgraded to OS 79 after CC updated the book listing. The Dell did the connect to Calibre normally like my tablets. I do have a separate router connected to the gateway modem & the lan is based on the router, wired & WiFi. Also my Chromebook is using the 5ghz mode network.

Did not see any mention of what OP's version of Chrome OS.

[chaley]

Originally Posted by crane3

Could the problem is HP's implementation?

It could be. Who knows what HP did, if anything. However, I suspect the A/V on the calibre machine, assuming that the content server connection from CC does work.