My main computer is running Ubuntu 18,04, I just bought my BBG for about 1 week. More information about my BBG :
root@beaglebone:~# uname -a
Linux beaglebone 3.8.13-bone71.1 #162 SMP Fri Oct 16 07:27:34 CST 2015 armv7l GNU/Linux
It worked well until yesterday, I don’t know why I cannot access to 192.168.7.2 When I try to access, it just displays «This site is inaccessible, 192.168.7.2 does not allow connection ». When I run ifconfig, I can see:
root@beaglebone:~# ifconfig
eth0 Link encap:Ethernet HWaddr 68:c9:0b:de:86:90
inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fd9c:b2b2:b823:e100:6ac9:bff:fede:8690/64 Scope:Global
inet6 addr: fe80::6ac9:bff:fede:8690/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:808 errors:0 dropped:0 overruns:0 frame:0
TX packets:181 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:89566 (87.4 KiB) TX bytes:22850 (22.3 KiB)
Interrupt:40
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/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:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
usb0 Link encap:Ethernet HWaddr 76:c8:bf:7b:58:36
inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252
inet6 addr: fe80::74c8:bfff:fe7b:5836/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2143 errors:0 dropped:0 overruns:0 frame:0
TX packets:1418 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:170470 (166.4 KiB) TX bytes:237376 (231.8 KiB)
In addition, I could not access 192.168.7.2:3000 which is cloud9 IDE, but when I try to find his folder, I see:
root@beaglebone:~# cd /var/lib/cloud9
root@beaglebone:/var/lib/cloud9# ls
LICENSE _includes examples node-v8.11.2.tar.gz
Projects _layouts favicon.ico node_latest_armhf.deb
README.md autorun index.html node_modules
Support bone101 node-v0.10.5.tar.gz static
_config.yml config node-v8.11.2-linux-armv7l
root@beaglebone:/var/lib/cloud9# cd bone101
root@beaglebone:/var/lib/cloud9/bone101# ls
LICENSE config node-v0.10.5.tar.gz node_latest_armhf.deb
Projects examples node-v8.11.2-linux-armv7l node_modules
README.md favicon.ico node-v8.11.2-linux-armv7l.tar.xz static
Support index.html node-v8.11.2.tar.gz
Note: I have the same problem with windows.
What would you recommend me to do?
How can I fix this issue?
Thanks in advance !
[-- multipart/alternative, encoding 7bit, 1863 lines --]
[-- text/plain, encoding quoted-printable, charset: UTF-8, 90 lines --]
My main computer is running *Ubuntu 18,04*, I just bought my *BBG* for
about 1 week. More information about my BBG :
root@beaglebone:~# uname -aLinux beaglebone 3.8.13-bone71.1 #162 SMP Fri
Oct 16 07:27:34 CST 2015 armv7l GNU/Linux
It worked well until yesterday, I don't know why I cannot access to
192.168.7.2 When I try to access, it just displays *«This site is
inaccessible, 192.168.7.2 does not allow connection »*. When I run
*ifconfig*, I can see:
So which way are you trying to connect? Are you running ssh on your
desktop and trying to connect to the BBB? I think you may have things
the wrong way round.
root@beaglebone:~# ifconfig
[snip]
usb0 Link encap:Ethernet HWaddr 76:c8:bf:7b:58:36
inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252
inet6 addr: fe80::74c8:bfff:fe7b:5836/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2143 errors:0 dropped:0 overruns:0 frame:0
TX packets:1418 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:170470 (166.4 KiB) TX bytes:237376 (231.8 KiB)
This is telling you that your *desktop* machine is 192.168.7.2, I
think the BBB will be 192.168.7.1.
But this is the same problem. I cannot access to this address :
On Fri, 25 May 2018 04:56:14 -0700 (PDT), Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:
My main computer is running *Ubuntu 18,04*, I just bought my *BBG* for
about 1 week. More information about my BBG :
root@beaglebone:~# uname -aLinux beaglebone 3.8.13-bone71.1 #162 SMP Fri Oct 16 07:27:34 CST 2015 armv7l GNU/Linux
1) you appear to be logging into the BBG using a "root" login... Most
images for the last few years disable direct "root" login. That also looks
like an ancient OS image (2015? I think the last Wheezy image was 2016, and
the current state-of-the-art isn't even Jessie, but has moved on to
Stretch)
It worked well until yesterday, I don't know why I cannot access to
192.168.7.2 When I try to access, it just displays *«This site is
inaccessible, 192.168.7.2 does not allow connection »*. When I run
*ifconfig*, I can see:
Is the USB cable still connected? 192.168.7.2 is only valid for a USB
gadget connection.
root@beaglebone:~# ifconfig
So how are you connecting to the BBG? I'm presuming via Ethernet
router...
eth0 Link encap:Ethernet HWaddr 68:c9:0b:de:86:90
inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0
... to IP 192.168.1.101
inet6 addr: fd9c:b2b2:b823:e100:6ac9:bff:fede:8690/64 Scope:Global
inet6 addr: fe80::6ac9:bff:fede:8690/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:808 errors:0 dropped:0 overruns:0 frame:0
TX packets:181 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:89566 (87.4 KiB) TX bytes:22850 (22.3 KiB)
Interrupt:40
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/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:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
usb0 Link encap:Ethernet HWaddr 76:c8:bf:7b:58:36
inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252
inet6 addr: fe80::74c8:bfff:fe7b:5836/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2143 errors:0 dropped:0 overruns:0 frame:0
TX packets:1418 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:170470 (166.4 KiB) TX bytes:237376 (231.8 KiB)
What would you recommend me to do?
Use the Ethernet IP address in place of the USB address?
Hello Wulfraed,
I try to use the Ethernet IP address, but it still the same problem.
On Fri, 25 May 2018 22:12:26 +0100, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:
Hello Wulfraed,
I try to use the Ethernet IP address, but it still the same problem.
Then... How did you connect to show the result of ifconfig in your
original post? I'm fairly sure you didn't hand-type the result while
looking at second monitor (connected to HDMI, which the BBG does not have
<G>) while using a USB keyboard/mouse on the BBG.
You still haven't confirmed if the USB cable is valid -- and the
192.168.7.x addresses are only usable if the you have a valid USB cable
detected by the host.
I type the command with ssh: ssh root@192.168.7.2
The cable is detected since I can see the content of the Beaglebone.
On Fri, 25 May 2018 23:44:09 +0100, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:
I type the command with ssh: ssh root@192.168.7.2
Unfortunately, gmane garbages things that look like email addresses
when they occur in a post. Try splitting that up into multiple lines the
punctuation, so it might not be seen by gmane as something to obscure.
The cable is detected since I can see the content of the Beaglebone.
If you are using a configuration of SSH with a login key (or whatever
SSH uses to bypass plain login prompts) on the destination, that might be
related (and since you seem to be using the root account, I have to suspect
this is the case). For some time now direct login to root has been disabled
on Beaglebones -- one has to log in as a regular user (the default account
is "debian", with password "temppwd") and use "sudo" to perform root level
operations.
Only things left that I could try would be ping and traceroute/tracert
to the USB and Ethernet addresses...
Or better yet, don't use gmane… I can see right here that he's telling
SSH to connect to 192.167.7.2 as root.
Perhaps try running `netstat -anlpt` and see if a daemon is listening on
port 3000?
On Sat, 26 May 2018 10:14:02 +1000, Stuart Longland
<stuartl@longlandclan.id.au> declaimed the
following:
Or better yet, don't use gmane… I can see right here that he's telling
SSH to connect to 192.167.7.2 as root.
Is that a typo? 167 -> 168
If the OP is connecting as "root", they are either running a very old
OS from an era when root had a published password, or they have given root
a password -- or, they have configured SSH with some sort of certificate to
bypass password checking.. So far as I recall, all OS images in the last
two years (give or take) have been configured without a root password.
Hypothesis: So it could easily be that connection via other means is
running into security constraints (user does not match certificate, no
certificate provided for authorization). I'm not up on the multitude of
authorization systems supported by SSH (I've only used it for BBB and RPi,
and only now looked far enough into PuTTY configuration to find I can have
it automatically provide a username, to which I still have to provide a
password).
As for gmane -- I find NNTP much more efficient in separating messages
by forum, filtering, and overall handling. I really wish the two mailing
lists (one genealogy, and one effectively dead investing list) I'm on had
an NNTP interface.
Is that a typo? 167 -> 168
Ahh yes, on my part… laptop keyboard, 7 and 8 are beside eachother.
If the OP is connecting as "root", they are either running a very old
OS from an era when root had a published password, or they have given root
a password -- or, they have configured SSH with some sort of certificate to
bypass password checking.. So far as I recall, all OS images in the last
two years (give or take) have been configured without a root password.
It's doable… if you've installed your SSH public key as
`/root/.ssh/authorized_keys`, you can log in directly as `root`.
Authentication is done by your client proving to the server it has the
corresponding private key (which should be encrypted with a strong
passphrase).
Not saying that's what the OP did, but it's what I do on my systems, as
generally if I'm intending to log into systems to do admin work, I
generally want to do so without dealing with a middle-man (e.g. su,
sudo, doas on OpenBSD).
Hello Stuart, Dennis,
When I type the netstat -anlpt command with ssh debian@192.168.7.2, I get:
and when I type the netstat -anlpt command with ssh root@192.168.7.2 I get:
On Sat, 26 May 2018 13:36:10 +0100, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:
Hello Stuart, Dennis,
When I type the `netstat -anlpt` command with ssh debian@192.168.7.2, I
get:
Please -- in the future just cut&paste the TEXT from the console... NOT
as screen image. Besides bloating the post to over 1600 "lines" of MIME
content, the displayed resolution is so low it is practically illegible
(each image is about 42kB, to relay just over 1kB of text). I finally had
to dig up the procedure to save the embedded images and open them in a
different program in order to clearly read the content.
Example (yes, it did wrap in the post, but it is much easier to read
than even a full-size fuzzy screen grab)... Oh, and it shows I have a
session via USB /and/ one via Ethernet, and started a cloud9 connection):
debian@beaglebone:~$ sudo netstat -anlpt
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN
989/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
860/sshd
tcp 0 0 192.168.2.105:22 192.168.2.109:56785 ESTABLISHED
1319/sshd: debian [
tcp 0 0 192.168.7.2:22 192.168.7.1:56752 ESTABLISHED
1082/sshd: debian [
tcp6 0 0 :::53 :::* LISTEN
989/dnsmasq
tcp6 0 0 :::22 :::* LISTEN
860/sshd
tcp6 0 0 :::1880 :::* LISTEN
1/init
tcp6 0 0 :::3000 :::* LISTEN
1/init
tcp6 0 0 :::80 :::* LISTEN
1/init
tcp6 0 0 :::8080 :::* LISTEN
898/apache2
tcp6 0 0 192.168.7.2:3000 192.168.7.1:57186 ESTABLISHED
3878/nodejs
tcp6 0 0 192.168.7.2:3000 192.168.7.1:57172 ESTABLISHED
3878/nodejs
tcp6 0 0 192.168.7.2:3000 192.168.7.1:57221 ESTABLISHED
3878/nodejs
tcp6 0 0 192.168.7.2:3000 192.168.7.1:57234 ESTABLISHED
3878/nodejs
tcp6 0 0 192.168.7.2:3000 192.168.7.1:57222 ESTABLISHED
3878/nodejs
The only thing significantly different is that you appear to have some
variation of xrdp running; whereas I seem to have dnsmasq active.
Obviously you CAN connect to the device, via SSH ON 192.168.7.2. How
you have SSH configured on the Beaglebone I do not know -- since all of
mine have root login disabled by default, and I don't know enough SSH
config to set up any sort of bypass, short of given root a regular
password.
My hypothesis: you have configured SSH to authorize root using some
known key. Said key is not used when you try other connections as root, so
they fail due to lack of a password.
Hello Wulfraed,
Thank you for your answer and for your advice, but sincerely I do not know how it was done, I tried all the solutions.
Is it when I update the Debian Image it could be resolved ?
Note: I am a beginner in this field.
On Sat, 26 May 2018 17:09:10 +0100, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:
Thank you for your answer and for your advice, but sincerely I do not know
how it was done, I tried all the solutions.
Is it when I update the Debian Image it could be resolved ?
Before running an eMMC flasher, I would recommend using a non-flasher
image ON THE SD card, and verify that everything is working when you boot
with the SD card. That includes configuring the home directory of the user
(I have a set of favorite aliases that I keep copying from one card to
another)
Only after you are happy should you convert the card to a flasher (see
instructions at Latest Software Images - BeagleBoard ), reboot, and let it
flash the eMMC (warning -- using USB power may not be enough; use a decent
5V power supply in the barrel connector before trying to flash the eMMC).
After it has flashed, remove the SD card, reboot, insert the SD card, mount
it, and re-edit /its/ copy of that file so it is no longer a flasher. That
gives you an SD card you can use as a boot image.
*Note: *I am a beginner in this field.
As such, my first bit of advice would be: NEVER log in as root (note
that new images don't even allow that without you first doing some
configuration changes).
Instead, log in with the regular debian name, and when you encounter a
command that needs elevated privileges, use the sudo command to run it.
https://wiki.debian.org/sudo
Being logged in as root means almost anything you did might have
changed a configuration setting... Firewall, other security, anything...
Hello,
It seems to solve this problem, we must update this card because when I boot with an SD card and with the latest version, it works well.
On Mon, 28 May 2018 17:08:15 +0100, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:
Hello,
It seems to solve this problem, we must update this card because when I
boot with an SD card and with the latest version, it works well.
If you are happy with how the SD card version is working, the next step
would be to convert the SD card into a flasher, and let it update the eMMC.
But, I do not know how to install it.
On Mon, 28 May 2018 17:52:42 +0100, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:
But, I do not know how to install it.
My previous post gave you the link to the instructions...
"""
To turn these images into eMMC flasher images, edit the /boot/uEnv.txt file
on the Linux partition on the microSD card and remove the '#' on the line
with 'cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh'.
Enabling this will cause booting the microSD card to flash the eMMC. Images
are no longer provided here for this to avoid people accidentally
overwriting their eMMC flash.
"""
So -- boot using the SD card
Edit the specified file.
Make sure you have a good 5V power supply connected as the USB power
may not be reliable for this step
Reboot -- it should see the command to flash the eMMC. If it works you
will get a "Larsen scanner" (cylon) pattern on the blue LEDs. Let it run
until it stops (may take up to 10 minutes or more, though I think mine run
in a bit less). When it stops (and powers off), remove the SD card (you
can't boot off it until you change the file again -- otherwise it will just
restart the flashing process).
With the SD card removed, restart the unit. It should now boot into the
eMMC with the new OS image installed.
Hello,
Thank you very much, it works well.
Best Reagrds.