Beta testing RxOS release 4.0 - Skylark. Link in thread!

OK - - yes now my.outernet.is works.

But as to the Java error, I tried to replicate it by going back to the SAVE AND REBOOT in the Network tab (which is where and when I saw it) - - but the Lantern became inert after I did the SAVE AND REBOOT (no Hotspot and not connected to my WiFi). Turning on and off - - unpluging – etc. did not work.

I had to reflash the CHIP to restore service. Then I went back thru the same set up routine: Opening the OUTERNET Hotspot, going to the Network Tab, setting up and selecting my local WiFi, getting the same Java error message, and then seeing the Lantern connected fine to my network. Ken

So I looked at this a bit more and realised I could connect via USB/ Ethernet even when it’s unreachable wirelessly.

This is what I found. Is there any other information that would be useful?

[rxOS][outernet@skylark:~]$ ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1%3068304476/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

usb0 Link encap:Ethernet HWaddr A6:58:46:9A:B7:1A
inet addr:10.10.10.10 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::a458:46ff:fe9a:b71a%3068304476/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:177 errors:0 dropped:0 overruns:0 frame:0
TX packets:72 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:21592 (21.0 KiB) TX bytes:8999 (8.7 KiB)

syslog
11.740000] using random self ethernet address
[ 11.745000] using random host ethernet address
[ 11.775000] usb0: HOST MAC f6:53:75:6f:7f:f0
[ 11.780000] usb0: MAC 16:e6:7a:fd:b4:5f
[ 11.785000] g_cdc gadget: CDC Composite Gadget, version: King Kamehameha Day 2008
[ 11.790000] g_cdc gadget: g_cdc ready
[ 12.190000] g_cdc gadget: high-speed config #1: CDC Composite (ECM + ACM)
[ 12.760000] udevd[236]: starting version 3.1.5
[ 14.495000] RTL8723BS: module init start
[ 14.495000] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40
[ 14.505000] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40
[ 14.655000] RTL8723BS: rtw_ndev_init(wlan0)
[ 14.665000] RTL8723BS: module init ret =0
[ 15.570000] cfg80211: World regulatory domain updated:
[ 15.575000] cfg80211: DFS Master region: unset
[ 15.580000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 15.590000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 15.595000] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz, 92000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 15.605000] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 15.615000] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 15.625000] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 15.635000] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 15.640000] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 15.650000] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 16.035000] rtl8723bs: accquire FW from file:rtlwifi/rtl8723bs_nic.bin
[ 17.385000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

interfaces
lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1
link/sit 0.0.0.0 brd 0.0.0.0
3: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 16:e6:7a:fd:b4:5f brd ff:ff:ff:ff:ff:ff
inet 10.10.10.10/24 brd 10.10.10.255 scope global usb0
valid_lft forever preferred_lft forever
inet6 fe80::14e6:7aff:fefd:b45f/64 scope link
valid_lft forever preferred_lft forever
4: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 7c:c7:09:e0:5d:91 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global wlan0
valid_lft forever preferred_lft forever

network routes
10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.1 linkdown
10.10.10.0/24 dev usb0 proto kernel scope link src 10.10.10.10

I managed to get some time this evening to look at this. I have the VM running but it does not detect the CHIP.

I have also noted that my CHIP is not like the ones in the pictures. Further investigation has revealed mine (the one supplied by Outernet) to be a V0.21. I am also not detecting it via lsusb either.

When not plugged in to the PC it is usable as an Outernet receiver.

I’m running Ubuntu 16.04.1 LTS with the MATE desktop interface.

Whilst it looks the same to me, this is the V0.21 pinout I got from the CHIP GitHub site …

You’re connecting a wire between 7/39?

Installing was very easy and the new version looks great.

Is it correct that there is no “out of the box” mp3 support anymore, or do I need to register that as a bug??

Yep.

Also did 1 and 7 too.

Outernet Status Reporting Bug

First observations of Skylark performance are excellent. :grinning: Alpha Lantern ran overnight rather than hang up in the morning as it always has under the rxOS 3.1 software. Lantern is receiving SNRs of 4 to 8 here and I’m always showing green on my bubble over Washington for SNR

but I am consistently reporting no Frame Lock even thou I have frame lock and am receiving files.

Ken

Worked it out. It would seem that the VM does not have rights to the dialout group - duh! Running the VM manager as root solved that issue.

As for the not showing up in lsusb, It was the USB cable. I went through 4 of them before it finally kicked into life. It’s programming now. Stay tuned.

1 Like

Weird! I also had to try two cables before the programming worked!!

I’m still not convinced that it has “worked”. I waited until the light was flashing before removing the CHIP from the cable and returning it to service. It does not appear to boot. I flashed it again and waited until the blinking light stopped flashing and went solid - again it doesn’t seem to boot.

I get a very quick blink when I apply power but that’s all. It does however, boot to FEL when I force it.

Grrrr

thats the “no auto boot” thing.

To make it boot, you will need to press the power button.

Did that. No joy.

Oh. And of course it does it now!!! Hold it for a 5 count seems to work.

1 Like

Yes, the “no frame lock” on the status page is a (server-side) bug. 3.1 (Librarian) and 4.0 (Skylark) send that data slightly differently. I have not yet gotten around to coding up the handling of that difference, server side.

Please add that as a “feature request”. Yes, right now there is no media viewer. Its coming though.

What are the u/p credentials? All I have is a password box

To folks who find their CHIP unresponsive after switching to Wifi Client mode:

The thing is, when you click “save and reboot” in the network app, that triggers a reboot (and yes, an alert would be nice, its coming - I am just one guy :D)

With the no-auto-boot - this reboot won’t happen unless you press the power button (and remember to remove the FEL header).

So from a users perspective, what looks like a “frozen” CHIP, is simply a CHIP that went into a reboot without visual warning, and then didn’t boot again due to no-auto-boot.

If you think your situation is different that this, I request you to file a bug.

Outernet/Outernet.

Right now there is no provision to change the password in the GUI.

On the flip side, now, any password changes via SSH reflect in the GUI. GUI password management is also Coming Real Soon Now™.

Well, I had to flash it twice before it worked anyway!