Re: How to get rid of sungem at boot time?
Hi Ben
Hi All
On Mon, Oct 17, 2005 at 08:54:00AM +1000, Benjamin Herrenschmidt wrote:
>
> > I've done tests this afternoon, and what I found is that the devices
> > change that the system "sees" from one reboot to another. Specifically
> > it is this device on a Titanium IV that the system knows about in one
> > instance, that it does not know about any more at another reboot:
> >
> > # ifconfig -a
> > eth0 Link encap:UNSPEC HWaddr 00-03-93-FF-FE-CD-E4-C4-00-00-00-00-00-00-00-00
> > BROADCAST MULTICAST MTU:1500 Metric:1
> > RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
> >
> > $ macchanger -s eth0
> > Current MAC: 00:03:93:ff:fe:cd (Apple Computer, Inc.)
> >
> > What is 00:03:93:ff:fe:cd : The modem?
>
> I think this is the Ethernet-over-firewire (which indeed for some
> strange reason doesn't always register itself).
"Ethernet-over-firewire": If you mean the firewire connector/system on
the machine by that:
And what if it's a hardware bug? In that the firewire system on the
machine has, e.g. a loose contact to the rest of the machine. In that case
even the best kernel/drivers would not be able to detect some firewire
system, with some eth0 device called
00-03-93-FF-FE-CD-E4-C4-00-00-00-00-00-00-00-00 ... :)
A few hours ago I remembered again the times when I connected a hard disk
via firewire to the Titanium, and I had problems to let kernel drivers
detect the partitions of that disk ...
So perhaps we're a bit too much a accustomed to blame Linux if
something does not work ... or at least in my case that might be true
... :)
>
> > If the eth0 device above is missing at another system boot the whole
> > devices order is shifting, and changed, and as a consequence
> > previous eth2 (radio card) simply does not exist any more, thus
> > rendering my settings in the /etc/network/interfaces useless ... :)
>
> The solution would be to able to specify interfaces by MAC or position
> in sysfs rather than ethX name in /etc/network/interfaces... Volunteer
> to fix those scripts ?
With sysfs you mean the scripts in the kernel source tree below
/fs/sysfs, is this correct? If that's true: I don't even understand
to *read* those scripts ... Sorry ...
My workaround, so far:
After system boot, if the radio card couldn't connect to the access
point, I firstly shut down the networking system (on Debian/unstable)
completely with that little script:
------------------------------------
#!/bin/sh -x
echo "Stopping networking .. " && \
/etc/init.d/portmap stop && \
/etc/init.d/dnsmasq stop && \
/etc/init.d/networking stop && \
/etc/init.d/ifupdown stop && \
/etc/init.d/dns-clean stop && \
echo "OK: Network is down"
---------------------------------
After that I make sure the wireless drivers are removed (not being
sure whether this is OK ... :)
-------------------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/removeairport.sh && \
rmmod airport && \
rmmod orinoco && \
rmmod hermes
---------------------------------------
Then with a 'ifconfig -a', 'iwconfig' or 'macchanger -s <device>' I
try to see which names my system gave to which devices. So if it
thinks that eth2 is my wireless card I change /etc/network/interfaces
file accordingly.
Following that I try to restart my networking system with that script:
--------------------------
#!/bin/sh
echo "Bringing up networking ..." && \
/etc/init.d/dns-clean start && \
/etc/init.d/ifupdown start && \
/etc/init.d/networking start && \
/etc/init.d/dnsmasq start && \
/etc/init.d/portmap start && \
echo "OK: Network is up and running"
------------------------------------
Too much work? ... :)
All of you, be careful please: I'd bet there are mistakes in the
scripts above. Don't just use them, but please try to find out what
they do instead.
My idea behind it simply was to clone the Debian boot/shutdown system
as to what it does when starting/stopping networking .... These
scripts work rather well here since quite some time, IIRC, (provided I
do not try to establish a WLAN connection to my AP when its wireless
system is switched off, as it happened to me this afternoon ... :) but
something that works does not necessarily mean it's right ...
At any rate: HTH
Best Regards
Wolfgang
--
Wolfgang Pfeiffer
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
Key fingerprint = A8CA 9D8C 54C4 4CC1 0B26 AA3C 9108 FB42 E303 7113
Reply to: