From: ibuprofin@painkiller.example.tld.invalid
On Sat, 19 Jan 2013, in the Usenet newsgroup alt.os.linux.mandriva, in article
, Adam wrote:
>Moe Trin wrote:
[Thinkpad T60]
>> there is no need for hurry. You don't need it in class yet, right?
>Nope, looks like I won't need it at all there. (Although spring-term
>classes are a great place to pick up anything contagious, ugh.)
Is that medical, or computer contagions?
>Meanwhile I made other discoveries about the laptop. When I boot
>Mandriva on battery power, it's VERY slow (presumably to conserve the
>battery charge), even if I then connect it to AC. I'm sure that's
>configurable.
I believe that's an acpid function. That is _probably_ distribution
specific, and there should be a helper tool or menu item for it.
>Also, its built-in dialup modem is a customized Winmodem.
> I thought that might be handy for sending and getting faxes away
>from home, but then I've never had a need for that.
That would also assume you have the appropriate phone cable AND a
place to plug in and make the call. I can probably count the number
of times I've had access to a public "open" phone jack. On the other
hand, neither of our laptops has a modem of any kind, but the little
US Robotics 5637 USB modems I have are small enough to carry (about a
pack of cigarettes with cables coiled) if needed.
>> I _thought_ they were getting IPs from the router - and the
>> _router_ was configured to hand out specific IPs to specific MACs.
>> Yes, that is static addressing, but it's still using DHCP.
>No, everything has a static address specified in
>/etc/sysconfig/network-scripts/ifcfg-whatever . That's because (a) it
>worked and (b) I don't recall any recommendations to do it any other
>way.
Oh, OK - I misunderstood your setup. DHCP is the more common setup
because it usually works and requires little to no thinking on the
part of the person setting up the computer. The technical burden is
transferred to the person who has to set up the DHCP server, and that
may or may not be a problem.
>> Because the wireless side of helot does indeed go out and about,
>> I'd suggest setting it for DHCP. At home if you're using the
>> wireless, I'd suggest setting the router to hand out a "fixed"
>> wireless address based on the hardware address associated with
>> helot's wireless interface
>Same thing as the MAC address?
Yup - but almost certainly a different value from that of eth0. My
HP has a 64:31:50: (HP) MAC on eth0 and a 4c:0f:6e: (Happy Peoples
Factory No 174) on wlan0.
>> If you are also using it on Ethernet, either set that with a
>> static address, _OR_ set the router to give out a "fixed" address
>> based on the MAC address of the Ethernet interface (what is shown by
>> "/sbin/ifconfig eth0"). My understanding of your setup was you are
>> using one range on the Ethernet (ex: 192.168.1.0/28), and a separate
>> range (ex: 192.168.1.16/28) for the wireless.
>No, because nobody ever suggested that. Only suggestion I remember
>was moving the router from 192.168.1.1 (and I learned the router has
>to have the lowest used address). Would using separate ranges for
>wired and wireless make things easier or better?
Boy, I'm batting a thousand on your setup. It may make it easier for
for router, but if it's acting as a bridge this may not be the case.
>192.168.1.23 eris.aplomb.invalid eris
>192.168.1.24 eris-wired.aplomb.invalid eris-wired
>and the address ending in 3 is the "usual" one for that device.
OK, let's start by talking about the routing problem, and we'll assume
everything is using Ethernet at the moment. Host A wants to talk to
host B and the address is in the 192.168.1.x range appropriate. The
routing table would have a single entry for this, looking like
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 655 eth0
This says everyone in 192.168.1.x is reachable directly on the eth0
interface. A wireless only setup would look the same, differing only
in the name of the interface. Now let's get complicated and have BOTH
interfaces up, and some systems reachable on the Ethernet, some only
on wireless. The routing table looks like this now
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 655 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
and maybe you see the problem. How do you know which route to use?
They both lead to 192.168.1.x, and have equal Metrics. The Linux
kernel knows in this case to use the last route declared/set-up, under
the assumption that who-ever did so screwed up with the first route,
and corrected that - BUT FAILED TO REMOVE THE ORIGINAL MISTAKEN ONE.
So the kernel does you a favor and ignores any/all duplicate routes
except the last one - note the "Use" counts and "Tx packets" counts in
the "/sbin/ifconfig -a" output.
There are several ways around this little mess, each more complicated
than the other ;-) The solution involves having one system with
both interfaces working (the router?) acting as a relay between the
two links. I thought you had solved this when you had eris on one
link, and stolid or retread on the other - using the DSL router as a
transparent bridge. That involves telling the router to act as a
bridge and have it do proxy-arp if needed. Stolid would try to talk
to the hpclj5 by noting it has a "local" IP address, sending an ARP
packet ("who-has 192.168.1.33") and the hpclj5 on hearing the request
responding with a "192.168.1.33 is-at 00:40:17:34:ef:40"). If it
were to try to talk to eris, AND eris is on the wireless link, eris
wouldn't hear the ARP request - and stolid would report "you can't
get there from here"... UNLESS the DSL router is doing bridging and/or
proxy-arp/forwarding. The router hearing the arp request, AND if
it knows eris is up and on wireless (it should check), would reply
to stolid saying "192.168.1.33 is-at ds:l-:ha:rd:wa:re" and stolid
would be able to talk (with the router silently forwarding packets
each way). ANOTHER way to do this is to have the wireless on
(example) 192.168.2.x while the Ethernet remains on 192.168.1.x and
have the relay listed as the gateway:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 655 eth0
192.168.2.0 192.168.1.1 255.255.255.0 UG 0 0 44 eth0
and
Kernel IP routing table
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
