Hello, in other forum, " dervari " resolved the tethering A101 with BlackBerry:
in /system/etc/ppp/peers/tether, change novj for #novj
in /system/bin/tether_start_dun.sh., change if [$# -eq 4 ] for if [ $# -eq 4 ]
but that was with firmware 2.3.26... now, the new firmware 2.3.81 changed these scripts..
my questions:
.- This changes makes tethering A101 with BlackBerry ?
.- Not necesary makes more changes in scripts ?
new /system/etc/ppp/peers/tether in 2.3.81:
#debug
# connection
crtscts
hide-password
nodetach
# peer parameters
noauth
# most gprs phones don't reply to lcp echo
lcp-echo-interval 0
lcp-echo-failure 0
# dns, routing
ipcp-accept-remote
ipcp-accept-local
defaultroute
#replacedefaultroute # not currently supported by our pppd
noipdefault
usepeerdns
# avoid compression
# novj is now an option
novjccomp
noccp
nobsdcomp
nopcomp
noaccomp
# connect scripts
connect '/system/xbin/chat -v -t3 -f /data/tether_start'
disconnect '/system/xbin/chat -v -t3 -f /etc/chatscripts/tether_stop'
new /system/bin/tether_start_dun.sh in 2.3.81:
#!/bin/sh
# $1 is the mac address of the phone
# $2 is the channel
# $3 is the user (not a mandatory argument)
# $4 is the password (not a mandatory argument)
# $5 is the novj option
MAC=$1
CHANNEL=$2
USER=$3
PWD=$4
NOVJ=$5
if [ "$USER" = "" ]
then
/system/xbin/dund --connect $MAC --channel $CHANNEL --pppd /system/bin/pppd /dev/rfcomm0 115200 mru 1280 mtu 1280 $NOVJ call tether
else
/system/xbin/dund --connect $MAC --channel $CHANNEL --pppd /system/bin/pppd /dev/rfcomm0 115200 mru 1280 mtu 1280 $NOVJ name $USER password $PWD call tether
fi
model number yp-G70CB
firmware 2.3.5
kernel version 2.6.35.7-G70XWKP2-CL580645
[email protected] #2
after 10h testing and reading manuals....
i present you openvpn startup script:
(requiements : root, busybox v1.19.3-stericson, optional Script Manager ads)
VPN.sh
------------------------------------------------------------
su -c "PATH=/system/xbin:$PATH" - # path for ifconfig
su -c "mkdir /dev/net" - # fixing tunctl problems
su -c "ln -s /dev/tun /dev/net/tun" - # linking tunctl for new location
su -c "tunctl" - # create tap0 device
su -c "ifconfig tap0 192.168.1.222" - # set manual IP for tap0 device
su -c "openvpn /sdcard/openvpn/config/FlamcoNet.ovpn" - # openvpn config
------------------------------------------------------------
only problem is DHCP
for unkown reason openvpn does not assing IP address to tap0
if someone know anythink about this please write me on this post
enjoy OpenVpn on you samsung
Thanks for this.
What problems with the lack of DHCP cause?
if you dont set manual IP for tap0 device
then tap0 device doesnt have ip address
it looks like that DHCP doesn't assing ip for it
but i have many computers on VPN and on everyone is working correctly
if you like i can post you logs from tab and vpn server / client
Probably failing due to lack of tunnelling support in the kernel - it's rare for a stock kernel to support it.
Entropy512 said:
Probably failing due to lack of tunnelling support in the kernel - it's rare for a stock kernel to support it.
Click to expand...
Click to collapse
Looking at the defconfigs, it seems that tunneling support is enabled in stock kernel.
rumirand said:
Looking at the defconfigs, it seems that tunneling support is enabled in stock kernel.
Click to expand...
Click to collapse
It isn't in venturi_usa_defconfig...
I currently run Paranoid Android on my SG5, which works well enough for my tastes. One thing I've wanted to play with is reverse tethering. Since I charge my player via the computer's usb connection, I figured it'd make sense to disable wifi and save a little power to speed up the slow usb charging and just use the pc's internet connection via usb. I also have a few apps like calibre and the compantion app which don't work correctly when I'm on a wifi connection that's been firewalled to prevent devices from communicating with each other. This bypasses the wifi connection and gives me a nice secure connection between devices.
I got it working ... mostly. I don't expect many people to find this useful, but I thought it might be an entertaining hack to poke at.
The following script sits on my linux netbooks' ~/bin directory as reverse-tether.sh
Code:
#!/bin/sh
# We need root on the host to mess with networking
if [[ $(whoami) != "root" ]]; then
echo "You must be root to run this script!"
exit 1
fi;
# We need root on the Player to mess with networking
echo 'Enabling adb root access...'
adb -d root
# Turn on usb networking
echo 'Enabling usb network interface on the Galaxy Player...'
adb -d shell 'sh /storage/sdcard0/reverse_tether.sh up &'
# adb disconnects, so we wait for the network on the player to settle before continuing on.
sleep 2
# Rename device interface as ArchLinux has annoying device names (becomes player)
IF=`ifconfig -a | grep "enp" | cut -d ':' -f 1`
ip link set dev $IF down
/usr/sbin/ifrename -i $IF -n player
ip link set dev player up
echo 'Setting Computer IP Address ...'
ifconfig player 192.168.200.1 netmask 255.255.255.0
ifconfig player up
echo 'Enabling NAT and IP Forwarding on Computer...'
# Start forwarding and nat (use existing default gw)
iptables -F -t nat
iptables -A POSTROUTING -t nat -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 'Starting dnsmasq on Computer...'
dnsmasq --interface=player --no-dhcp-interface=player
echo
echo 'Connection is ready! Press any key to shutdown.'
echo
read
echo 'Shutting down reverse tethering'
# SSH server is always running on player, with public rsa key imported for passwordless logins
# This hackery is required as adb seems to be disabled with rndis active.
# I use dropbear server II, but any of the ssh servers would probably work.
ssh [email protected] 'sh /storage/sdcard0/reverse_tether.sh down &'
killall dnsmasq
ifconfig player down
iptables -F -t nat
echo 0 > /proc/sys/net/ipv4/ip_forward
And the following script is simply stashed on the sdcard of the player. as /storage/sdcard0/reverse_tether.sh
Code:
#!/system/bin/sh
if [ "$1" = "up" ]; then
echo 1 > /sys/class/usb_composite/rndis/enable
ip addr add 192.168.200.2/24 dev usb0
ip link set usb0 up
ip route delete default
ip route add default via 192.168.200.1
setprop net.dns1 192.168.200.1
fi
if [ "$1" = "down" ]; then
sleep 2
ip route delete default
ip link set usb0 down
echo 0 > /sys/class/usb_composite/rndis/enable
fi
When I finish, sometimes I need to restart wifi on the player to get networking to work again.
The only real problem I've had is that some apps require or want wifi/3g active in order to fully function. For example, the play store works fine until you try and download an actual update. Google Maps works fine, although you get lots of warnings about having wifi turned off. I have no idea how to "emulate" 3g or wifi which I think would solve that problem.
This was fun getting running. Hope you enjoyed...
I know this is an old thread but I found this really really useful. Going to give it a try after work today. Great job.
Sent from my YP-G70 using xda app-developers app
I have a rooted a GT-I9195 (SGS4-mini) done with CF-Auto-Root and the latest Busybox. I then decided to use the "Ssh server" from The Olive Tree, since it is simple, small, free, but unfortunately have ads. For on-device/local shell, I use the Android Terminal Emulator and everything works great, including su and shell environment.
However, I have a really strange bahaviour when connecting using ssh via WiFi, and trying to su.
First when connecting via ssh, I get the following message.
Code:
[SIZE=2]$ ssh -2 -4 -t [email protected] -p 50555
Authenticated with partial success.
[email protected]'s password:
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ $[/SIZE]
I have Googled this and there's little useful info. On one site they even say:
Code:
[SIZE=2]Getting a controlling tty
[B]How does one get a controlling terminal? [COLOR=Red]Nobody knows[/COLOR], this is a great mystery.[/B]
The System V approach is that the first tty opened by the process
becomes its controlling tty. The BSD approach is that one has to
explicitly call
ioctl(fd, TIOCSCTTY, ...);
to get a controlling tty.
Linux tries to be compatible with both, as always, and this results in
a very obscure complex of conditions. Roughly:
The [B]TIOCSCTTY [/B]ioctl will give us a controlling tty, provided that (i)
the current process is a session leader, and (ii) it does not yet have
a controlling tty, and (iii) maybe the tty should not already control
some other session; if it does it is an error if we aren't root, or we
steal the tty if we are all-powerful.
Opening some terminal will give us a controlling tty, provided that
(i) the current process is a session leader, and (ii) it does not yet
have a controlling tty, and (iii) the tty does not already control
some other session, and (iv) the open did not have the [B]O_NOCTTY[/B] flag,
and (v) the tty is not the foreground VT, and (vi) the tty is not the
console, and (vii) maybe the tty should not be master or slave pty.
[/SIZE]
Now this is not the end of the world, if it was not that it doesn't understand normal terminal control characters and in addition, when I do su, I loose the command prompt. However, using the "-i" (interactive) switch gets me the "#" prompt, but environment is still completely messed up:
Code:
[SIZE=2][email protected]:/ $ [B]su -c /system/bin/sh -i[/B]
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ #[/SIZE]
I've never had or seen this issue before. Any ideas?
(Also, where would I put a source to my .bashrc and make sure it runs when su'ing or ssh?)
PS. The phone is using a stock 4.2.2 SELinux kernel.
Code:
[SIZE=2]Device: Samsung Galaxy S4 Mini LTE (GT-I9195)
Board/Platform: MSM8930AB (Snapdragon 400)
Baseband: I9195XXUBML4
Kernel: 3.4.0-2340422
[email protected] #1
Build: JDQ39.I9195XXUBML4
SE: SEPF_GT-I9195_4.2.2_0022
ro.build.date: Sat Dec 21 01:46:00 KST 2013
ro.build.description: serranoltexx-user 4.2.2 JDQ39 I9195XXUBML4
[/SIZE]
I still have no idea of what's causing those error messages above, also because logcat is not telling us anything interesting either. Only as Warning from "System.err", but without any useful information. However, I have got some improvement in the terminal behavior when doing the initial ssh connection.
One problem seem to be that the TERM environment variable was copied from local machine (PC side) to remote server (Android phone), thus giving TERM=cygwin to the Android shell. This can be disabled or changed as follows.
Some relevant SSH options:
Code:
[SIZE=2]
-e escape_char
Sets the escape character for sessions with a pty (default: `~'). The escape
character is only recognized at the beginning of a line. The escape charac-
ter followed by a dot (`.') closes the connection; followed by control-Z sus-
pends the connection; and followed by itself sends the escape character once.
Setting the character to "none" disables any escapes and makes the session
fully transparent.
-T Disable pseudo-tty allocation.
-t Force pseudo-tty allocation. This can be used to execute arbitrary screen-
based programs on a remote machine, which can be very useful, e.g. when
implementing menu services. Multiple -t options force tty allocation, even
if ssh has no local tty.
[/SIZE]
Some relevant SSH -o options:
Code:
[SIZE=2][B]RequestTTY[/B]
Specifies whether to request a pseudo-tty for the session. The argument may
be one of: "no" (never request a TTY), "yes" (always request a TTY when stan-
dard input is a TTY), "force" (always request a TTY) or "auto" (request a TTY
when opening a login session). This option mirrors the -t and -T flags for
ssh(1).
[B]
SendEnv[/B]
Specifies what variables from the local environ(7) should be sent to the
server. Note that environment passing is only supported for protocol 2. The
server must also support it, and the server must be configured to accept
these environment variables. Refer to AcceptEnv in sshd_config(5) for how to
configure the server. Variables are specified by name, which may contain
wildcard characters. Multiple environment variables may be separated by
whitespace or spread across multiple SendEnv directives. The default is not
to send any environment variables.
[/SIZE]
So by using the ssh -T option (which is equivalent to using '-o RequestTTY="no"'), we are disabling "pseudo-tty allocation" which doesn't work anyway, but with the effect of not forwarding local TERM to server, and thus setting it to default "vt100" which accepts backspace (but not insert). But a better way is to actually set the TERM variable on our own. This is done by simply adding it as a prefix to the ssh command like this:
Code:
[SIZE=2]TERM=[B]vt220[/B] ssh -t [email protected] -p 50555[/SIZE]
(This effectively, but temporarily overrides the local TERM value and forwards it to remote server shell.)
RanTime!
Since Google intruduced the SELinux/SEAndroid features, they have essentially fukced up the entire AOS ecosystem as based on good-old normal Linux environments and all the years of standards therein. Basically nothing works as before and as logically intended or preferred and I bet from now on, developers will have to spend a significant and expensive time, on just trying to setup their various developer environments and jump through the hoops of dikchead Google engineers, rather than on actual developing. A very sad story all thanks to the populist "security" eye-candy marketing.
The SU time!
Apparently after having read about the various quirks and issues in using an SELinux Enforced based AOS {4}, it seem that the issue from OP is probably due to one of 3 things or a combination thereof.
My su binary (SuperSU 1.94) is not yet handling SElinux properly
The SSHd server is not handling SELinux properly
Lack of properly set SSH and SHELL environment files on the server side
As for (1) I just have to wait and see. For (2) we can only test with other SSHd servers/solutions which I don't know what to use. (They're all, either not free or full of ads. WTF!) And finally, for (3) we can only test, since I don't have the source code...
Unfortunately listing the SuperSU (1.94) command line options is not very helpful, since they're rather poorly explained. While some of the option themselves just doesn't work (for me). It would have been great if @Chainfire could write a more detailed how-to {2} for all these options, but then again we should be extremely grateful he's written anything at all.
Code:
[SIZE=2]Usage: su [options] [--] [-] [LOGIN] [--] [args...]
------------------------------------------------------------------------------------
Options:
-c, --command COMMAND pass COMMAND to the invoked shell
-cn, --context CONTEXT switch to SELinux CONTEXT before invoking
-h, --help display this help message and exit
-, -l, --login pretend the shell to be a login shell
-m, -p,
-mm, --mount-master connect to a shell that can manipulate the
master mount namespace - requires su to be
running as daemon, must be first parameter
--preserve-environment do not change environment variables
-s, --shell SHELL use SHELL instead of the default detected shell
-v, --version display public version and exit
-V display internal version and exit
Usage#2: su LOGIN COMMAND...
Usage#3: su {-d|--daemon|-ad|--auto-daemon|-r|--reload}
auto version starts daemon only on SDK >= 18 or
if SELinux is set to enforcing
Usage#4: su {-i|--install|-u|--uninstall}
perform post-install / pre-uninstall maintenance
[/SIZE]
References:
[1] [Chainfire G+] Next Android version: even more breakage
[2] [Chainfire] How-To SU (Guidelines for problem-free su usage)
[3] SuperSU Download
[4] [Google] Validating Security-Enhanced Linux in Android
From THIS very old post by @mirabilos , it is possible that command-line TAB-completion and up-arrow is not working on all mksh binaries. So perhaps we just need a new static mksh binary installed?
Tab expansion is pretty broken on BSD with xterm and GNU screen, but the same seems to work better on ssh’ing out to Linux, I wonder why, since all software involved is the same… except tput though. But it works like that and is usable. With post-R40 mksh, you can get about with even less hacks (more similarity to AT&T ksh).
Click to expand...
Click to collapse
However, this still doesn't explain why I have no controlling tty for ssh sessions.
Also I tested a new and different SSH server called SSHelper, which has more features and is better maintained, without ads, but is also 6 times larger at ~ 6MB, because of included OpenSSH, FTP and webserver log functionality. When logging in via ssh I get:
Code:
...
Server refused to allocate pty
Followed by an empty non-responsive connection.
Is this the same as […]this problem elsewhere? Man, I'm searching for ideas and keep coming back to your questions all over the 'net
To clarify, I talked to someone at Google; they renamed mksh into just sh lately, but this should have no adverse effect. They currently ship R48 and “would have updated it if I knew there was a new version”. That being said, the code of the shell itself is not at fault here.
The “no controlling tty” message here is a red herring: you do not have access to a tty at all, let alone a ctty
As I said elsewhere, use “ssh -t” and either change the SELinux policies to allow pty/tty pair allocation, or disable it (possibly set it into permissive mode).
@mirabilos: Yes, thanks for that info. I haven't updated this thread since I started it, in anticipation of a writeup about SELinux. However, that proves to be a little over my head, so it will take some time. What is clear though, is that the above problem is connected with the SEAndroid protection mechanisms, which in turn have been mangled and incorporated into Samsungs KNOX.
Also I have been busy making the SSHelper support thread:
[APP][INFO|SUPPORT] SSHelper (The free Android SSH Server Application)
There I have also added a small section about mksh.
@ E:V:A - I recently put together a little package containing all necessary bins/scripts to create a SSH server (via dropbear and dropbearkey) (properly secured, not public) and connect with a SSH client (ssh). The package also contains bins/scripts to create a Telnet server (via utelnetd) and connect with Telnet client (via "static busybox" telnet). Everything works with superuser that I've tested. Linked in my signature and attached to post as well.
Instructions (for anyone who sees this and would like a guide)::
Basically just extract it anywhere with:
Code:
tar -xf easy.ssh.and.telnetz.clients+servers.tar.gz
(if it's in /sdcard/Download which is probable, do "cd /sdcard/Download" then run the above)
Change directory inside the folder:
Code:
cd ./ssh.telnetz
There are 6 scripts: ssh.start(connect to ssh server via ssh), sshd.start(create ssh server), ssh.kill(kill ssh processes and remove ssh server keys), and... 3x telnet scripts for the telnet equivalents.
Running scripts and optional parameters:
Code:
./telnetd.start [ shell ]
e.g. TELNET_PORT=8080 ./telnetd.start /system/bin/mksh
./telnet.start [ ip port ]
e.g. ./telnet.start 192.168.0.3 8080
./sshd.start [ <dropbear_flags_and_options ]
e.g. ./sshd.start (default port is 8090)
./ssh.start [ ip port shell ]
e.g. ./ssh.start 192.168.0.3 8090 /system/bin/mksh
Default ip is the loopback 127.0.0.1 so you can test running a server and connecting to it on your phone at the same time. Just change params as described above to connect from/to your phone (phone is client/server).
***As far as I have tested on Android 4.4.4, this works perfectly as root or restricted user. You can get a su'd ssh shell by starting the sshd.start with /system/xbin/su or just entering su after you've connected as a restricted user.***
I've finally found a work-around for the crippled /dev/pts job-control and su combination. There are two small problems that combines to this issue.
1. The SELinux policy is screwed up by Samsung. And others?
2. The /dev/pts is mounted wrong by default.
The work-around:
Make sure you're device is already in Enforcing mode, so that you get the proper su prompt (#).
1. Open terminal session 1.
Code:
[SIZE=2]
## On Terminal 1
ssh -2 [email protected] -p 2222
$ su -c /system/bin/sh -i
# su 0 setenforce 0
# umount /dev/pts
# su -cn u:r:init:s0 -c "busybox mount -t devpts -o rw,seclabel,relatime,mode=620,gid=5 devpts /dev/pts"[/SIZE]
2. Now go to Terminal 2 and login:
Code:
[SIZE=2]## On terminal 2
ssh -2 [email protected] -p 2222
$
[/SIZE]
(You now have job-control but no su possibility.)
3. Now go back to Terminal 1 and enable Enforcing mode:
Code:
[SIZE=2]## On Terminal 1
# su 0 setenforce 1
[/SIZE]
4. Now go back to Terminal 2 and escalate to su:
Code:
[SIZE=2]## On terminal 2
$ su -c /system/bin/sh -i
# [/SIZE]
Unfortunately if you exit the su (#) shell, you'll have to repeat steps 2-4 of the procedure.
Hi All,
I have a stupid Juniper VPN device at work which does not support 64 bit linux clients using netconnect. I have found ways around this previously, but now we are setting up 2 factor auth which throws a lot of javascript into the mix, making the scripts I used pretty much obsolete. The Junos pulse client works well for android, so I am thinking I want to use an android device as a router. Connecting to the VPN and using wifi tethering does not work, same with USB tethering does not work, and those are not exactly what I want anyway.
So basically I want to be able to connect my android device to my wifi here at home, connect to the VPN on it, run a script to do my setup on the Android device, lastly add a route on my client pc to tunnel through the android device. here is what I tried so far on the device:
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -P FORWARD ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.0.0/16 -d 10.0.0.0/8 -j MASQUERADE
ip rule add from all to 10.0.0.0/8 fwmark 0x3c lookup 60
and on the client PC:
Code:
route add -net 10.0.0.0 netmask 255.0.0.0 gw 192.168.1.29
where 192.168.1.29 is the IP of my android device, and 10.0.0.0/8(I know its lazy) is the IP range I want to go through tun0 on the device. This is however not working.
The only thing I need to do on a standard linux box to do this would be:
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -I POSTROUTING -s 192.168.0.0/16 -d 10.0.0.0/8 -j MASQUERADE
And setup the same route command on the client but point it at the linux box instead. This currently works, but when we decide to flip the switch and use the 2 factor auth only I will not be able to make it work on a standard linux box, but 2 factor does work on android via the Junos app.
I fear I am missing something simple in Android land, please help...