Hi guys
I've a Dream when i start it up it goes into a locked screen that says “no sim card found i tried to register it with adb shell by typing this:
sqlite3 /data/data/com.android.providers.settings/databases/settings.db “INSERT INTO system (name, value) VALUES (’device_provisioned’, 1);”
i get error no database so i tried another command:
am start -a android.intent.action.MAIN -n com.android.settings/.Settings
it the same a get error type 3
i tried evrything: instazll usb drivers, changing computers, cabales typing all commands by the way when i typing adb shell i get this $ not #
anyone can help me
de_salim said:
Hi guys
I've a Dream when i start it up it goes into a locked screen that says “no sim card found i tried to register it with adb shell by typing this:
sqlite3 /data/data/com.android.providers.settings/databases/settings.db “INSERT INTO system (name, value) VALUES (’device_provisioned’, 1);”
i get error no database so i tried another command:
am start -a android.intent.action.MAIN -n com.android.settings/.Settings
it the same a get error type 3
i tried evrything: instazll usb drivers, changing computers, cabales typing all commands by the way when i typing adb shell i get this $ not #
anyone can help me
Click to expand...
Click to collapse
.... Do you have a sim card in? is it rooted?
I've searched the Forums but couldn't find anything interesting which could solve my problem. I've installed Ubuntu on my Device and now I'd like to get my WiFi working. I have made the wpa_supplicant.conf file and pasted it in /etc/wpa_supplicant.
Now when I run
sudo wpa_supplicant -i eth0 -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf
It says:
Could not read interface eth0 flags: No such device.
Also, when I try to connect to an open network, typing:
sudo ifconfig eth0 down
The result is the same.
So what does
"Could not read interface eth0 flags: No such device."
mean and how can I get into the internet?
Thank You, I hope You can help me
Mr.Ox said:
I've searched the Forums but couldn't find anything interesting which could solve my problem. I've installed Ubuntu on my Device and now I'd like to get my WiFi working. I have made the wpa_supplicant.conf file and pasted it in /etc/wpa_supplicant.
Now when I run
sudo wpa_supplicant -i eth0 -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf
It says:
Could not read interface eth0 flags: No such device.
Also, when I try to connect to an open network, typing:
sudo ifconfig eth0 down
The result is the same.
So what does
"Could not read interface eth0 flags: No such device."
mean and how can I get into the internet?
Thank You, I hope You can help me
Click to expand...
Click to collapse
maybe it's not 'eth0'.
type:
sudo ifconfig -a
to see all interfaces.
fserve said:
maybe it's not 'eth0'.
type:
sudo ifconfig -a
to see all interfaces.
Click to expand...
Click to collapse
Ok, I'm going to give it a try, thank You!
Now is the problem, that I have to open the WICD Manager, but I haven't got it installed... How do i get it now? Without internet?
Hi,
I'm having an issue with all terminal emulators (Android Terminal Emulator, ConnectBot, ...) after upgrading my Nexus 10 from Android 4.2.2 to 4.3.
The terminal is not recognizing the actual size of the screen and it is fixed to 80 columns and 20 rows. I can temporarily fix it typing "stty cols 180 rows 35", but those values depend on the screen rotation, font size, etc.
This is really weird, and I wasn't having this issue before the upgrade.
Anyone else has this problem or know how to solve it?
Thanks!
Ok, i've been doing some tests.
It seems to be a 'su' bug, it is not receiving the SIGWINCH signal.
If I type without su:
trap 'echo sigwinch' SIGWINCH
It is executed every time I rotate the tablet or popup the keyboard.
But, under su, the same command is not working.
It may be a permission issue.
Any ideas?
I can confirm having the same issue with my Nexus 10 and android 4.3. As soon as I run su - from the terminal (Android Terminal Emulator) the lines start wrapping at 80 characters.
Hi,
i've been working on this trying to find a solution.
Here is what I saw:
Every time I enter su or enter chroot (i have a chrooted debian), the tty number is changed to another one. That isn't the usual tty behavior!
So, if the normal user is in /dev/pts/0 , root could be in /dev/pts/1 and chroot in /dev/pts/2.
If I rotate the screen /dev/pts/0 cols and rows are changed even if I am as root, I can verify that by typing:
stty -F /dev/pts/0 -a
But, if I am at /dev/pts/1 i'm not receiving that SIGWINCH signal. In common linux distributions, that is not happening as pts number doesn't change.
Here is my (not so perfect) solution for the chrooted debian:
Write a fix_stty.sh script as root:
#!/bin/bash
sttypath=/bin
tty0=$(ls --sort time /dev/pts/ | head -n 1 | awk '{print $1}')
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols
Save it in /usr/local/bin
Make it executable:
chmod +rx /usr/local/bin/fix_stty.sh
Add to ~/.bashrc this line:
trap '/usr/local/bin/fix_stty.sh' DEBUG
Or if you use non-root users:
trap 'sudo /usr/local/bin/fix_stty.sh' DEBUG
And add to sudoers file:
%sudo ALL = (ALL) NOPASSWD: /usr/local/bin/fix_stty.sh
Logout and login again, and it will fix the rows and columns before each command.
----
For su, outside the chrooted linux write a script fix_stty.sh:
sttypath=/system/xbin
tty0=$(/system/xbin/busybox ls -t /dev/pts | head -n1)
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols
Save it to /system/xbin
(You should remount /system as rw: mount --remount -orw /system)
Then, make it exec:
chmod 755 /system/xbin/fix_stty.sh
And, finally you should type at each su login:
trap '/system/xbin/fin_stty.sh' SIGINT
(i don't know why DEBUG isn't here)
So you have to press Ctrl+C to fix it.
----
Alternatively, you can write an infinite loop or a simple daemon to fix it, but i don't like daemons on my tablet.
If anyone has a better solutions, please post it.
Hi all. I've been mulling over this problem as well. I believe the issue is because in 4.3, SuperSU now uses a "proxy", where commands are sent form the process which called su to daemonsu, which is launched at system startup. Chainfire explains a bit more in his G+ posts the reasons for doing this, but I think the key here is that root processes are now launched on a different tty, because they are launched by a different process (namely, daemonsu). Starting a root shell (whether system shell or ubuntu/debian chroot) now results in the creation of three pts devices, as opposed to the usual one. However, other shells not launched locally are fine. For example, starting the SSH server in my chroot and logging in via SSH is always fine.
I'm still trying to figure out a permanent solution to this problem. I still don't have a full understanding of the problem as I'm still trying to wrap my head around how Linux handles terminals and TTYs. I do have a few ideas floating around my head, though:
Change daemonsu and su to support full termios/line-discipline/whatever-we-need through the "pts bridge" that he is using
Create TTY(pts) pairs on demand, and have a modified Terminal Emulator connect to those directly when we want a shell
Have a background-ed process in the original terminal catch SIGWINCH and pass it to the root terminal
Still quite a bit a figure out though. I may just go through Terminal Emulator's source code to see how it work to get a better picture too. But that's gonna take time. I've also created a little native utility which creates two pts pseudo-TTYs and shuffles data between them. I'm still experimenting. Will post more as I learn more.
Just to let you all know that I've got a system working for myself: http://blog.tan-ce.com/android-root-shell/
The way I'm doing it uses a daemon, much like the su daemons ChainFire and Koush are using. The benefit of doing it this way is that I'm not confined by the application container, which is good for security when used by applications, but is annoying when you are using the terminal itself. I remember having to do hacks with adb servers to get around those.
But if you don't want a daemon, you can still set one up manually, just look at the last section of the README on how to use pts-wrap and pts-exec.
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.
I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
alf_tux said:
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.
Click to expand...
Click to collapse
My mistake, I forgot to create the symlinks for those two.
install-recovery-2.sh is an idea I took from CharinFire's SuperSU. Basically, it seems as if people are using install-recovery.sh to install startup scripts, and having the script try to call install-recovery-2.sh allows you to chain recovery scripts. For example, if you install this on a system with SuperSU, it will be installed as install-recovery-2.sh. If the system doesn't already have an install-recovery.sh, it'll install itself as install-recovery.sh.
Anyway, I've fixed and uploaded a new zip.
alf_tux said:
I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
Click to expand...
Click to collapse
Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
tan-ce said:
Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
Click to expand...
Click to collapse
Yes, here is my the terminal output:
[email protected]:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|[email protected]:/ $ su pts-shell /system/bin/sh
[email protected]:/ #
As you see, I can only run pts-shell as root.
alf_tux said:
Yes, here is my the terminal output:
[email protected]:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|[email protected]:/ $ su pts-shell /system/bin/sh
[email protected]:/ #
As you see, I can only run pts-shell as root.
Click to expand...
Click to collapse
Sorry, I realized that the correct command should be:
[email protected]:/ $ su -c pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
(pts-shell) Enter your password:
[email protected]:/ #
Anyway I can only run this as root.
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
tan-ce said:
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
Click to expand...
Click to collapse
I don't think that was the the bug:
[email protected]:/ $ su
[email protected]:/ # ls -l /data/pts
-rw------- root root 61 2013-08-28 19:09 passwd
srw-rw-rw- root root 2013-08-28 18:59 pts
[email protected]:/ # chmod 0701 /data/pts
[email protected]:/ # ls -l /data/pts
-rw------- root root 61 2013-08-28 19:09 passwd
srw-rw-rw- root root 2013-08-28 18:59 pts
[email protected]:/ # ^D
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Connection refused
255|[email protected]:/ $
I have also tried:
chmod 0701 /data/pts/pts
And
chmod 0701 /data/pts/*
I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
alf_tux said:
I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
Click to expand...
Click to collapse
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)
After that, perhaps you could try "chmod 0711 /data/pts"
There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".
Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.
On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
tan-ce said:
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)
After that, perhaps you could try "chmod 0711 /data/pts"
There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".
Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.
On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
Click to expand...
Click to collapse
Yes, I agree that fixing su would be better.
I don't have my tablet right know, i don't remember well /data /data/pts and /data/pts/pts read and exec bits. I will see better whan I have my tablet with me.
Here is the output:
/data:
drwxrwx--x system system 2013-08-28 18:59 data
/data/pts:
drwxr-xr-x root root 2013-08-28 19:06 pts
[email protected]:/ $ ls -la /data/pts
-rwxrwxrwx root root 61 2013-08-28 19:09 passwd
srwxrwxrwx root root 2013-08-28 18:59 pts
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Connection refused
255|[email protected]:/ $
I suppose it isn't a permission problem.
alf_tux said:
I suppose it isn't a permission problem.
Click to expand...
Click to collapse
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.
Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes.
tan-ce said:
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.
Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes.
Click to expand...
Click to collapse
T/hanks! I tried your new update and I think it's working!
Can you add a passwordless option? Or if password is blank just don't ask for it
alf_tux said:
T/hanks! I tried your new update and I think it's working!
Can you add a passwordless option? Or if password is blank just don't ask for it
Click to expand...
Click to collapse
Ok, but I took the easiest way out... If you set the environment variable PTS_AUTH, pts-shell will read the password from there instead of prompting you for it. So, if you're writing a script to spawn a root shell, do:
Code:
#!/system/bin/sh
export PTS_AUTH="your password here"
pts-shell /system/bin/sh
The latest update zip is here.
Thanks a lot tan-ce!!
It's working just as I expected!
Glad to hear it.
Finally found a way to get this usb 3g modem to work with android x86. Looks like there are significant differences in android kitkat, the other tutorials didn't work for me. Here's what i did in case somebody else finds it useful:
Model: Huawei E1752 HSPA USB Stick
Android x86 4.4.2 on Acer Netbook
Get modem to work under Ubuntu first so you have chat scripts that are known to work with your modem/provider. (If having trouble finding the right AT commands to initialize your modem you can record them under windows. Try free serial port monitor)
Install PPP Widget. It doesn't work, but that gives us usb_modeswitch and pppd to play with.
Install busybox if you don't have it already. Your device should be rooted.
I disabled modem's cdrom mode so that i wouldn't have to modeswitch it with PPP Widget every time (did it from linux)
http://ma.juii.net/blog/disable-usb-mode-switching
Tweak and install pppd/chat scripts for your provider:
/sdcard/pppwidget/ppp/free-chat
Chat script to initiate connection. Change AT commands and dial number (*99#) if yours differ.
Code:
ABORT BUSY
ABORT 'NO CARRIER'
ABORT 'NO ANSWER'
ABORT DELAYED
REPORT CONNECT
TIMEOUT 2
"" AT
OK-AT-OK AT&FE0V1X1&D2&C1S0=0
OK-AT-OK AT
OK-AT-OK ATS0=0
OK-AT-OK AT
OK-AT-OK AT&FE0V1X1&D2&C1S0=0
OK-AT-OK AT
OK ATDT*99#
TIMEOUT 30
CONNECT ''
SAY '\rReport from chat:\r'
/sdcard/pppwidget/ppp/peers/free
pppd config file
Code:
#/etc/ppp/peers/free
# Usage: root>pppd call free
ttyUSB0
3600000
crtscts
connect '/data/data/de.draisberghof.pppwidget/app_bin/chat -v -f /sdcard/pppwidget/ppp/free-chat'
noauth
defaultroute
usehostname
user fooooooo
noipdefault
usepeerdns
idle 0
/sdcard/3gmodem/connect
script to start connection
Code:
#!/system/bin/sh
pppd call free
# use own DNS (OpenDNS)
ndc resolver setifdns ppp0 208.67.222.222 208.67.222.220
ndc resolver setdefaultif ppp0
To connect, open a terminal and type:
Code:
$ su
# cd /sdcard/3gmodem
# ./connect
Now you're connected. browser should work now.
Connection is there but android doesn't know about it, so apps like play store which check connectivity will think you're offline. Install Fake Wifi Connection to deal with those.
Done !
how to get chat script for other modem
Hello, Can I use your chat script with Huawei E3531, and replace only the AT commands?
Do I need busybox?
I have no knowledge of commands, just very basic commands on android terminal.
I am having a really hard time to connect to internet, mainly because Broadcom BCM43142 wifi is not compatible with android 9.0-r2, and older versions.
Thank you
I decided to try some inter-device adb action today. I'm sure some people have tried this, but I thought it was interesting. So I began by connecting from my laptop to my Nexus 4. I set up the Nexus 4 to do adb wireless with:
Code:
setprop service.adb.tcp.port 5555
adbd &
On my laptop I connected to the Nexus 4 with:
Code:
adb connect 192.168.0.7 (Nexus 4's host)transfer files over telnet
adb shell
su
Then I set up my G4 to do adb wireless the same way. In the adb shell into my Nexus 4, I connected to my G4 with:
Code:
adb connect 192.168.0.11 (G4's host)
adb shell
su
I tested some file transfers betwen phones with "adb push" and "adb pull" which worked really well. I'll definitely be using adb in the future to transfer files from one phone to the other. ftp works well, but this is even easier.
I decided to take my adb connection even further. My adb shell is now from laptop -> Nexus 4 -> G4 now. I then connected back to the Nexus 4 with:
Code:
adb connect 192.168.0.7
adb shell
su
When adb connects to a device it connects to the abdb daemon, and multiple connections can be made. Now that I'm back in the Nexus 4, I could reconnect to the G4, but that would be pointless since I already connected from the Nexus 4 to the G4. I wanted to try some other things. In the Nexus 4, I dropped down into a chrooted ubuntu image. I retrieved adb like you do on a computer with ubuntu:
Code:
apt-get install android-tools-adb
In the ubuntu chroot on the Nexus 4, I connected back to the G4. I'm now running laptop -> Nexus 4 -> G4 -> (Nexus 4 -> ubuntu chroot) -> G4. At this point the connection was showing some lag. In the G4, I dropped down to a chrooted ubuntu image I have on that phone. I connected back to the Nexus 4. Dropped down into a chrooted Debian image I also have on that phone. At that point, I was able to connect back to the G4, but the device showed up as "offline", so I exited the chroot. In the Android environment, I found out I was still able to connect back and forth between phones, launching new adb processes each time. I ended up with an adb shell connection like this: laptop -> Nexus 4 -> G4 -> (Nexus 4 -> ubuntu chroot) -> (G4 -> ubuntu chroot) -> (Nexus 4 -> G4 ->)x20. You can see the processes for the connections with:
Code:
pgrep -fl adb
# You get something like:
>339 adb -s 192.168.0.7:5555 shell
>2869 adb -s 192.168.0.7:5555 shell
>4049 adb -s 192.168.0.7:5555 shell
>4933 adb -s 192.168.0.7:5555 shell
>5085 adb -s 192.168.0.7:5555 shell
>5772 adb -s 192.168.0.7:5555 shell
>5879 adb -s 192.168.0.7:5555 shell
>6027 adb -s 192.168.0.7:5555 shell
>6135 adb -s 192.168.0.7:5555 shell
>6236 adb -s 192.168.0.7:5555 shell
>6334 adb -s 192.168.0.7:5555 shell
>6447 adb -s 192.168.0.7:5555 shell
>6548 adb -s 192.168.0.7:5555 shell
>31220 /sbin/adbd --root_seclabel=u:r:su:s0
>31669 adb -P 5037 fork-server server
>31684 adb -P 5038 fork-server server
In the Android environment (not the chroot), I connected from phone to phone about 20 times until I got bored and the connection got too laggy. Unfortunately, the adbd daemon you can download in ubuntu gives a segmentation fault when you run it in Linux, so no connection between ubuntu's. Telnet and ssh work though. I was able to ssh back into my laptop with my ridiculous, laggy adb cascade and then adb back into the phones once again. Depending on which device you're currently in, you can kill the whole chain with:
Code:
pkill adbd
This was all kind of ridiculous, but the adb between phones is useful, so I guess I got something out of it.
This is pretty cool. Thanks for that.
Off topic, but if you do transfer files between phones a lot or if you enjoy streaming media from one phone to another, one solution I use is the Sambadroid app. Just hotspot one phone, connect to the wifi on the other, and use a file explorer app such as ES to map a network share.