> "Ethernet-over-firewire": If you mean the firewire connector/system on > the machine by that:
Yes, there is a kernel module that implements ethernet-like networking on top of FireWire. > 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 ... :) Well, in that case it would have a lose contact on all macs including mine :) No, I think the problem is with that damn driver that randomly don't work. > 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 ... I think the linux firewire stack is fairly broken, but you can complain on their mailing list. > 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 > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
