Closed GoogleCodeExporter closed 9 years ago
Is this actually an OpenVPN problem and not a Tunnelblick one?
Original comment by batman...@gmail.com
on 26 Feb 2009 at 4:31
I suppose Tunnelblick's. If you activate the DHCP discovery on the tap+
interface manually it will get the IP and
GW von dnsmasq. DNS will be ignored though.
I would like Tunnelblick to act kinda like the tap adapter under Windows. There
it will listen for DHCP but
override it in case of any dhcp-option.
Original comment by raf...@gmail.com
on 26 Feb 2009 at 4:59
Same "error=5" on 10.5.6 intel using b10. Looks like there is no TAP interface
created in the 1st place.
Reinstalled b7 and it worked right away.
Didn't check with b8 or b9.
HTH
Original comment by jp.mo...@gmail.com
on 19 Mar 2009 at 2:27
Adding my voice for this one. I have to manually run this command every time I
connect:
sudo ipconfig set tap0 DHCP
My Windows clients have no problem at all getting an IP address; it's just
Tunnelblick. I have tried adding the
above command as an auto-executing script, but no luck there.
Original comment by wilhelm....@gmail.com
on 16 Jun 2009 at 4:22
Is ever going to get fixed? I have 3.0b7 installed it works, but it would be
nice to
have some of the newer features. what changed code wise between b7 and b11 or
b10?
Original comment by richardg...@gmail.com
on 30 Jul 2009 at 1:00
I confirm I'm experiencing the same issue:
"write to TUN/TAP : Input/output error (code=5)"
TUN is working, but I prefer TAP. I am able to use TAP in Viscosity, but I'd
prefer
a working Tunnelblick. Any chance there's a compiled 3.0b11 beta I could test?
iBook G4 10.5.7
Original comment by amli...@comcast.net
on 3 Aug 2009 at 5:05
Actually, all you need is a up/down script setting
up:
/usr/sbin/ipconfig set $1 DHCP
down:
/usr/sbin/ipconfig set $1 NONE
Original comment by christ...@zagrodnick.de
on 21 Sep 2009 at 3:11
Actually, all you need is a up/down script setting
up:
/usr/sbin/ipconfig set $1 DHCP
down:
/usr/sbin/ipconfig set $1 NONE
Original comment by christ...@zagrodnick.de
on 21 Sep 2009 at 3:11
Up/down script didn't work for me.
Original comment by rmi6...@gmail.com
on 2 Dec 2009 at 7:53
Bump...
This is a serious issue for me. None of the suggested scripts, or
troubleshooting
tips have helped at all.
What do we need to do to get this working?
Original comment by afreeman...@gmail.com
on 20 Jan 2010 at 2:42
I don't have access to a server which does TAP, so I can't test anything to do
with it.
From comment #5 on this Issue, an old version of Tunnelblick, 3.0b7, apparently
works. If you can try 3.0b7 and
it works for you, try versions 3.0b8, 3.0b9, 3.0b10, etc. until you find one
that doesn't work. Then let us know
what happened and we can look at what changes were made, and (I hope) get a
clue as to what is causing the
problem.
And if 3.0b7 doesn't work for you, let us know that, too, please.
Original comment by jkbull...@gmail.com
on 20 Jan 2010 at 4:50
ok for me using the latest 3.0b24 version and the up/down script from:
http://openvpn.net/archive/openvpn-users/2006-10/msg00120.html
it also sets the DNS so you don't have to check the "set nameserver" option, as
this triggers the included
up/down scripts which don't work for TAP.
Original comment by marcello.teodori
on 20 Jan 2010 at 9:42
If anyone has been able to get this working I would apperichate a explanation
of how
you got it to work. That is tap with isc-dhcp over openvpn on os x. I want
each
client to have a public IP for accounting reasons. I have only been able to
get it
working on Windows XP so far.
-Thanks
Original comment by storagen...@gmail.com
on 30 Jan 2010 at 8:32
I know only one good GUI to work with OpenVPN is Linux NetworkManager. It does
everyting well, asks for name, cert, does DHCP hacks, does default routing/local
network access.
I hope Tunnelblick will do the same.
And that is Thunnelblick problem ;)
Original comment by kuznetsov.alexey
on 19 Mar 2010 at 1:47
Please solve it within
/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh for
upcoming release 3.1.
(check if here is no ip coming from server, then set interface to receive dhcp
packets)
Original comment by kuznetsov.alexey
on 7 Jun 2010 at 11:01
Please try "Set nameserver (alternate 1)" in Tunnelblick 3.1beta18.
Original comment by jkbull...@gmail.com
on 18 Oct 2010 at 10:23
Original comment by jkbull...@gmail.com
on 31 Oct 2010 at 12:44
This issue still exists on the current 3.1.4 version. I have tried the
suggestions and the set nameserver alt 1 with no results. I can connect the
VPN connection and then issue sudo ipconfig set tap0 DHCP then the pipe gets an
IP and goes to town.
Original comment by mprin...@gmail.com
on 31 Jan 2011 at 12:21
[deleted comment]
This issue _may_ have been resolved with Tunnelblick 3.2beta10. Feedback would
be appreciated.
Original comment by jkbull...@gmail.com
on 2 May 2011 at 10:48
3.2beta10 not working...
Original comment by kuznetsov.alexey
on 4 May 2011 at 1:46
log
Original comment by kuznetsov.alexey
on 4 May 2011 at 1:51
Attachments:
@keznetsov.alexey
Does "Set nameserver (alternate 1)" work any differently? Please submit your
configuration file, also. Thanks.
Original comment by jkbull...@gmail.com
on 4 May 2011 at 2:20
Yes, working fine with "alternate1"
Original comment by kuznetsov.alexey
on 5 May 2011 at 9:47
A bug in the script used by 'Set nameserver (alternate 1)' has been discovered
and a fix has been committed as r1480. It will be included in the next beta
release.
Original comment by jkbull...@gmail.com
on 5 May 2011 at 7:09
problem is back for: Tunnelblick 3.2beta28 (build 2714)
Original comment by kuznetsov.alexey
on 18 Aug 2011 at 3:38
@keznetsov.alexey -
Do you mean the problem is back even when you have selected 'Set nameserver
(alternate 1)'? Or only when you select the default 'Set nameserver'?
Original comment by jkbull...@gmail.com
on 27 Aug 2011 at 11:01
I have selected "alternate 1" and i have no DHCP set for interface and no IP
assigned to it.
Original comment by kuznetsov.alexey
on 27 Aug 2011 at 1:01
Thanks for reporting this.
Neither 'Set nameserver (alternate 1)' or 'Set nameserver' work?
What version of Tunnelblick had you been using that did work?
Please post the full log of a connection attempt and configuration file.
Original comment by jkbull...@gmail.com
on 27 Aug 2011 at 1:24
im using vpn only when im traveling. so i did know when it got broken. last my
comment here was 5 may...
for alternate 1 http://pastebin.com/JGnA7jSi, config
http://pastebin.com/9RDW6KrB
yes, they booth fail
Original comment by kuznetsov.alexey
on 27 Aug 2011 at 1:36
no, it actually works for "Set nameserver" sorry for mislead.
Original comment by kuznetsov.alexey
on 27 Aug 2011 at 2:12
Thanks. That's actually good news -- because "Set nameserver" is the new
standard script, and is meant to do everything that the both the old "Set
nameserver" and the old "Set nameserver (alternate 1)" did. So your comment is
further evidence that it does that.
I'm marking this Issue as Fixed.
Original comment by jkbull...@gmail.com
on 27 Aug 2011 at 4:26
I'm experiencing this issue with multiple versions of Tunnelblick. I've
attempted the latest stable release and also multiple beta releases. Today I'm
using 3.2beta30 (build 2780).
I get no IP from the DHCP server and see the "input output error" message with
"Set nameserver" and "Set nameserver (alternate 1)".
I do get an IP and can send traffic to the VPN LAN when I use "Set nameserver
(3.0b10)".
Original comment by Michael....@gmail.com
on 12 Sep 2011 at 6:23
@ Michael....@gmail.com --
Do you get the "input output error" message with "Set nameserver (3.0b10)" or
is it completely working for you?
Could you provide the complete log of a connection up/down cycle from the "VPN
Details…" window when using "Set nameserver"? That may help us find and fix
the problem.
Original comment by jkbull...@gmail.com
on 15 Sep 2011 at 10:38
I think I am struck with the same issue using Tunnelblick 3.1.7. I posted in
the openvpn.eu-forum a day ago, so can see my config and logs here:
http://forum.openvpn.eu/viewtopic.php?f=1&t=7646&sid=c11df3cea922be9a0d24499c510
157c6
In the german text I mainly tell that I don't know what causes the problems
that occur :)
In my case it makes no difference, which nameserver-option is selected, but I'm
quite a bit unsure if the problem isn't also caused by the fact, that my
isc-dhcpd expects a dhcp-client-identifier. I don't know how to transmit this
information over the tap0-interface which is automatically created by
Tunnelblick.
If there's a way to manage this, I could tell you which of the
nameserver-options work in my case if one of them did.
Original comment by dagot...@googlemail.com
on 19 Sep 2011 at 7:19
@dagot...@googlemail.com -
Please try Tunnelblick 3.2beta30. "Set nameserver" has changed significantly,
so you should try all the "Set nameserver" settings.
Original comment by jkbull...@gmail.com
on 19 Sep 2011 at 7:34
@jkbull...@gmail.com: I tried 3.2b30 and don't get these errors with 3.0b10
now, so this option seems to fix the issue. I still don't get a working
connection, but I think that's because I'm not capable to send an
DHCP-Client-ID and my dhcpd only accepts known clients. Nevertheless, thanks
for your hint to use 3.2beta30!
Original comment by dagot...@googlemail.com
on 20 Sep 2011 at 2:41
@dagot...@googlemail.com -
Maybe it's obvious, but have you tried setting the Client ID in Network
Settings / Advanced for the Ethernet and/or Airport interface? Maybe it would
be passed through.
Original comment by jkbull...@gmail.com
on 20 Sep 2011 at 2:56
This was my first idea, too, but I'm trying to connect through an UMTS-stick
whose Network Settings don't provide an ID to be set. I also can't find a way
to set the option on tap0-device through the shell.
With a connection like this, I believe it's impossible to get a VPN-Connection
with DHCP working.
Though this is only for test purposes (I'm going to use a wifi-connection in
the future, but have no further test-environment than the stick by now) it's
maybe a point to think about in future releases?
Thank you for your help!
Original comment by dagot...@googlemail.com
on 20 Sep 2011 at 5:08
Original issue reported on code.google.com by
raf...@gmail.com
on 25 Feb 2009 at 7:03