On 02/03/2012 06:49:30 PM, jdow wrote:
> On 2012/02/03 16:52, Rick Stevens wrote:
> > On 02/03/2012 02:39 PM, Geoffrey Leach wrote:
> >> On 02/03/2012 01:54:34 PM, j.e.aneiros wrote:
> >>> On Fri, Feb 3, 2012 at 4:01 PM, Geoffrey Leach<geoff@xxxxxxxxxx>
> >>> wrote:
> >>>
> >>>> A system on my local network (pvr) has its IP address in
> /etc/hosts
> >>>>
> >>>> geoff@pvr[1]->cat /etc/hosts
> >>>> 127.0.0.1 localhost localhost.localdomain localhost4
> >>>> localhost4.localdomain4
> >>>>
> >>>> 192.168.10.2 pvr.mtranch.com pvr
> >>>> 192.168.10.3 mtranch.mtranch.com mtranch
> >>>> 192.168.10.1 Netgear
> >>>> 198.168.20.5 Homerun
> >>>>
> >>>> Netgear router accessed from pvr via wireless. It has the
> address
> >>>> 192.168.10.2 reserved and assigned to pvr. Worked fine. Today
> >>> after
> >>>> booting up the latest kernel, (3.2.2-1.fc16.i686.PAE), the IP
> >>> address
> >>>> has changed to 192.168.10.5:
> >>>>
> >>>> geoff@pvr[2]->ifconfig wlan0
> >>>> wlan0 Link encap:Ethernet HWaddr AE:5D:BA:91:67:2D
> >>>> inet addr:192.168.10.5 Bcast:192.168.10.255
> >>>> Mask:255.255.255.0
> >>>> inet6 addr: fe80::ac5d:baff:fe91:672d/64 Scope:Link
> >>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> >>>> RX packets:484 errors:0 dropped:0 overruns:0 frame:0
> >>>> TX packets:462 errors:0 dropped:0 overruns:0 carrier:0
> >>>> collisions:0 txqueuelen:1000
> >>>>
> >>>> you'll note that it is 192.168.10.5
> >>>>
> >>>> Not surprisingly, I can't ssh 192.168.10.2, but I can ssh
> >>> 192.168.10.5
> >>>>
> >>>> Question: where is this (dynamic?) assignment taking place?
> >>>>
> >>>
> >>> I think the machine is requesting the router a new IP and the
> router
> >>> couldn't match the MAC of the request with the MAC associated to
> the
> >>> reserved IP 192.168.10.2, so is giving a new IP in the range.
> >>> Something
> >>> change at the machine, did you check the MAC AE:5D:BA:91:67:2D
> >>> against
> >>> your
> >>> rule in the router?
> >>
> >> Your suspicion was correct. I replaced the one in use with the one
> from
> >> ifconfig. Unfortunately that did not fix the problem.
> >>
> >> I need a tutorial on assigning MAC addresses, as they are
> inconsistent
> >> on the server and client. Is it correct that the MAC address is
> the
> >> same as HWADDR in the ifcfg file? And why would the value change
> when
> >> the hardware did not?
> >
> > They're supposed to be the same. The only way to be sure is to
> actually
> > see what the driver assigned as the MAC address:
> >
> > $ cat /sys/class/net/wlan0/address
> >
> > What's returned by that is the MAC address as set up by the driver.
> > That should match the value in the ifcfg file's HWADDR field.
>
> There is also the little pesky detail that the computer remembers the
> address
> that it last used and requests that of the DHCP server. Modulo the
> server
> involved it will give the requested address regardless of whether it
> has a
> formal assignment for that MAC to another address or not. You may
> have
> to
> tell the computer to formally release the current DHCP assignment
> before
> going off to request a new one.
>
> {o.o} Been bit by this one before. It's also painful to change a
> computer's
> name on a network in which the dhcpd updates the named.
> Absurdly short
> TTLs helps.
OK, I believe I've isolated the source of the problem. The wireless
interface on pvr (the client) is a USB device, (Roswell RNX-G) delivers
a different MAC address on reboot and whenever its removed and replaced
in its USB socket. When the MAC changes, the router delivers a new IP
address, and everything I've observed follows.
I presume that the Roswell RNX-G requires replacement, unless someone
has a better idea.
Thanks to all who offered advice.
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
