Another lost Vista user!
Carmen Sandiego on Tuesday, 02 December 2008 19:47:15
The story so far... Got to the point of being able to nslookup and ping random IPv6 Internet hosts, but just could not get a browser to go to an IPv6 address (even if explicitly typed into the URL bar). Looked like I should be all set, didn't get hung up where so many other Vista users have been. Thought perhaps it was just another one of those random Vista problems that a reboot would set right. Post reboot, I can still do nslookups and I can ping my tunnel, but I can't ping (or traceroute) anything else anymore!
Another lost Vista user!
Shadow Hawkins on Thursday, 04 December 2008 10:13:26
I started to document all of the steps necessary to get Windows Vista working with AICCU and an AYIYA IPv6 tunnel on the wiki.
This is just a first draft right now, but it may help you with your issue.
In particular, look at steps 8-14 on the instructions from the wiki, as this may help you if you are running AICCU on Vista. If it does not help, try giving the information requested in step 14 in a reply to this forum thread.
Good Luck.
Another lost Vista user!
Carmen Sandiego on Wednesday, 03 December 2008 18:32:13
Thanks! I'll give it a try!
Another lost Vista user!
Carmen Sandiego on Wednesday, 03 December 2008 18:53:52
No go. Same spot I was after the other reboot (and tried rebooting again after step 14). Looks like Vista is locking onto some other address to try and use (fdfe...) as my default route (what is a "temporary" address?). Not sure where this other one is coming from, or how to get rid of it. :-( Also interesting that I'm yet another step further back than I was yesterday (not able to ping remote end of the tunnel anymore)!
C:\Windows\system32>netsh int ipv6 show address
Interface 1: Loopback Pseudo-Interface 1
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Other Preferred infinite infinite ::1
Interface 11: Local Area Connection 2
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Manual Preferred infinite infinite 2002:81a8:102::
Public Preferred 29d23h58m42s 6d23h58m42s fdfe:182a:bdca:470f:6164:9e73:407
c:e6bd
Temporary Preferred 6d22h26m57s 6d22h26m57s fdfe:182a:bdca:470f:d118:e052:a794
:dd95
Other Preferred infinite infinite fe80::6164:9e73:407c:e6bd%11
Interface 20: aiccu
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Manual Preferred infinite infinite 2001:4978:f:21d::2
Other Preferred infinite infinite fe80::f113:9f2e:69a8:f5c7%20
C:\Windows\system32>netsh int ipv6 show route
Publish Type Met Prefix Idx Gateway/Interface Name
------- -------- --- ------------------------ --- ------------------------
No Manual 256 ::/0 11 fe80::21d:a2ff:feaf:2ffc
Yes Manual 256 ::/0 20 2001:4978:f:21d::1
No Manual 256 ::1/128 1 Loopback Pseudo-Interface
1
No Manual 256 2001:4978:f:21d::/64 20 aiccu
No Manual 256 2001:4978:f:21d::2/128 20 aiccu
No Manual 256 2002:81a8:102::/64 11 Local Area Connection 2
No Manual 256 2002:81a8:102::/128 11 Local Area Connection 2
No Manual 8 fdfe:182a:bdca:470f::/64 11 Local Area Connection 2
No Manual 256 fdfe:182a:bdca:470f:6164:9e73:407c:e6bd/128 11 Local
Area Connection 2
No Manual 256 fdfe:182a:bdca:470f:d118:e052:a794:dd95/128 11 Local
Area Connection 2
No Manual 256 fe80::/64 11 Local Area Connection 2
No Manual 256 fe80::/64 20 aiccu
No Manual 256 fe80::6164:9e73:407c:e6bd/128 11 Local Area Connectio
n 2
No Manual 256 fe80::f113:9f2e:69a8:f5c7/128 20 aiccu
No Manual 256 ff00::/8 1 Loopback Pseudo-Interface
1
No Manual 256 ff00::/8 11 Local Area Connection 2
No Manual 256 ff00::/8 20 aiccu
C:\Windows\system32>ipconfig/all
Windows IP Configuration
Host Name . . . . . . . . . . . . : bknoblauch
Primary Dns Suffix . . . . . . . : sscorp.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : sscorp.com
Ethernet adapter aiccu:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TAP-Win32 Adapter V9
Physical Address. . . . . . . . . : 00-FF-86-7E-64-13
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:4978:f:21d::2(Preferred)
Link-local IPv6 Address . . . . . : fe80::f113:9f2e:69a8:f5c7%20(Preferred)
Autoconfiguration IPv4 Address. . : 169.254.245.199(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 2001:4978:f:21d::1
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek RTL8168B/8111B Family PCI-E Gigab
it Ethernet NIC (NDIS 6.0)
Physical Address. . . . . . . . . : 00-1A-4D-5F-03-47
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2002:81a8:102::(Preferred)
IPv6 Address. . . . . . . . . . . : fdfe:182a:bdca:470f:6164:9e73:407c:e6bd(P
referred)
Temporary IPv6 Address. . . . . . : fdfe:182a:bdca:470f:d118:e052:a794:dd95(P
referred)
Link-local IPv6 Address . . . . . : fe80::6164:9e73:407c:e6bd%11(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.100.65(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.254.0
Default Gateway . . . . . . . . . : fe80::21d:a2ff:feaf:2ffc%11
192.168.100.1
DNS Servers . . . . . . . . . . . : 192.168.102.10
192.168.102.14
NetBIOS over Tcpip. . . . . . . . : Enabled
Tunnel Information for T18391:
PoP Id : uschi02
IPv6 Local : 2001:4978:f:21d::2/64
IPv6 Remote : 2001:4978:f:21d::1/64
Tunnel Type : ayiya
Adminstate : enabled
Userstate : enabled
Name : My First Tunnel
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.100.65)
### This should return so called 'echo replies'
### If it doesn't then check your firewall settings
### Your local endpoint should always be pingable
### It could also indicate problems with your IPv4 stack
Pinging 192.168.100.65 with 32 bytes of data:
Reply from 192.168.100.65: bytes=32 time<1ms TTL=128
Reply from 192.168.100.65: bytes=32 time<1ms TTL=128
Reply from 192.168.100.65: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.100.65:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
######
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (216.14.98.22)
### These pings should reach the PoP and come back to you
### In case there are problems along the route between your
### host and the PoP this could not return replies
### Check your firewall settings if problems occur
Pinging 216.14.98.22 with 32 bytes of data:
Reply from 216.14.98.22: bytes=32 time=64ms TTL=53
Reply from 216.14.98.22: bytes=32 time=55ms TTL=53
Reply from 216.14.98.22: bytes=32 time=45ms TTL=53
Ping statistics for 216.14.98.22:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 45ms, Maximum = 64ms, Average = 54ms
######
####### [3/8] Traceroute to the PoP (216.14.98.22) over IPv4
### This traceroute should reach the PoP
### In case this traceroute fails then you have no connectivity
### to the PoP and this is most probably the problem
Tracing route to sixxs.cx01.chi.bb.your.org [216.14.98.22]
over a maximum of 30 hops:
1 1 ms <1 ms <1 ms 12.199.185.1
2 13 ms 9 ms 13 ms 12.88.183.17
3 19 ms 19 ms 19 ms cr81.dtrmi.ip.att.net [12.122.102.14]
4 22 ms 17 ms 21 ms cr1.cgcil.ip.att.net [12.123.139.157]
5 17 ms 20 ms 20 ms tbr1.cgcil.ip.att.net [12.122.17.146]
6 17 ms 18 ms 16 ms ggr6.cgcil.ip.att.net [12.122.87.245]
7 18 ms 16 ms 20 ms 192.205.35.138
8 19 ms 18 ms 18 ms your.org.ge2-5.br02.chc01.pccwbtn.net [63.218.5.38]
9 57 ms 52 ms 31 ms sixxs.cx01.chi.bb.your.org [216.14.98.22]
Trace complete.
######
###### [4/8] Checking if we can ping IPv6 localhost (::1)
### This confirms if your IPv6 is working
### If ::1 doesn't reply then something is wrong with your IPv6 stack
Pinging ::1 from ::1 with 32 bytes of data:
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Ping statistics for ::1:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
######
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4978:f:21d::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
Pinging 2001:4978:f:21d::2 from 2001:4978:f:21d::2 with 32 bytes of data:
Reply from 2001:4978:f:21d::2: time<1ms
Reply from 2001:4978:f:21d::2: time<1ms
Reply from 2001:4978:f:21d::2: time<1ms
Ping statistics for 2001:4978:f:21d::2:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
######
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4978:f:21d::1)
### This confirms the reachability of the other side of the tunnel
### If it doesn't reply then check your interface and routing tables
### Don't forget to check your firewall (both IPv4 and IPv6) of course
### If the previous test was succesful then this could be both
### a firewalling and a routing/interface problem
Pinging 2001:4978:f:21d::1 from 2001:4978:f:21d::2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 2001:4978:f:21d::1:
Packets: Sent = 3, Received = 0, Lost = 3 (100% loss),
######
###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net)
### This confirms that you can reach the central machine of SixXS
### If that one is reachable you should be able to reach most IPv6 destinations
### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connection
### If your browser supports IPv6 and uses it of course.
######
###### [8/8] Traceroute6 to (www.kame.net)
### This confirms that you can reach a Japanese IPv6 destination
### If that one is reachable you should be able to reach most IPv6 destinations
### You should also check http://www.kame.net which should display
### a animated kame (turtle), of course only when your browser supports and uses IPv6
######
###### ACCU Quick Connectivity Test (done)
### Either the above all works and gives no problems
### or it shows you where what goes wrong
### Check the SixXS FAQ (http://www.sixxs.net/faq/
### for more information and possible solutions or hints
### Don't forget to check the Forums (http://www.sixxs.net/forum/)
### for a helping hand.
### Passing the output of 'aiccu autotest >aiccu.log' is a good idea.
Another lost Vista user!
Carmen Sandiego on Wednesday, 03 December 2008 19:14:49
Another update:
Doing a "netsh interface ipv6 set privacy state=disable" makes that weird fdfe "temporary address" go away and allows me to ping the other end of the tunnel again. However, still no ability to ping Internet hosts via IPv6.
Another lost Vista user!
Carmen Sandiego on Wednesday, 03 December 2008 19:17:34
Yikes. That pesky temporary address is back!
Another lost Vista user!
Jeroen Massar on Wednesday, 03 December 2008 19:16:56
AICCU test is useless in these cases, it will only tell you that it does not work. /me still need to finalize the new AICCU and resolve that.
First try a:
netsh int ipv6 reset
Then disable 6to4, teredo, isatap:
netsh int ipv6 6to4 set state disabled
netsh int ipv6 6to4 set teredo disable
netsh int ipv6 isatap set state disabled
That should take care of the 2002:: addresses (6to4), though 2002:81a8:102::/64 apparently is derived from 129.168.1.2; I guess somebody made a typo there, do you have another host on your network with IPv6 and more specifically 6to4 enabled?
The gateway of fe80::21d:a2ff:feaf:2ffc which seems to be announcing that broken 6to4 prefix is apparently a Cisco, any such gear around?
Another lost Vista user!
Carmen Sandiego on Wednesday, 03 December 2008 19:28:33
Unfortunately, netsh int ipv6 reset doesn't seem to do anything (yes, I rebooted) :). It *did* do something on day 1 that I tried this, but today doesn't seem to do anything. The 6to4, teredo, and isatap are already disabled.
Turning off routerdiscovery and turning on managedaddress (M flag) has now allowed me to get to my previous "best" point of yesterday. I can ping www.kame.net over IPv6. I just can't get there via browser.
We may very well still have something with 6to4 on it. We played around with that years ago... :-/
Another lost Vista user!
Jeroen Massar on Wednesday, 03 December 2008 19:38:47
Can you do a "tracert6 www.sixxs.net" and paste the output here?
The only thing that might prevent on Vista that you can do that
We may very well still have something with 6to4 on it.
No, I see that in the Wiki: Configuring Windows Vista there is that wrong configuration entry {netsh int ipv6 add address "Local Area Connection" 2002:81a8:102::}, that is where it comes from. That one is supposed to fix a trick with not connecting to IPv6 websites.
I wonder why "2002:81a8:102::" aka 129.168.1.2 was chosen for this, it definitely is not any IP that you can just use and looks a lot like a typo for 192.168.1.2, which can't be assigned as a 6to4 address as it is RFC1918. I also think that it is a rather weird thing to use a 6to4 prefix, better use a global address in that case.
Did you try going to http://www.ipv6.sixxs.net, that has only an AAAA record, that should work.
The other prefix with fdfe:: is thus most likely the one which comes from a Cisco and should not be there as it will be causing issues. fdfe:: is a ULA prefix btw. It is not registered in the ULA list though.
Another lost Vista user!
Carmen Sandiego on Wednesday, 03 December 2008 20:24:11
Ah yes, now that you mention it, that's where that 2002 came from. Without it, the resolver refuses to return AAAA records. Done so many things with the setup these couple of days that I'm beyond confused. :-)
www.ipv6.sixxs.net just fails with an "unable to connect" error from all my browsers (IE, Safari, Chrome). Kame comes up as IPv4 only.
C:\Windows\system32>tracert -6 www.sixxs.net
Tracing route to www.m.sixxs.net [2001:838:1:1:210:dcff:fe20:7c7c]
over a maximum of 30 hops:
1 98 ms 116 ms 44 ms gw-542.chi-02.us.sixxs.net [2001:4978:f:21d::1]
2 171 ms 37 ms 23 ms sixxs.ge-0.0.0-30.core1.chi.bb6.your.org [2001:4
978:1:400::ffff]
3 33 ms 35 ms 26 ms gige-g2-19.core1.chi1.he.net [2001:470:0:7f::1]
4 137 ms 46 ms 46 ms 10gigabitethernet2-4.core1.nyc4.he.net [2001:470
:0:4e::2]
5 258 ms 176 ms 655 ms 10gigabitethernet1-2.core1.lon1.he.net [2001:470
:0:3e::2]
6 127 ms 133 ms 123 ms 10gigabitethernet1-1.core1.ams1.he.net [2001:470
:0:3f::2]
7 665 ms 131 ms 129 ms 2001:470:1:1f::2
8 136 ms 123 ms 603 ms jointtransit.ip6.concepts-ict.nl [2a02:10:0:2::4
]
9 127 ms 167 ms 125 ms 2001:838:0:10::2
10 272 ms 127 ms 130 ms noc.sixxs.net [2001:838:1:1:210:dcff:fe20:7c7c]
Trace complete.
Another lost Vista user!
Jeroen Massar on Wednesday, 03 December 2008 20:39:33
Except for latency jumps in the traceroute, all of that looks just fine. Can you test with Firefox btw?
I don't have a Vista box here to test out (XP works perfectly fine thus I don't see the point of 'upgrading'), thus I am all of ideas with respect to why it is making so much troubles. I actually thought that Vista was supposed to be fully IPv6 happy, and the last time I tested it, it worked actually... Vista is on the test-list for the new AICCU though, then I'll figure out what all the menace is about.
Another lost Vista user!
Carmen Sandiego on Wednesday, 03 December 2008 21:23:39
Well. I installed Firefox and immediately lost my ability to even lookup AAAA records. Rebooted, no change. Uninstalled Firefox, no change. I'm at a loss as to why I suddenly can't resolve anymore. Traceroutes to IPv6 sites still work as long as I don't need to resolv a DNS name.
Another lost Vista user!
Shadow Hawkins on Wednesday, 03 December 2008 22:05:18
Brian / Jeroen -
The 2002:81a8:102:: address is just a work-around for the fact that Vista will not do "AAAA" dns lookups without a global address assigned to a physical network interface. Apparently Vista does not accept the fact that a global address is assigned to a virtual network interface (tap901 driver) as good enough to enable "AAAA" lookups.
Jeroen --
If you would rather I use some other IPv6 address as a work-around (rather than the bastardized 2002:81a8:102::, let me know and I will test it on Vista and update the wiki as appropriate.
As per the draft wiki page (Step 8):
* Run the following command to work-around the issue with Vista and AICCU IPv6 "AAAA" DNS lookups with a virtual interface:
netsh int ipv6 add address "Local Area Connection" 2002:81a8:102::
* Make sure to replace "Local Area Connection" with your actual physical ethernet (wired or wireless) network interface name if the name is different on your computer.
o You can see your network interface names using ipconfig /all at a command prompt
* Note: See http://technet.microsoft.com/en-us/library/bb727035.aspx for more information on Vista DNS
This should restore the automatic "AAAA" dns lookups. The easiest way to test if this is your problem is as follows:
Run:
ping www.kame.net
(Do not use -4 or -6 flags)
If it resolves to an IPv4 address, then you have the issue that the work-around *should* solve (works for me and several others). If after assigning the global address (should take effect immediately), it still does not resolve to an IPv6 address, then you likely have a resolver issue (only way to tell for sure is to diagnose with nslookup/dig and/or wireshark/netmon.
The system dns resolver library (when not forced otherwise) will use IPv6 addresses over IPv4 addresses when both are present in dns records, AND the system has enabled "AAAA" lookups by determining that a global IPv6 address is assigned to a network interface (as per http://technet.microsoft.com/en-us/library/bb727035.aspx)
FYI, IE7 and Firefox 2+ work perfectly out of the box with IPv6 on Vista. Firefox can have IPv6 dns lookups disabled on some platforms.
network.dns.disableIPv6 (bool) can be checked to make sure that it is properly set to false by typing the *special* url of "about:config" in the Firefox url bar.
Good Luck.
Another lost Vista user!
Jeroen Massar on Thursday, 04 December 2008 10:12:16 If you would rather I use some other IPv6 address as a work-around (rather than the bastardized 2002:81a8:102::, let me know and I will test it on Vista and update the wiki as appropriate.
Well first off, why use a 6to4 address there? Does it work with a global address? If the latter works, one can much better assign <tunnel>::2/128 to the interface.
I guess I'll have to dig out my Vista DVD sooner or later and then play around with it, good that the xmas season is soon that should allow for some 'free' time for that sort of stuff.
Another lost Vista user!
Shadow Hawkins on Thursday, 04 December 2008 17:19:37
Jeroen --
The usage of a 6to4 address in Vista was simply that it was thought to work-around the problem (AAAA automatic lookups), and hopefully have minimal conflicts with real-world IPv6 address usage.
The user can not use the tunnel client endpoint address <tunnel>::2/128 on the physical network interface, as this address is assigned to the virtual (tapv9) network interface.
Vista will not let you assign the same address to a different interface (I tried anyway, and it failed with "This object already exists") If the user assigned to the physical interface before aiccu assigned to the virtual interface, the tunnel will not work, as aiccu will not be able to assign the endpoint address to the tapv9 interface.
Of course the user *could* use <tunnel>::dead/128 or some such address on the physical network interface, but I would not recommend that unless you thought it would not cause any other issues. (It does by the way work effectively as the work-around)
Thanks!
Another lost Vista user!
Carmen Sandiego on Thursday, 04 December 2008 14:57:52
Argh. :) Had to turn my m flag back off now. It was causing me to pickup a DHCPv6 address from somewhere on the network that was breaking nslookup from the command line!
I'm really starting to hate the Windows Vista "netsh" command. It's just close enough to Cisco syntax to confuse me on a regular basis and just far enough away to make it really hard to figure out how to do what I want... :-)
Anyways, reinstalled FireFox. Still no IPv6 surfing. Able to ping/traceroute over IPv6, but all my browsing goes out IPv4. Specifying the IPv6 address directly still results in the standard "Firefox can't establish a connection to the server at [2001:200:0:8002:203:47ff:fea5:3085].".
Another lost Vista user!
Jeroen Massar on Thursday, 04 December 2008 15:08:21
Do you have a proxy configured?
Also, what "Firewall" and "anti-virus" software or similar tools do you have?
Lastly, try Wireshark on the IPv4 interface (thus the interface the tunneled packets go over), that should reveal the packets being sent. If you have a recent/SVN version of Wireshark it even properly decodes AYIYA packets and thus everything below it.
Another lost Vista user!
Carmen Sandiego on Thursday, 04 December 2008 15:47:23
No proxy.
Windows firewall and Panda AV (with firewalling features disable, operating in AV mode only).
Not sure what I'm looking for in the wireshark capture (version 1.04). I don't see any AYIYA packets?
Another lost Vista user!
Carmen Sandiego on Thursday, 04 December 2008 15:52:55
Got it, I'm up and running. Panda AV, despite the firewalling features off, was blocking IPv6.
Another lost Vista user!
Jeroen Massar on Thursday, 04 December 2008 15:59:45
This is a very common thing with those "Firewall" tools, one needs to really uninstall them. They tend to 'hook' into winsock and then filter out stuff that way; unfortunately they do this is at install time and not on activate/disable time. And all "unknown" stuff, they just drop.
(There is a small argument pro not being able to fully remove the hook, as it probably needs a 'fresh start' to be able to hook into all applications, then again, the enable/disable feature can easily be built into the hook too... it is thus just bad software design).
Another lost Vista user!
Shadow Hawkins on Thursday, 04 December 2008 17:21:31
Glad it was solved.
I'll add Panda AV to the "bad" list for IPv6 blocking. What version were you using btw ?
Another lost Vista user!
Shadow Hawkins on Thursday, 04 December 2008 10:12:59
Nice to see the Vista stuff documented :)
Just for reference there is a section in the Wiki for AICCU, though it does not cover Vista at this point.
I have added the 'Software' category tag so that it appears in a category, and also a link to it from the 'Aiccu/Installation' section in the wiki.
Another lost Vista user!
Shadow Hawkins on Sunday, 08 February 2009 11:48:06
Thanks David !!!
I tried about 6h to run AICCU on Vista. Finally I found your WIKI link in this thread.
After folowing your instructions --> IT WORKS PERFECT !!!
Keep it up!
Martin Brill
Another lost Vista user!
Carmen Sandiego on Thursday, 04 December 2008 15:58:10
A big thank you to everyone involved in helping me through this! Much appreciated!
Posting is only allowed when you are logged in. |