Closed GoogleCodeExporter closed 9 years ago
Issue 146 has been merged into this issue.
Original comment by jkbull...@gmail.com
on 2 Sep 2010 at 1:03
Please try using "Set nameserver (alternate 1)" in Tunnelblick 3.1beta18.
Original comment by jkbull...@gmail.com
on 18 Oct 2010 at 10:18
Please try using "Set nameserver (alternate 1)" in Tunnelblick 3.1beta18.
Original comment by jkbull...@gmail.com
on 18 Oct 2010 at 10:18
Original comment by jkbull...@gmail.com
on 31 Oct 2010 at 12:42
I have this problem too & have been trying to find a workaround in order to
keep my search domain on LAN as well as add the search domain for VPN...
Original comment by Still...@gmail.com
on 13 Mar 2011 at 5:20
@Still...@gmail.com:
And "Set nameserver (alternate 1)" doesn't help?
Original comment by jkbull...@gmail.com
on 13 Mar 2011 at 8:31
Original comment by jkbull...@gmail.com
on 2 Apr 2011 at 6:58
I also encountered the same problem. Looking inside client.3.up.tunnelblick.sh
script (which is executed when using "Set nameserver (alternate 1)") seems that
the problem resides in the logic handling the push "dhcp-option DOMAIN" (line
105). It's being considered as a single value when it should be considered as a
multiple value (like the DNS parameter).
I have modified the script and now it seems to work fine. However this has been
a very quick fix and I am far from an expert regarding this kind of scripts.
Maybe one of the team members could check if its all right.
Regards
Original comment by david.ba...@gmail.com
on 12 Oct 2011 at 12:09
Attachments:
This would be great if we could get this into the next release :)
Just tested with the latest beta and is still just takes the last domain you
specify and throws the others away.
Original comment by ea...@tubemogul.com
on 31 Aug 2012 at 5:13
This was added in Tunnelblick 3.3beta18 on 2012-08-04:
"Adds a new checkbox on the 'Advanced' settings page that tells Tunnelblick to
add the domain name provided by OpenVPN to the start of the list of search
domains. This checkbox is disabled and unchecked unless the DNS/WINS setting is
set to 'Set nameserver'. Adding the domain name does not take place if the
search domains are manually set."
If it isn't working for you, please post your configuration file and the full
Tunnelblick log.
Original comment by jkbull...@gmail.com
on 2 Sep 2012 at 5:44
Still not working as expected.
After downloading and installing the 3.3beta20 (build 3105), I configured the
connection as stated in the previous comment, still having the same issue. The
VPN server sends three different dhcp-option DOMAIN lines and only the last one
is used (connection log attached).
As I did before (see my previous comment, number 7), I took a look at the
client.up.tunneblick.sh script and found the same thing: DOMAIN options are not
stored in an array (lines 822 to 842):
while vForOptions=foreign_option_$nOptionIndex; [ -n "${!vForOptions}" ]; do
vOptions[nOptionIndex-1]=${!vForOptions}
case ${vOptions[nOptionIndex-1]} in
*DOMAIN* )
sDomainName="$(trim "${vOptions[nOptionIndex-1]//dhcp-option DOMAIN /}")"
;;
*DNS* )
aNameServers[nNameServerIndex-1]="$(trim "${vOptions[nOptionIndex-1]//dhcp-option DNS /}")"
let nNameServerIndex++
;;
*WINS* )
aWinsServers[nWinsServerIndex-1]="$(trim "${vOptions[nOptionIndex-1]//dhcp-option WINS /}")"
let nWinsServerIndex++
;;
* )
logMessage "Unknown: 'foreign_option_${nOptionIndex}' = '${vOptions[nOptionIndex-1]}' ignored"
;;
esac
let nOptionIndex++
done
Therefore only the value in the last option is used. IMHO A code similar to the
one I posted (in October 2011) should fix the issue, however I might be wrong
given I'm not an expert in bash scripting.
Regards.
Original comment by david.ba...@gmail.com
on 3 Sep 2012 at 10:10
Attachments:
I apologize. I was referring to a different problem with search domains.
Original comment by jkbull...@gmail.com
on 4 Sep 2012 at 12:57
should be a pretty straight forward patch, no?... could we get that on next
version? If you're too busy, I could try my hand at putting this change in?
Original comment by ea...@tubemogul.com
on 4 Sep 2012 at 1:22
It does look straightforward, but it needs to be applied to
client.up.tunnelblick.net, which is the default up script.
The purpose of the other scripts is for backward compatibility, so I do not
want to change client.3.up.tunnelblick.net, for example, (because that
defeats the purpose of the backward compatibility).
I try to be very careful about changing these scripts, because they run as
root and are used by so many people.
It would be great if you could create a new patch based on
client.up.tunnelblick.net. If I am able to really look at it and test it
out thoroughly I would put it into the next beta release, which I hope to
have out soon (either in the next few days or in a couple of weeks; it
depends on some other changes being ready).
Original comment by jkbull...@gmail.com
on 4 Sep 2012 at 1:40
I agree. In 2011 I made the fix in client.3.up.tunnelblick.net because it was
the configuration I was using and I was not sure myself about which script
should be fixed
As soon as I have some spare time I'll fix the client.up.tunnelblick.net and
send you the patch for testing.
Original comment by david.ba...@gmail.com
on 4 Sep 2012 at 2:02
That would be great!
Original comment by jkbull...@gmail.com
on 4 Sep 2012 at 2:04
Seems that I am not gonna make it. Not confident enough in the changes I made.
Not sure about how the script should handle the different cases (also not sure
about how many different cases there are) ^_^U
I have been digging into the script and there were several changes to be made.
Detection of multiple push DOMAIN was easy to accomplish, however deciding what
to do with the domains was not.
Current version of the script took one DOMAIN and set it, leave it, append it
or prepended based on the current configuration, the configuration the user set
manually, the OS version and the new "Prepend domain option".
Currently I am a little confused about how the multiple domain should be
treated. This is a very big script with tons of vars and I have the feeling
that some of the logic is not needed. The different CUR_ and MAN_ vars confuse
me. At first glance one would say that checking the current config is all that
is needed, but what happens when the user has several simultaneos vpn sessions
opened. Also the different behaviour between OS versions seems so arbitrary and
needless.
Maybe I am missing something (I am missing something for sure) cause as I
stated before, I am not a Bash scripting expert and do not really know all the
corner cases the script has to handle, ^_^
So, I am only able to deliver a half assed script. Therefore I prefer not to
deliver it.
My apologies :(
Original comment by david.ba...@gmail.com
on 6 Sep 2012 at 8:17
David, thank you very much for trying, and for articulating the complexity of
the scripts.
Here are my comments; they may help anyone else looking at this script:
What to do with multiple domains: I think multiple domains should be treated
the same as a single domain, either set (if there is no current domain),
appended, prepended, or ignored (if there is a manual domain setting).
The CUR_xxx, MAN_xxx variables: The CUR_xxx variables contain the current
network setting and the MAN_xxx contains the network settings that were set
manually. The reason for having both is that as a general rule -- almost a
philosophy -- we don't modify anything that was set manually. By having both we
can see whether a particular setting was set manually or not.
Simultaneous VPN sessions: None of the Tunnelblick scripts work with that
situation, as far as I know. The script for the second configuration to be
connected would overwrite the variables stored by the script for the first
configuration. I think each multi-VPN situation needs to be scripted by whoever
sets up the VPN. (Again, as far as I know. Maybe there are some situations
where the standard script works.)
The different behavior between OS versions is arbitrary and capricious because
the different OS X versions are arbitrary and capricious. The goal is to handle
OpenVPN VPN sessions the same way that OS X handles built-in VPN sessions like
PPTP. Since OS X changed its behavior with the OS version, the script changes
its behavior with the OS version.
Again, thanks David for looking into this.
Original comment by jkbull...@gmail.com
on 6 Sep 2012 at 11:22
i've the same trouble with multiple search domain.
so i'm waiting beta with this update. thanks
Original comment by a...@romanov.ws
on 6 Oct 2012 at 7:51
[deleted comment]
I have a question, related to a question I just asked on Issue 220 [1]:
Why is "DOMAIN" being treated as a search domain?
OS X seems to have two different DNS parameters: a single "domain", and a set
of zero or more "search domains". The existing Tunnelblick scripts seem to use
"DOMAIN" for both.
Should the scripts be changed so that
* "SEARCH-DOMAIN" is a set of zero or more entries that are to be stored as OS
X "search domains"; and
* "DOMAIN" is used (A) as the "domain" and (B) if no SEARCH-DOMAIN are
specified, as the "search domain"?
This would be downward-compatible (I think) but would allow setting of an
arbitrary list of search domains.
* The DOMAIN would replace any existing domain unless a domain is manually set.
* The SEARCH-DOMAINs would be set, appended, prepended, or ignored, just like
DNS or WINS servers.
* Multiple "DOMAIN" entries would cause a warning to be put in the log and
(A) Be ignored; or
(B) Be treated as if they were "SEARCH-DOMAIN"
[1] http://code.google.com/p/tunnelblick/issues/detail?id=220
Original comment by jkbull...@gmail.com
on 19 Feb 2013 at 6:57
In my previous comment, "SEARCH-DOMAIN" should be "DOMAIN-SEARCH", sorry.
Original comment by jkbull...@gmail.com
on 20 Feb 2013 at 4:05
I believe multiple DOMAIN entries is non-standard and the client behavior is
undefined; I think using DOMAIN-SEARCH is the better option.
FYI, OpenVPN on Windows behaves the same way (only the last DOMAIN is used),
and Linux w/NetworkManager is the opposite (only uses the _first_ DOMAIN).
Connecting from cmdline and using the update-resolv-conf script does add all of
them to the search list, but that's to be expected since it just loops through
the DHCP options.
Original comment by andrew.d...@gmail.com
on 13 Mar 2013 at 8:43
Agreed, Domain-Search would totally work for out needs!
Original comment by ea...@tubemogul.com
on 13 Mar 2013 at 8:47
Tunnelblick 3.3beta34 includes the following changes, which I think should
close this Issue and Issue 220:
* Multiple "DOMAIN-SEARCH" entries are allowed, and are set, prepended, or ignored, like DNS or WINS servers.
* "DOMAIN" is used (A) as the "domain" and (B) if no DOMAIN-SEARCH entries are specified, as the "search domain"
* Only the last "DOMAIN" entry is used (like Windows)
(But I'll leave this Issue and Issue 220 open for a while.)
Original comment by jkbull...@gmail.com
on 27 Mar 2013 at 10:54
Original comment by jkbull...@gmail.com
on 10 Apr 2013 at 6:41
Original issue reported on code.google.com by
bretep
on 11 Feb 2010 at 6:38