I've searched the online leaf archives and didn't find a compendium of
all this info that I've learned so I'm submitting it here. It is
long-winded and represents what I've learned, on a Dachstein (IDE
kernel) box, about MAC address management and dhclient & dhcp - my
initial problem, observations & my resolution. I will speak as though
all things are unassailable truths in the hopes that someone who does in
fact know better will feel compelled to stand up and correct me.
First it must be said a great thanks to the people who have made
LRP/leaf a reality. I love my router. I causes me no grief and I can
make changes easily. Rightly or not it gives me a warm, fuzzy feeling of
security. Thank you.
Situation:
- I setup my router in the 'standard' eth0-internet-dhclient,
eth1-internal-dhcpserver, eth2-dmz-fixed-address arrangement with no
funny NAT or anything
- I don't have anything on eth2 at the time and eth1 serves only a
coupl'a PC's
- I am a Rogers (Ontario) high-speed subscriber.
- Rogers uses DHCP-served ip addresses
- Rogers locks-in a served IP address (in effect, locking-in that
particular cable modem) based on the MAC address of the card that
requested the IP address ... unless a DHCPRELEASE is executed, in which
case a different MAC address can be used to request an IP address
- I had an E2B (Eiger2Beta) box (called "Rold"; P1-133; eth0 is on a
PCI NIC) up and running for about 18 months with no probs, except the
dhclient-lease-renewal issue which aggravated me once per year. I
recently got the dhclient 2.0pl5 to make that particular problem go away.
- I had always wanted to have a backup router box so I setup a 486
with Dach (called "Rnew"; eth0 is on an ISA NIC)
- I cannot substitute the boxes directly because of this: if my
Rold:eth0 card dies or Rold blows up I will have lost track of what it's
MAC address was
- I obviously cannot coerce a PCI card (current eth0) into an ISO
slot on the upgrade box
- Because E2B & Dach use dhclient 2.0pl5 I can't perform a 'release'
of my IP address
- Thus I have to contact Rogers and beg then to clear the MAC
address from their ARP table
- Resetting a MAC address seems to be a big deal to Rogers and a
pain for me, the user, to accomplish (call, wait, wait, wait, describe
(lie about using Linux), argue, beg, beg some more, succeed)
- If I knew the MAC addy of Rold:eth0 and could set Rnew:eth0 to
that addy then I would have no problem in the first place
- Better yet, if I set them both up in the first place, with a
known, easy-to-remember MAC address then I would always have a 100%
swap-in box at the ready and never need to worry about this stupid
MAC-address lockdown that Rogers uses cuz I could _remember_ what my MAC
addy is supposed to be!
- This issue would also effect someone who: wants to upgrade from
one box to another, whose ISP does a mac-addy lockdown, who doesn't want
want to transport eth0 to the upgrade box (and who may not even be able
to specify that that card is eth0 what with one's lesser control over
ethN assignment with PCI cards, etc)
Observations:
- IMO, a shortcoming in E2B/Dach if I may: E2B & Dachstein both have
a dhclient of version 2.0pl5. This version does not permit one to
perform a release of the IP address. Don't bother to try (dhclient -r
eth0 ???) because you don't get that ability until dhclient version 3.
So my devil's advocate question is (and I'll post a separate
compile-request): is there a material reason that we don't have a newer
version of dhclient in the Dach package?
- On the web one can read about changing the dhcp-client-identifier
identifier (Dach: lrcfg/3/4/1) as a means of changing one's MAC address
(format: 01:aa:bb:cc:dd:ee:ff where aa...ff is your fake mac addy, in
hex octet form - NOTE the leading 01: !!!). This may be theoretically
true but it didn't work for me. From a posting
(http://www.geocrawler.com/mail/msg.php3?msg_id=3072792&list=465) by the
guy (Ted Lemon) behind dhcp:
> It`s [Window NT-based DHCP servers are] required to take the
> client identifier in favor of the MAC address.
it would seem to be the case that it _should_ work it didn't for me.
However, the fact is that the adapter's MAC address is sent as a
separate field to the client-identifier, which means that Rogers can
accomplish what they are doing. If you're running a dhcp-Server on your
leaf box then view the contents of /var/state/dhcp/dhcpd.leases to see
what I mean (in example below 00:04:05:5d:7d:4e is the MAC addy of the
card doing the DHCP request; "uid" is the client-identifier):
> lease 192.168.0.1 {
> starts 4 2002/04/04 06:40:37;
> ends 4 2002/04/04 18:40:37;
> hardware ethernet 00:04:05:5d:7d:4e;
> uid 01:00:04:05:5d:7d:4e;
> client-hostname "ske";
> }
- how I worked around this situation at first: My usual workstation
is a Win98SE box that, via the program winipcfg (StartMenu/Run:winipcfg)
allows me to release an IP address. The problem is that after I plug in
my cable-modem-connected network cable directly into my windows box I
still don't have the correct mac address (or IP address for that matter)
to effect the release ... (from the apocryphal-idea files comes the
brainfart: would it be possible to set, on this windows box, ones IP
addy to the fixed address that is the usual dhcp-served-addy, with the
correct gateway setting, and then booting up using that, execute a
successful release via winipcfg - probably not?!?!) ...
Back to the problem at hand - I need to set the correct mac address
on my windows box ... and this is possible (at least with my OS &
network driver -dLink DFE-530TX+). Via: StartMenu/ Settings/
ControlPanel/ Network/ tab:Configuration/ <relevant_network_adapter_>/
properties/tab:Advanced/ property:NetworkAddress/ value (whew!). You can
enter the 12 characters that represent a MAC addy's six hex chars (e.g.
0004055d7d4e). Reboot and your windows box should be able to properly
get served your IP address. Bring up winipcfg, do the release. Now you
can boot any box and it will get served a 'fresh' ip address (in my case
if I change MAC address I can usually get a different IP address).
- ok, so I plug the network cable back into the lrp box and it comes
up and all is well...
- the problem of swappable backup boxes still remains - I sure don't
want to have to be re-connecting my net cables if my lrp box dies and I
didn't even write-down-and-store-in-a-safe-location the mac address that
I had to enter on my windows box (do you have your current eth0 mac addy
written down somewhere?)
- ... unless I can set the mac addy on my LRP box, right?! Then I
can set both of them to some memorable mac addy and never have a problem
with this.
Resolution:
- one can on the Dach box, do this to set the MAC addy. Do:
ip link set eth0 down
then
ip link set eth0 address aa:bb:cc:dd:ee:ff
then
ip link set eth0 up
and you will have a new MAC address on eth0.
- So now we have a solution and we need to wrap it all up into some
autoexecutable mechanism.
- I elected to add this stuff to the /etc/dhclient-enter-hooks
script (Dach: lrcfg/3/4/4). At line 8 I inserted:
> # var: REPLACE_ETH0_MAC_ADDRESS
> # Performs: Overrides eth0's default (hardware-specific) MAC address
> # default: <blank>
> # valid settings: blank, or any mac address in hex octet form
> # (e.g. 00:04:07:fe:23:a7)
> # if blank then no replacement of the eth0's MAC addy happens
> ##################################################################
> #lrp_200_eth0#REPLACE_ETH0_MAC_ADDRESS=00:00:1b:49:b0:24
> # r1_eth0#REPLACE_ETH0_MAC_ADDRESS=00:04:05:5d:7d:4e
> #REPLACE_ETH0_MAC_ADDRESS=00:00:00:00:00:01
> REPLACE_ETH0_MAC_ADDRESS=00:00:00:00:00:02
- and at (now) line 24 (after the 'flush') I added:
> if [ "$REPLACE_ETH0_MAC_ADDRESS" != "" ]; then
> # skeadditions to fake-out MAC address for eth0
> echo " >> Reassigning MAC address for eth0 << "
> echo " > Stop eth0 (via: ip link set eth0 down)..."
> ip link set eth0 down
>
> echo " > Reassign eth0 MAC address to be
$REPLACE_ETH0_MAC_ADDRESS..."
> echo " (via: ip link set eth0 address
$REPLACE_ETH0_MAC_ADDRESS)..."
> ip link set eth0 address $REPLACE_ETH0_MAC_ADDRESS
>
> echo " > Start eth0 (via: ip link set eth0 up)..."
> ip link set eth0 up
> echo " >> DONE --> Reassigning MAC address for eth0 <<"
> fi
- save the script and backup. You now have control over your MAC
address, before it executes the first DHCP-request.
- attached (if this group so permits ... nope, DENIED IN ADMIN) is
my dhclient.lrp that is a drop-in replacement if you want to add this
MAC addy support, or if you prefer I've included just the modified
client-enter-hooks script
Conclusion:
- if your ISP uses MAC addy lockdown then...
- be aware of your dependency on your MAC address; know your MAC
addy
- consider setting up a MAC address that is memorable
- MAC address overriding can be done on LRP boxes to aid in
redundancy
Unresolved questions:
- it seems that any valid text char is valid in the Windows MAC-addy
'value' field: what happens with other chars? Alt-250? Alt-0250? etc?
- does anyone know rules about what constitutes a valid MAC addy?
- is dhclient-enter-hooks the best place for addition of such
functionality?
TidBits:
- Rogers would not deliver an IP address for the following MAC
addy's (as set under Win98): 01:02:03:04:05:06, ff:ff:ff:ff:ff:ff. When
I selected, under Win98, to use 'Not Present' for the MAC addy, it
seemed (IIRC) to use the last 'value' MAC address that I had specified.
When I specified a MAC addy of 000000000000 it then used the adapter's
default hardware MAC addy.
- I read about (but didn't try) a utility for Linux to change one's
MAC address, called 'changemac', if you're so interested
Suggestions (to the community):
- add MAC address handling (via a var) to the Dach network.conf
script - can we set a var there and have it effect in
dhclient-enter-hooks? I dunno how myself.
- for Dachstein, replace the dhclient executable with a newer one
that supports a DHCPRELEASE command; provide a newer one at Charles'
modules page (which is where I looked)
- to my thinking it would make the most sense to override a mac addy
when a network driver module loads(ne.o, tulip,o, etc), but I never
found such an option. Am I missing something here (is this in fact the
best place to specify this? is there a reason that that functionality is
not already there? is the functionality there but I missed it?)
Final:
- I have written this doc to contribute back to the community that
has made my success with leaf possible. For that reason, I invite
critical (or kudo!) comments back from people about how I did here in
barfing out a bunch of info. Had I found this doc myself in the first
place, it would have saved me a bunch of time so that's what I'm trying
to give back. I prefer that you reply privately ([EMAIL PROTECTED])
than on the forum.
- Thanks to Charles et al for Dachstein!
--
The best time to tackle a small problem is before he grows up.
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
