Linux is stealing the internet from eCS...
Pierre Jelenc
way it came, I haven't even attempted to modify anything.) It plugs into
port #2 of a Netopia router, while the eCS machine uses port #1. It seems
that almost as soon as I do something via the internet on the Linux
machine, it disables completely internet access from the eCS one: http,
ssh, telnet, ftp all time out with no explanation, while things look OK on
the Linux side.
To get eCS back on line, I must not only unplug the cable from the Linux
box, but reboot the router as well.
I have an old Mac laptop that I used to use together with the same eCS
machine and the same router without any problem, so it's not just having
two computers going through the router that causes the trouble. Also, when
the eCS side becomes disabled, it appears to be disabled at the computer
itself, because I cannot even reach the router via its web interface: such
an attempt times out, even though there's no traffic beyond the router.
I have swapped the cables at the router ports (there are 4 ports, and I
tried several combinations of all of them) and rebooted everything but
that does not help.
One peculiar thing is that both computers claim to be at 192.168.1.105
(from ifconfig lan0/eth0) which would point to a competition, but why
would they both get the same address? Why 105 rather than 100 or 101? Why
does Linux always seem to win regardless of whether it is plugged in port
#1 or #2, or whether it is not even plugged in until well after eCS has
already grabbed 192.168.1.105 and been shown to connect without problem?
If this is the cause of the problem (rather than a symptom) I should be
able to force an address via ifconfig, but should I do it on both
machines, and how much should I specify? The syntax of ifconfig has so
many parameters!
Thanks,
Pierre
--
Pierre Jelenc
The Gigometer www.gigometer.com
The NYC Beer Guide www.nycbeer.org
Bob Plyler
What is giving out the DHCP addresses? It sounds like it's messed
up.
You could set one (eCS or Linux) of them to a static address.
Bob Plyler
Jonathan de Boyne Pollard
message should have been "My DHCP server is handing out the same IP
address to two different machines.".
Perhaps your DHCP server cannot tell them apart. Do they erroneously
have the same MAC addresses and names or something?
Perhaps you misconfigured your DHCP server. Did you erroneously tell it
to map two clients to a single static IP address?
If your router is your DHCP server, its WWW configuration interface
(which you should be able to access from the machine whose network
connectivity is working, after all) will tell you what MAC addresses
each of its DHCP clients has.
Pierre Jelenc
>
> What is giving out the DHCP addresses? It sounds like it's messed
> up.
The router, I assume. But it used to work fine with the Mac instead of the
Linux machine.
> You could set one (eCS or Linux) of them to a static address.
Right, but how? ifconfig I assume, but what's needed among all the
possible parameters.
glen herrmannsfeldt
> I have just set up a Linux machine running Ubuntu 10.10/Gnome (that's the
> way it came, I haven't even attempted to modify anything.) It plugs into
> port #2 of a Netopia router, while the eCS machine uses port #1. It seems
> that almost as soon as I do something via the internet on the Linux
> machine, it disables completely internet access from the eCS one: http,
> ssh, telnet, ftp all time out with no explanation, while things look OK on
> the Linux side.
(snip)
> One peculiar thing is that both computers claim to be at 192.168.1.105
> (from ifconfig lan0/eth0) which would point to a competition, but why
> would they both get the same address? Why 105 rather than 100 or 101?
That was about to me my guess. The why is a good question, my
guess is more than one DHCP server, but there are other possibilities.
As someone mentioned, another possibility is more than one with
the same MAC (ethernet) address. With built-in ethernet interfaces,
that isn't so likely, but some years ago there were reports of
NICs with the same address coming from one company. I have seen
the address 00:00:00:00:00:00 on nets before, (so far only one) that
presumably came when someone erased the NVRAM and didn't store
a new address.
Many DHCP servers start with 100 for the last octet, leaving
the lower addresses for static assignment. (Usually .1 for the router.)
Hosts likely to be used as servers should have static addresses.
> Why does Linux always seem to win regardless of whether it
> is plugged in port #1 or #2, or whether it is not even
> plugged in until well after eCS has already grabbed 192.168.1.105
> and been shown to connect without problem?
The later host always wins (until the ARP cache times out).
Actually, it is more complicated, but it is ARP related.
I first saw this booting diskless Suns, accidentally assigning
the same address to two of them. The later one takes over the
connection, leaving the first one stuck.
-- glen
Pierre Jelenc
>
> Perhaps your DHCP server cannot tell them apart. Do they erroneously
> have the same MAC addresses and names or something?
No, they are completely different.
> Perhaps you misconfigured your DHCP server. Did you erroneously tell it
> to map two clients to a single static IP address?
I did not configure anything, I just unplugged the Mac laptop, which had
worked fine for years, and plugged in the Linux machine, then rebooted
everything (including the router, eventually.)
> If your router is your DHCP server, its WWW configuration interface
> (which you should be able to access from the machine whose network
> connectivity is working, after all) will tell you what MAC addresses
> each of its DHCP clients has.
I don't see anything like that in the configuration pages. I go to
http://192.168.1.1/ where I log in, and I get this menu (submenus
expanded):
Wizard Setup
Advanced Configurations
Router Password Change
Internet Security
NAT Applications
Remote Management
LAN Setup
Wireless Setup
WAN Setup
IPSec Setup
Maintenance
System Status
DSL Statistics
LAN Statistics
Wireless Statistics
WAN Statistics
Diagnostics
Firmware Upgrade
Factory Reset
Restart
Logout
Nowhere is there any listing of hardware or assigned IP addresses.
I tried to assign a fixed address with "ifconfig lan0 192.168.1.106" in
tcpexit.cmd so as to leave 105 free, but that ends in failure as well: the
106 address is assigned, but the net is still inaccessible (whether or not
the Linux box is plugged in.)
glen herrmannsfeldt
> I tried to assign a fixed address with "ifconfig lan0 192.168.1.106" in
> tcpexit.cmd so as to leave 105 free, but that ends in failure as well: the
> 106 address is assigned, but the net is still inaccessible (whether or not
> the Linux box is plugged in.)
Try an address like 192.168.1.10
something between 2 and 99 for the last octet.
DHCP assigned usually start at 100.
-- glen
Pierre Jelenc
>
> As someone mentioned, another possibility is more than one with
> the same MAC (ethernet) address.
I have checked, they are different.
> Many DHCP servers start with 100 for the last octet, leaving
> the lower addresses for static assignment. (Usually .1 for the router.)
Yes, and so it does here as well. But why is it assigning 105, then. Not
100 and 101, or perhaps 101 and 102? Or even 105 and 106?
> Hosts likely to be used as servers should have static addresses.
No a concern here.
> The later host always wins (until the ARP cache times out).
Not here: it does not matter which is first, if Linux is plugged in it
takes over, or refuses to yield.
Pierre Jelenc
>
> Try an address like 192.168.1.10
> something between 2 and 99 for the last octet.
> DHCP assigned usually start at 100.
Unfortunately, that does not work either. The address is assigned to lan0
according to ifconfig, but I still can't access the net (I tried http and
ssh). The attempts just time out. I will try to do it in Linux instead
(once I figure out how to do it...) and let eCS use DHCP.
Pierre Jelenc
> glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> >
> > Try an address like 192.168.1.10
> > something between 2 and 99 for the last octet.
> > DHCP assigned usually start at 100.
>
> Unfortunately, that does not work either. The address is assigned to lan0
> according to ifconfig, but I still can't access the net (I tried http and
> ssh). The attempts just time out. I will try to do it in Linux instead
> (once I figure out how to do it...) and let eCS use DHCP.
Bingo! I assigned 192.168.1.10 to eth0 in the Linux machine, then rebooted
the eCS one with its DHCP default: it again got 192.168.1.105 assigned to
lan0 but now there's no conflict and both computers connect simultaneously
to the outside word!
So, it was a DHCP mistake/bug that caused the same address to be assigned
to two different machines, with Linux grabbing priority somehow regardless
of the order of assignments.
Since this is all magic to me, I doubt that I can dig any further by
myself, but if anyone wants me to test things, just let me know: these two
computers will stay side by side in this configuration for a while.
Thanks to all.
glen herrmannsfeldt
>> > Try an address like 192.168.1.10
>> > something between 2 and 99 for the last octet.
>> > DHCP assigned usually start at 100.
>> Unfortunately, that does not work either. The address is assigned to lan0
>> according to ifconfig, but I still can't access the net (I tried http and
>> ssh). The attempts just time out. I will try to do it in Linux instead
>> (once I figure out how to do it...) and let eCS use DHCP.
> Bingo! I assigned 192.168.1.10 to eth0 in the Linux machine, then rebooted
> the eCS one with its DHCP default: it again got 192.168.1.105 assigned to
> lan0 but now there's no conflict and both computers connect simultaneously
> to the outside word!
DHCP also assigns a default route and DNS server address.
If you configure a static address (which you should be able to do
with a GUI instead of editing a file), you should also configure those.
The default route is the router, most likely 192.168.1.1.
I am not so sure about DNS. Most likely the DNS server supplied
to your router by DHCP from your ISP.
-- glen
Pierre Jelenc
>
> DHCP also assigns a default route and DNS server address.
> If you configure a static address (which you should be able to do
> with a GUI instead of editing a file), you should also configure those.
Yes, I did that via a GUI form that gathers IP address, router, DNS
servers, and "network mask". The latter was a bit strange: The DHCP-
assigned network mask on the eCS side is 0xffffff00 while on the Linux
side it got automattically filled in with decimal 24 as soon as I typed in
the IP address. I left it as is and it works, but I can't figure out what
that 24 is, compared to 0xffffff00.
Trevor Hemsley
Jelenc) wrote:
> I can't figure out what
> that 24 is, compared to 0xffffff00.
The same thing: /24 is the same as 255.255.255.0
--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
Pierre Jelenc
>
> The same thing: /24 is the same as 255.255.255.0
But 24 what? /24 is abundantly used as a qualifier in subnet discussions,
but I haven't been able to figure out what it means.
Peter Flass
Probably something under LAN setup. You should be able to configure
DHCP (or not) and/or DDNS. What address/options did you assign when you
did the OS/2 TCP/IP configuration?
You should run an ethernet monitor in promiscuous mode on Linux and log
all the packets. This should point you in the right direction. I
assume this LAN is only these two or three machines, so you're not
talking huge volumes of traffic.
Peter Flass
>
> DHCP assigned usually start at 100.
>
That may be convention, but my router lets me set up anything I want. I
think I started at 10.
James Moe
>
> I don't see anything like that in the configuration pages. I go to
> http://192.168.1.1/ where I log in, and I get this menu (submenus
> expanded):
> Wizard Setup
> Advanced Configurations
> Router Password Change
> Restart
> Logout
>
> Nowhere is there any listing of hardware or assigned IP addresses.
>
all. If there is a DHCP service on your network, it is NOT located in
the router.
> I tried to assign a fixed address with "ifconfig lan0 192.168.1.106" in
> tcpexit.cmd so as to leave 105 free, but that ends in failure as well: the
> 106 address is assigned, but the net is still inaccessible (whether or not
> the Linux box is plugged in.)
>
The place to change it is in <c:\mptn\bin\setup.cmd>. Replace the dhcp
line with the ifconfig line.
Or use the TPCIP GUI interface.
In either case adding "ifconfig ..." to <tcpexit.cmd> is worthless at best.
--
James Moe
jmm-list at sohnen-moe dot com
Allan
> Trevor Hemsley <Trevor....@mytrousers.ntlworld.com> writes:
> >
> > The same thing: /24 is the same as 255.255.255.0
>
> But 24 what?
Bits
/24 is abundantly used as a qualifier in subnet discussions,
Yes, it is a standard notation.
225.225.225.0 = 8bits+8bits+8bits (=24 bits) fixed and 0=8bits free
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Trevor Hemsley
Jelenc) wrote:
> Trevor Hemsley <Trevor....@mytrousers.ntlworld.com> writes:
> >
> > The same thing: /24 is the same as 255.255.255.0
>
> But 24 what? /24 is abundantly used as a qualifier in subnet discussions,
> but I haven't been able to figure out what it means.
24 bits in the subnet mask. A /32 has 32 bits so is the same as 255.255.255.255.
It's just a different convention for expressing the same thing.
glen herrmannsfeldt
Yes, but usually 100 is the default, and most people don't
change it, so it is usually 100. Also, the OP seemed to have
numbers in that range.
Many have limit on the total DHCP range that is low, but usually
enough for home use. Most don't have more than 100 computers at home.
-- glen
Jonathan de Boyne Pollard
>> it to map two clients to a single static IP address?
>>
> I did not configure anything, I just unplugged the Mac laptop, which
> had worked fine for years, and plugged in the Linux machine, then
> rebooted everything (including the router, eventually.)
>
You probably *did* configure things, back when you bought your router
and first used it.
>> If your router is your DHCP server, its WWW configuration interface
>> (which you should be able to access from the machine whose network
>> connectivity is working, after all) will tell you what MAC addresses
>> each of its DHCP clients has.
>>
> I don't see anything like that in the configuration pages.
>
You don't tell us what router it is, but if it's anything like what I
think it is, you didn't look far enough for the DHCP settings. They're
under "LAN Setup" on that very menu. On an "IP and Mac Address Binding"
page of that, you'll see what static DHCP leases you've configured but
now don't remember; and on a "DHCP client" page you'll see all of the
currently assigned leases.
Pierre Jelenc
>
> Probably something under LAN setup. You should be able to configure
> DHCP (or not) and/or DDNS. What address/options did you assign when you
> did the OS/2 TCP/IP configuration?
Here are the LAN and WAN setup forms (I had to take screen shots, since
they are form input fields):
http://www.pierrejelenc.com/lansetup.gif
http://www.pierrejelenc.com/wansetup.gif
> You should run an ethernet monitor in promiscuous mode on Linux and log
> all the packets. This should point you in the right direction. I
> assume this LAN is only these two or three machines, so you're not
> talking huge volumes of traffic.
Two machines. I'll have to figure out the ethernet monitor business.
Pierre Jelenc
>
> Nor is there any indication that the router provides a DHCP service at
> all. If there is a DHCP service on your network, it is NOT located in
> the router.
I think it is; these are repeats of the screen shots I just posted in
another reply:
http://www.pierrejelenc.com/lansetup.gif
http://www.pierrejelenc.com/wansetup.gif
> The place to change it is in <c:\mptn\bin\setup.cmd>. Replace the dhcp
> line with the ifconfig line.
Ah, thanks. Will try.
Pierre Jelenc
> >> it to map two clients to a single static IP address?
> >>
> > I did not configure anything, I just unplugged the Mac laptop, which
> > had worked fine for years, and plugged in the Linux machine, then
> > rebooted everything (including the router, eventually.)
> >
>
> You probably *did* configure things, back when you bought your router
> and first used it.
Oh, right, I misunderstood. I had not re-configured anything between the
Mac and the Linux machines, but of course I did set up the router
originally.
> You don't tell us what router it is, but if it's anything like what I
> think it is, you didn't look far enough for the DHCP settings. They're
> under "LAN Setup" on that very menu.
Indeed, it's right there under LAN setup, see the screenshots in another
reply. I totally missed it.
Paul Ratcliffe
>> Probably something under LAN setup. You should be able to configure
>> DHCP (or not) and/or DDNS. What address/options did you assign when you
>> did the OS/2 TCP/IP configuration?
>
> Here are the LAN and WAN setup forms (I had to take screen shots, since
> they are form input fields):
>
> http://www.pierrejelenc.com/lansetup.gif
An hour is rather a short time for a lease. I'd make it at least a day,
not that it has any bearing on your problem.
You should find a list of DHCP devices in use on one of the router's
pages, probably under Maintenance, LAN statistics or similar.
Alex Taylor
> I tried to assign a fixed address with "ifconfig lan0 192.168.1.106" in
> tcpexit.cmd so as to leave 105 free, but that ends in failure as well:
I guess you already got it working another way, but regarding this...
If you're not familiar with how to hack the configuration scripts
directly, why on Earth aren't you using the TCP/IP configuration GUI?
Run "tcpcfg2" from a command prompt. The first three pages are all
you need to change your IP address to static:
Network: Select the "manually" radiobutton; fill in the IP address
field with your desired address, and the Subnet mask field
with 255.255.255.0 (and ignore the "Advanced" tabs).
Routing: Choose "Add", select "Route type" "Default" and enter
a destination IP address of 192.168.1.1 (metric count 0).
Host Names: Make sure 192.168.1.1 also appears in the Name Server list.
--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00
Please take off hat when replying.
Ilya Zakharevich
> If you're not familiar with how to hack the configuration scripts
> directly, why on Earth aren't you using the TCP/IP configuration GUI?
>
> Run "tcpcfg2" from a command prompt. The first three pages are all
> you need to change your IP address to static:
> Network: Select the "manually" radiobutton; fill in the IP address
> field with your desired address, and the Subnet mask field
> with 255.255.255.0 (and ignore the "Advanced" tabs).
> Routing: Choose "Add", select "Route type" "Default" and enter
> a destination IP address of 192.168.1.1 (metric count 0).
> Host Names: Make sure 192.168.1.1 also appears in the Name Server list.
BTW, is there a simple way to add "extra, manual" nameserver entries
to the entry written by DHCP? DNS in my AirLink101 router (one
assigned automatically via DHCP) is unreliable under high router
traffic, and I'd like to have fallbacks...
Manually appending entries to /tcpip/etc/hosts works, but it is
eventually overwritten by DHCP.
Thanks,
Ilya
glen herrmannsfeldt
(snip)
> BTW, is there a simple way to add "extra, manual" nameserver entries
> to the entry written by DHCP? DNS in my AirLink101 router (one
> assigned automatically via DHCP) is unreliable under high router
> traffic, and I'd like to have fallbacks...
Some allow you to configure them in the DHCP server.
Then you only have to do it once.
-- glen
Ilya Zakharevich
> Ilya Zakharevich <nospam...@ilyaz.org> wrote:
> (snip)
>
>> BTW, is there a simple way to add "extra, manual" nameserver entries
>> to the entry written by DHCP? DNS in my AirLink101 router (one
>> assigned automatically via DHCP) is unreliable under high router
>> traffic, and I'd like to have fallbacks...
>
> Some allow you to configure them in the DHCP server.
Thanks; I have never seen it, so did not think about checking for
this. Unfortunately, this does not work with this router (the only
DNS-option is Enable/Disable DNS passthru)...
Yours,
Ilya
Marty
clients tend to try to re-acquire the same address that they had
previously. They will explicitly request it from the DHCP server, and
it's the server's responsibility to decide if it is available or not.
Perhaps this, coupled with your low lease time resulted in your problem.
Your eCS lease expired, but the eCS DHCP client didn't renew it in
time (probably assumed a more sane renewal time), then the Linux machine
popped on and requested the same address (which was the address it had
held previously?). Usually explicitly releasing the DHCP lease will
undo these kinds of SNAFUs (dhcpcd -k on Linux). You can check
/var/logs/messages on Linux to get some visibility into what the DHCP
client is doing.
On 03/27/2011 11:23 AM, Pierre Jelenc wrote:
> Peter Flass<Peter...@Yahoo.com> writes:
>>
>> Probably something under LAN setup. You should be able to configure
>> DHCP (or not) and/or DDNS. What address/options did you assign when you
>> did the OS/2 TCP/IP configuration?
>
> Here are the LAN and WAN setup forms (I had to take screen shots, since
> they are form input fields):
>
> http://www.pierrejelenc.com/lansetup.gif
> http://www.pierrejelenc.com/wansetup.gif
>
>> You should run an ethernet monitor in promiscuous mode on Linux and log
>> all the packets. This should point you in the right direction. I
>> assume this LAN is only these two or three machines, so you're not
>> talking huge volumes of traffic.
>
> Two machines. I'll have to figure out the ethernet monitor business.
--
Reverse the parts of the e-mail address to reply by mail.
Dave Saville
<nospam...@ilyaz.org> wrote:
> Thanks; I have never seen it, so did not think about checking for
> this. Unfortunately, this does not work with this router (the only
> DNS-option is Enable/Disable DNS passthru)...
Ilya
In that case I would run my own copy of bind locally. As I do, but not
for that reason.
--
Regards
Dave Saville
KO Myung-Hun
How about using kipcfg ?
It has a feature allocating IP only from DHCP servers.
Instead, you should configure a default gateway using route.exe and DNS
servers editing %ETC%\RESOLV2, manually.
--
KO Myung-Hun
Using Mozilla SeaMonkey 2.0.11
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1GHz with 512 MB RAM
Korean OS/2 User Community : http://www.ecomstation.co.kr
Pierre Jelenc
>
> If you're not familiar with how to hack the configuration scripts
> directly, why on Earth aren't you using the TCP/IP configuration GUI?
I had forgotten it existed...
Ilya Zakharevich
>> Manually appending entries to /tcpip/etc/hosts works, but it is
>> eventually overwritten by DHCP.
>
> How about using kipcfg ?
>
> It has a feature allocating IP only from DHCP servers.
>
> Instead, you should configure a default gateway using route.exe and DNS
> servers editing %ETC%\RESOLV2, manually.
Do not see how this would differ from disabling DHCP completely - I
have no way to FIND these values without DHCP, right? And I need DHCP
for laptops to work transparently...
Is not there a way to run a script when a new lease is allocated?
Thanks,
Ilya
Jonathan de Boyne Pollard
> to the entry written by DHCP? DNS in my AirLink101 router (one
> assigned automatically via DHCP) is unreliable under high router
> traffic, and I'd like to have fallbacks...
>
> Manually appending entries to /tcpip/etc/hosts works, but it is
> eventually overwritten by DHCP.
>
That's a confused question. Entries in %ETC%\HOSTS have nothing
whatsoever to do with nameservers, and the DHCP client does not
overwrite %ETC%\HOSTS.
When it comes to forcing the use of particular DNS servers, it depends
from the DHCP client. It's the client that decides what to do with an
IP lease that says "Your IP address is 192.68.100.15, and by the way the
proxy DNS servers that you can talk to are at 192.168.1.1 and
192.168.1.2.". The IBM DHCP client in IBM OS/2 writes out a fresh
%ETC%\RESOLV2 whenever it is assigned a fresh lease, essentially saying
to the DNS client library to use the proxy DNS server that the DHCP
client was just told about in a lease. This is configurable. One
simply adjusts %ETC%\DHCPCD.CFG to tell the IBM DHCP client to ignore
("reject") option 6, and it stops overwriting %ETC%\RESOLV2.
Then of course one simply adjusts %ETC%\RESOLV2 manually to list
whatever proxy DNS server one wants. I have it telling the DNS client
library to talk to a proxy DNS server running on the machine itself on
my machine. (It's DNSFCPD, from my Internet Utilities, listening on
127.0.0.4.)
Jonathan de Boyne Pollard
>
That's exactly what IBM's DHCP client *already does*. That's,
fundamentally, how it works. It runs a script (sometimes a default,
built-in script) for each option received.
KO Myung-Hun
Ilya Zakharevich wrote:
> On 2011-03-28, KO Myung-Hun <ko...@chollian.net> wrote:
>>> Manually appending entries to /tcpip/etc/hosts works, but it is
>>> eventually overwritten by DHCP.
>>
>> How about using kipcfg ?
>>
>> It has a feature allocating IP only from DHCP servers.
>>
>> Instead, you should configure a default gateway using route.exe and DNS
>> servers editing %ETC%\RESOLV2, manually.
>
> Do not see how this would differ from disabling DHCP completely - I
> have no way to FIND these values without DHCP, right? And I need DHCP
> for laptops to work transparently...
>
No, it's different. At least, you can get IP address.
And you said that you wanted to add a DNS server manually. If so, you
already know the address of your DNS server. Why do you want to get a
DNS server address from a DHCP server ?
One problematic thing is a default gateway.
If you don't use a laptop on various places, you can get the address of
a default gateway from a DHCP server. and then you can set it manually.
But, you should often use it on different places, you should use another
way as Jonathan said.
> Is not there a way to run a script when a new lease is allocated?
>
Jonathan said about that.
Ilya Zakharevich
>>> How about using kipcfg ?
>>>
>>> It has a feature allocating IP only from DHCP servers.
>>>
>>> Instead, you should configure a default gateway using route.exe and DNS
>>> servers editing %ETC%\RESOLV2, manually.
>>
>> Do not see how this would differ from disabling DHCP completely - I
>> have no way to FIND these values without DHCP, right? And I need DHCP
>> for laptops to work transparently...
>>
>
> No, it's different. At least, you can get IP address.
>
> And you said that you wanted to add a DNS server manually. If so, you
> already know the address of your DNS server. Why do you want to get a
> DNS server address from a DHCP server ?
The keyword is to "add", not "replace". No, I do not know DNS server
in advance. But I know one which MAY work if the principal one fails
(especially given that that failure is frequent on one location only.)
>> Is not there a way to run a script when a new lease is allocated?
> Jonathan said about that.
I did not notice any answer. Or maybe I stated the question wrong.
Ilya
Ilya Zakharevich
>> BTW, is there a simple way to add "extra, manual" nameserver entries
>> to the entry written by DHCP? DNS in my AirLink101 router (one
>> assigned automatically via DHCP) is unreliable under high router
>> traffic, and I'd like to have fallbacks...
>>
>> Manually appending entries to /tcpip/etc/hosts works, but it is
>> eventually overwritten by DHCP.
> That's a confused question. Entries in %ETC%\HOSTS have nothing
> whatsoever to do with nameservers, and the DHCP client does not
> overwrite %ETC%\HOSTS.
Thanks for catching this. I, of course, meant resolv2, not hosts.
> client was just told about in a lease. This is configurable. One
> simply adjusts %ETC%\DHCPCD.CFG to tell the IBM DHCP client to ignore
> ("reject") option 6, and it stops overwriting %ETC%\RESOLV2.
As I said, I do not want this. I WANT the nameserver to be DHCP'ed.
But I want to add BACKUP servers to the end of resolv2 AS WELL.
Ilya
Ilya Zakharevich
The answer straight from the "literal reading" department... OK, let
me restate the question:
How do I force IBM's DHCP client to run a script c:\on_dhcp.cmd AFTER
the lease having been assigned/renewed?
Thanks,
Ilya
Ilya Zakharevich
> On Mon, 28 Mar 2011 06:36:42 UTC, Ilya Zakharevich
><nospam...@ilyaz.org> wrote:
>
>> Thanks; I have never seen it, so did not think about checking for
>> this. Unfortunately, this does not work with this router (the only
>> DNS-option is Enable/Disable DNS passthru)...
> In that case I would run my own copy of bind locally. As I do, but not
> for that reason.
This would be chicken and egg problem. How would this local copy find
the address of upstream server?
Ilya
James Moe
>>
>> Nor is there any indication that the router provides a DHCP service at
>> all. If there is a DHCP service on your network, it is NOT located in
>> the router.
>
> I think it is; these are repeats of the screen shots I just posted in
> another reply:
> http://www.pierrejelenc.com/lansetup.gif
> http://www.pierrejelenc.com/wansetup.gif
>
Jonathan de Boyne Pollard
> the address of upstream server?
>
There *is no* upstream server. You have an errneous concept of how DNS
works. People sometimes think, as you are, that there's a chain of
servers somehow, each passing things along to the next. There isn't.
DNS works like HTTP. There's your applications, with DNS client
libraries embedded into them, the proxy DNS server that they talk to,
and the content DNS servers out on the rest of Internet that the proxy
DNS server talks to. The DNS client libraries in the applications are
told where the resolving proxy DNS server is, through the likes of
/etc/resolv.conf, %ETC%\RESOLV2, the DNS_PROXY_IP_ADDRESS environment
variable, or Registry values (depending from the particular DNS client
library employed). The resolving proxy DNS server is told where the
content DNS servers for the root domain name, ".", are. And that's *it*.
http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/iu/commands/dnsrcpd.html
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-query-resolution.html
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-updating-resolving-proxy-root-list.html#IU
Jonathan de Boyne Pollard
>
That's because you don't understand what you are doing and don't
understand DNS.
> I WANT the nameserver to be DHCP'ed. But I want to add BACKUP servers
> to the end of resolv2 AS WELL.
>
That's a pointless exercise. If you are running a local proxy DNS
server, you might as well have your DNS clients query it all of the
time, and ignore entirely what your DHCP server points to. Make it a
forwarding proxy DNS server rather than a resolving proxy DNS server if
you like. (It's fairly easy to plumb a script into IBM's DHCP client
that will try to update the back end of a forwarding proxy DNS server.
The hard part is not the plumbing in to the DHCP client but the actual
updating, especially if one uses a proxy DNS server with a complex
configuration file that has to be parsed and rewritten.) But it's
pointless and wasteful to use a proxy that's on another machine, and
(you state) unreliable, when one has an always-running caching proxy
that's on the local machine itself. Always use the always-there local
proxy DNS server that you don't need to go across the LAN to get to.
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-obtaining-proxy-service.html
glen herrmannsfeldt
>> This would be chicken and egg problem. How would this local copy find
>> the address of upstream server?
> There *is no* upstream server. You have an errneous concept of how DNS
> works. People sometimes think, as you are, that there's a chain of
> servers somehow, each passing things along to the next.
Well, it isn't so far off. It is usual for an ISP to run a
DNS server for use by its customers. That one will be nice
and close, and should be able to reply fast.
It does seem that DNS is sometimes time sensitive, and if
you point the resolver at some far away server then it might
time out before the replies arrive.
Anyway, the ISP server will at least cache, such that repeater
requests for the same sight, from the same or different customers,
don't have to go do the whole search back to the root.
> There isn't.
> DNS works like HTTP. There's your applications, with DNS client
> libraries embedded into them, the proxy DNS server that they talk to,
> and the content DNS servers out on the rest of Internet that the proxy
> DNS server talks to. The DNS client libraries in the applications are
> told where the resolving proxy DNS server is, through the likes of
> /etc/resolv.conf, %ETC%\RESOLV2, the DNS_PROXY_IP_ADDRESS environment
> variable, or Registry values (depending from the particular DNS client
> library employed). The resolving proxy DNS server is told where the
> content DNS servers for the root domain name, ".", are. And that's *it*.
Yes. Normally that will be the ISP's DNS server, and most often
that is assigned through DHCP.
While it isn't nice to statically configure an IP address assigned
to you by the ISP with DHCP, it isn't so bad to do that with DNS.
If the ISP moves the DNS server, then your lookups will fail.
Then you fix it.
-- glen
Allan
> As I said, I do not want this. I WANT the nameserver to be DHCP'ed.
> But I want to add BACKUP servers to the end of resolv2 AS WELL.
Get the ISC DHCP client from:
http://os2ports.smedley.info/index.php?page=isc-dhcp-client
It has all the features you want - and a lot more :-)
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Jonathan de Boyne Pollard
>> DNS works. People sometimes think, as you are, that there's a chain
>> of servers somehow, each passing things along to the next.
>>
> Well, it isn't so far off.
>
It really is. It's a pernicious misconception that I've seen lead to
error so many times over the past many years. It's the idea that DNS
operates by relay, and it leads to all sorts of fallacies, not the least
of which is the idea that one still has to somehow use someone else's
resolving proxy DNS server even when one is running one's own on one's
own machine. DNS does not operate by relay. It's not SMTP.
>> There isn't. DNS works like HTTP. There's your applications, with
>> DNS client libraries embedded into them, the proxy DNS server that
>> they talk to, and the content DNS servers out on the rest of Internet
>> that the proxy DNS server talks to. The DNS client libraries in the
>> applications are told where the resolving proxy DNS server is,
>> through the likes of /etc/resolv.conf, %ETC%\RESOLV2, the
>> DNS_PROXY_IP_ADDRESS environment variable, or Registry values
>> (depending from the particular DNS client library employed). The
>> resolving proxy DNS server is told where the content DNS servers for
>> the root domain name, ".", are. And that's *it*.
>>
> Yes. Normally that will be the ISP's DNS server, and most often that
> is assigned through DHCP.
>
No. *Normally* it will be one's own proxy DNS server. In years gone
past, it was the accepted norm that one ran a proxy DNS server onesself,
on one's own machines. It's only with the advent of the
Internet-connected DOS/Windows/OS/2 PC that that became otherwise. M.
Zakharevich is, ironically, an example of how that has come full
circle. He is using his own proxy DNS server, once again running on a
machine of his own. That machine is his router. The only real problem
is that it's apparently unreliable when LAN/WAN traffic levels are high,
the obvious answer to which is to run a proxy DNS server *locally*, that
isn't susceptible to LAN congestion. And once one is doing that, one
can decide to *completely ignore* DNS service provided by the router, or
even by the ISP. In the conventional case, of a resolving proxy rather
than a forwarding proxy, one indeed does precisely that.
> While it isn't nice to statically configure an IP address assigned to
> you by the ISP with DHCP, it isn't so bad to do that with DNS.
>
It's even nicer to just run one's own proxy DNS server. One is, after
all, running a multitasking operating system that is easily capable of
such a feat. (-:
glen herrmannsfeldt
> No. *Normally* it will be one's own proxy DNS server. In years gone
> past, it was the accepted norm that one ran a proxy DNS server onesself,
> on one's own machines.
As I understand it, or as I did when I configure my local DNS server,
the preferred way is with the "forwarders" directive that tells the
DNS server to request from the ISPs server. That reduces traffic
through the internet. Well, it might be that the long distance
links are enough faster now that one doesn't worry about such things.
Some years ago, when I configured my home server, that was the way
it was usually done.
> It's only with the advent of the
> Internet-connected DOS/Windows/OS/2 PC that that became otherwise. M.
> Zakharevich is, ironically, an example of how that has come full
> circle. He is using his own proxy DNS server, once again running on a
> machine of his own. That machine is his router.
I have been working with IP since about 1988, though actually
running DNS servers since 1990. (When I first configured one for
the lab I was working in.) The net was slower then, and some things
were done differently to account for that.
> The only real problem
> is that it's apparently unreliable when LAN/WAN traffic levels are high,
> the obvious answer to which is to run a proxy DNS server *locally*, that
> isn't susceptible to LAN congestion. And once one is doing that, one
> can decide to *completely ignore* DNS service provided by the router, or
> even by the ISP. In the conventional case, of a resolving proxy rather
> than a forwarding proxy, one indeed does precisely that.
>> While it isn't nice to statically configure an IP address assigned to
>> you by the ISP with DHCP, it isn't so bad to do that with DNS.
> It's even nicer to just run one's own proxy DNS server. One is, after
> all, running a multitasking operating system that is easily capable of
> such a feat. (-:
-- glen
Ilya Zakharevich
> It's even nicer to just run one's own proxy DNS server. One is, after
> all, running a multitasking operating system that is easily capable of
> such a feat. (-:
Not in my experience. OS/2 scheduler has some bugs which make task
switch unreliable (w.r.t. quickness) when long-running CPU-intensive
tasks without I/O are present. And if one runs FF/Mozilla/etc, all
hope of timely dispatched jobs is gone.
I prefer using the router's DNS when it works. When it does not, I
prefer to use upstream's (static) addresses of DNS servers.
Ilya
Ilya Zakharevich
> On Tue, 29 Mar 2011 17:58:08 UTC, Ilya Zakharevich <nospam...@ilyaz.org> wrote:
>
>> As I said, I do not want this. I WANT the nameserver to be DHCP'ed.
>> But I want to add BACKUP servers to the end of resolv2 AS WELL.
>
> Get the ISC DHCP client from:
>
> http://os2ports.smedley.info/index.php?page=isc-dhcp-client
>
> It has all the features you want - and a lot more :-)
Thanks, >>TODO. However, I still would like to know whether
"running a script when needed" is possible with the IBM's one.
Thanks,
Ilya
Allan
I remember I tried that many years ago, but I could not make it work.
ISC client do have that feature.
We designed the port as a drop-in replacement for IBM's old client,
using the same filenames and commands.
Only thing missing (yet) is the GUI monitor.
KO Myung-Hun
Ilya Zakharevich wrote:
> On 2011-03-29, KO Myung-Hun <ko...@chollian.net> wrote:
>>>> How about using kipcfg ?
>>>>
>>>> It has a feature allocating IP only from DHCP servers.
>>>>
>>>> Instead, you should configure a default gateway using route.exe and DNS
>>>> servers editing %ETC%\RESOLV2, manually.
>>>
>>> Do not see how this would differ from disabling DHCP completely - I
>>> have no way to FIND these values without DHCP, right? And I need DHCP
>>> for laptops to work transparently...
>>>
>>
>> No, it's different. At least, you can get IP address.
>>
>> And you said that you wanted to add a DNS server manually. If so, you
> ^^^
>> already know the address of your DNS server. Why do you want to get a
>> DNS server address from a DHCP server ?
>
> The keyword is to "add", not "replace". No, I do not know DNS server
> in advance. But I know one which MAY work if the principal one fails
> (especially given that that failure is frequent on one location only.)
Hmm...
What I said is the way to ADD a DNS server.
Anyway, the way seems not to be what you want.
Finally, you can get the IP address of the DNS server looking in
%ETC%\resolve2 when your dhcp client configured your NIC correctly.
Jonathan de Boyne Pollard
>> all, running a multitasking operating system that is easily capable
>> of such a feat. (-:
>>
> Not in my experience. OS/2 scheduler has some bugs which make task
> switch unreliable (w.r.t. quickness) when long-running CPU-intensive
> tasks without I/O are present.
>
A proxy DNS server performs I/O. How else do you think that it
communicates with the clients that query it? Indeed, how else do you
think that it's back-end communicates with the content DNS servers that
it queries? Kiddo, I've been running a local proxy DNS server on OS/2
for roughly a decade at this point. It's not exactly an onerous
exercise. (Indeed, I actually run two, a forwarding one that forwards
to a resolving one; so I'm doubling whatever overheads there might be
for the normal case.) And I'm not exactly alone in doing this, as the
many other people whose answer to such woes are typically "You can
always run BIND locally, like we do." will attest. Stop clutching at
made-up straws for trying to continue doing things the daft way. You
have traffic congestion problems; so run a (forwarding) proxy DNS server
locally to reduce them and direct your DNS client libraries to use it.
It's the simple and well-known answer to a widely experienced problem.
It's a Frequently Given Answer. It's also page 266 of the "Cricket
Book" (4th edition).
Jonathan de Boyne Pollard
> needed" is possible with the IBM's one.
>
How many times do I have to repeat myself before what *I already told
you* sinks in? That's exactly what IBM's DHCP client *already does*.
That's, fundamentally, how it works. It runs a script (sometimes a
default, built-in script) for each option received. What do you think
DHCPIBM.CMD is?
Jonathan de Boyne Pollard
>> past, it was the accepted norm that one ran a proxy DNS server
>> onesself, on one's own machines.
>>
> As I understand it, or as I did when I configure my local DNS server,
> the preferred way is with the "forwarders" directive that tells the
> DNS server to request from the ISPs server.
>
forums at least. Some people will decry that a forwarding proxy DNS
server is the "right" thing to do. Some will say that one should always
do query resolution onesself. Oftentimes this is simple repetition of
received wisdom, passed along by word of mouth. Sometimes it's an
incorrect inference from the fact that DHCP hands out an option. The
option is there, goes the incorrect inference, therefore it *must* be
used. Sometimes it's an incorrect elevation of an ISP's customer
documentation to the level of Holy Scripture. ("My ISP says that's
where the DNS servers are, so that's what I must do." No, kiddo. Your
ISP is offering you this service. It's your choice, and optional,
whether you use it.) The simple truth, that I've been telling people
for at least 11 years, and probably longer, is that one picks which
according to what one's circumstances and one's goals are. See the
Frequently Given Answer.
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-server-roles.html#ChoosingProxy
It's a complex decision, to which there is no single universal answer.
One has to weight the various factors (several of which the FGA lays
out), which pull in different directions, according to what one onesself
wants. As I said to M. Zakharevich just now, he can locally run a
forwarding proxy, rather than a resolving proxy, if he so chooses. But
the idea of *falling back* from someone else's remote proxy DNS server
to a local proxy DNS server on one's own machine (be that a forwarding
proxy or a resolving proxy) is just downright foolish. The local proxy
is going to be always there, closer to the DNS client libraries than
anything out on the LAN (let alone out on the WAN), and not subject to
LAN congestion at the front end, so always use it. Set it up to forward
at the back end if one likes, and one's personal weighting of the
several factors involved is that a forwarding proxy is better than a
resolving proxy, but always use it.
glen herrmannsfeldt
>>> No. *Normally* it will be one's own proxy DNS server. In years gone
>>> past, it was the accepted norm that one ran a proxy DNS server
>>> onesself, on one's own machines.
>> As I understand it, or as I did when I configure my local DNS server,
>> the preferred way is with the "forwarders" directive that tells the
>> DNS server to request from the ISPs server.
> There's some debate on this, amongst people in Internet discussion
> forums at least. Some people will decry that a forwarding proxy DNS
> server is the "right" thing to do. Some will say that one should always
> do query resolution onesself. Oftentimes this is simple repetition of
> received wisdom, passed along by word of mouth.
I believe that one reason for "forwarders" was to reduce
the load on the root servers. Is that not a problem?
Of course the fraction of users that know how to configure a local
proxy server is small enough that it might not make a difference
(for home use, anyway).
I have been running mine long enough that the recommendations
could have changed by now.
-- glen
Ilya Zakharevich
>> It's even nicer to just run one's own proxy DNS server. One is, after
>>> all, running a multitasking operating system that is easily capable
>>> of such a feat. (-:
>>>
>> Not in my experience. OS/2 scheduler has some bugs which make task
>> switch unreliable (w.r.t. quickness) when long-running CPU-intensive
>> tasks without I/O are present.
> A proxy DNS server performs I/O.
No it does not - if the scheduler does not give it a timeslice. Which
would happen (for up to several seconds) if such a bug hits.
> How else do you think that it
> communicates with the clients that query it? Indeed, how else do you
> think that it's back-end communicates with the content DNS servers that
> it queries? Kiddo, I've been running a local proxy DNS server on OS/2
> for roughly a decade at this point. It's not exactly an onerous
> exercise. (Indeed, I actually run two, a forwarding one that forwards
> to a resolving one; so I'm doubling whatever overheads there might be
> for the normal case.) And I'm not exactly alone in doing this, as the
> many other people whose answer to such woes are typically "You can
> always run BIND locally, like we do." will attest. Stop clutching at
> made-up straws for trying to continue doing things the daft way. You
> have traffic congestion problems; so run a (forwarding) proxy DNS server
> locally to reduce them and direct your DNS client libraries to use it.
> It's the simple and well-known answer to a widely experienced problem.
> It's a Frequently Given Answer. It's also page 266 of the "Cricket
> Book" (4th edition).
All I see is that you think you are smarter than me. This is off-topic. ;-)
Ilya
Ilya Zakharevich
>>>>> Instead, you should configure a default gateway using route.exe and DNS
>>>>> servers editing %ETC%\RESOLV2, manually.
>>>>
>>>> Do not see how this would differ from disabling DHCP completely - I
>>>> have no way to FIND these values without DHCP, right? And I need DHCP
>>>> for laptops to work transparently...
>>>>
>>>
>>> No, it's different. At least, you can get IP address.
>>>
>>> And you said that you wanted to add a DNS server manually. If so, you
>> ^^^
>>> already know the address of your DNS server. Why do you want to get a
>>> DNS server address from a DHCP server ?
>>
>> The keyword is to "add", not "replace". No, I do not know DNS server
>> in advance. But I know one which MAY work if the principal one fails
>> (especially given that that failure is frequent on one location only.)
> What I said is the way to ADD a DNS server.
Then I misunderstood you (and still do). You said "editing
%ETC%\RESOLV2" - and this AFAIK means disabling "update %ETC%\RESOLV2
via DHCP". I DO want it to be updated via DHCP; all I want is to add
something else at the end AFTER this update.
> Anyway, the way seems not to be what you want.
I just might have missed what you mean.
> Finally, you can get the IP address of the DNS server looking in
> %ETC%\resolve2 when your dhcp client configured your NIC correctly.
I know this; as I said, I can fix things manually without any
problem. But how is it relevant? I can easily append something
to %ETC%\RESOLV2 - but I must know WHEN I should do this. Hence my
question about "How to run a script after the lease is
renewed/acquired.
Thanks,
Ilya
Ilya Zakharevich
I do not know, you tell me please. Or, better, if you already know the
answer, just explain what should one do so that c:\foo.cmd is run
after the lease is updated/acquired.
Thanks,
Ilya
Jonathan de Boyne Pollard
> the root servers. Is that not a problem?
>
own resolving proxy DNS server, or whether you pass the query resolution
grunt work along to a second party, with a forwarding proxy DNS server,
makes precious little difference to the "." content DNS server traffic.
*Someone*, whether it's you or the second party, ends up performing
query resolution, which involves starting at the roots. The reduction
of load involves *caching*, in a resolving proxy DNS server, and is far
more determined by what the cache hit and cache miss patterns are than
by exactly who it is that is doing the grunt work.
People have analyzed the query traffic to (some of) the "." content DNS
servers, by the way. CAIDA did an analysis in 2002, for example.
Kirkpatrick et al. did another analysis in 2004. I recommend reading the
actual papers rather than the press reports of the same. As I mentioned
back in 2004, the CAIDA paper was reported as concluding that 98% of
traffic to the root content DNS servers was bogus, when in fact
according to the graphs in the paper itself it's only some 11%. (Duane
Wessels said in 2004 that the model employed in the 2002 study was
"overly simplistic", moreover.) One thing that the papers do focus upon
is caching as a primary concern. One of the things that people have
tried to measure, with only limited success, is how effectively the
world is caching the data that it receives from the "." content DNS
servers. It's how well the people who do query resolution cache what
they find that is important, not really how that work is handed around
to the places that it is done, before it is done.
If you want to stop impinging upon the "." content DNS servers, the
right way to do it is to run your own "." content DNS server, and
configure all of your resolving proxy DNS servers to start with it.
*That* is the direct way to reduce the load on the "." content DNS
servers, not forwarding at all. The idea is that any query resolution
traffic for lookups that start at the root never escapes your
site/organization/network at all, and stays purely local to you. The
only external traffic related to the root that is necessary is then a
fairly regular (the data don't change all that often) refresh of the
database content. (Mirror the Public Root database, for example, and
one, as things stand at the time of writing, need only check for data
changes every 12 hours and can hang on to stale data, if data
replication fails, for up to a fortnight.) Of course, once query
resolution reaches a point where there's a delegation *away* from the
root, then query resolution traffic passes across your borders again.
But in a number of cases, as the papers show, this won't be the case,
because the domain names being looked up aren't under existing top-level
domains, so query resolution starts and ends at the root content DNS
servers.
One way of thinking of this is that a "." content DNS server is brought
right within your borders themselves, so it's as close to you as it can
be. ICANN has, in effect, been trying to make this as near to the case
as it can get, by physically distributing its "." content DNS servers
around the world, so that query traffic to them is not many hops out
over Internet beyond (many, but not all) people's borders, and using
AnyCast to pretend that they're all the one server. Of course, to be
optimal that would require an AnyCast instance right outside the borders
of every AS on the planet, which isn't really feasible. And it still
wouldn't be as good as the case where everyone had their own "." content
DNS server.
Running one's own "." content DNS server is fairly easy for a company or
organization with a corporate LAN, which will (certainly if Active
Directory is involved) involve site-local content DNS servers
somewhere. As long as the company/organization has done the sensible
thing and separated its content DNS servers from its proxy DNS servers,
running a "." content DNS server can be as easy as just adding a replica
of the root "zone" to the content DNS servers' databases and pointing
the (resolving) proxy DNS servers to them. It's somewhat harder for the
end-user with the single leaf node personal computer. But that extra
difficulty lies mainly in deciding to run local DNS servers in the first
place, and configuring the necessary services on a PC somewhere, when
the only PC operating systems where it's expected that one runs a DNS
server as standard kit, and that thus supply the software to do so right
in the box, are the Unixen and their clones; in contrast to corporate
LANs which will have the server flavours of the (non-Unix-clone)
operating systems, that also have DNS server software as standard kit.
That's not exactly an insurmountable problem.
Alex Taylor
wrote:
> >> However, I still would like to know whether "running a script when
> >> needed" is possible with the IBM's one.
> >
> > How many times do I have to repeat myself before what *I already told
> > you* sinks in? That's exactly what IBM's DHCP client *already does*.
> > That's, fundamentally, how it works. It runs a script (sometimes a
> > default, built-in script) for each option received. What do you think
> > DHCPIBM.CMD is?
>
> I do not know, you tell me please. Or, better, if you already know the
> answer, just explain what should one do so that c:\foo.cmd is run
> after the lease is updated/acquired.
The DHCP client is configured by %ETC%\DHCPCD.CFG; examining that file
(it is self-documented quite well) should give you a starting point.
There's also a brief example in chapter 7 of Redbook SG24-5280.
--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00
Please take off hat when replying.