On 06/01/15 10:13, intrigeri wrote: > Hi, > > David Arnstein wrote (03 Jan 2015 19:28:01 GMT) : >> Today I downloaded a new ISO named >> tails-i386-feature_jessie-1.3-20150103T1234Z-67d9850.iso . I burned it to a >> DVD and >> I booted my Macbook Air from this DVD. > >> The WiFi function of the machine seems to be working, up to a point. The >> Tails GUI >> presented all of the WiFi SSIDs in my vicinity. I tried my own SSID but it >> failed >> to connect. > >> /var/log/syslog contains many interesting messages so I attach it to this >> email. > >> I don't know how to debug this issue further, but if you would send detailed >> instructions I should be able to follow. > > Thanks! I see MAC spoofing failures in the logs: > > Jan 3 19:14:12 localhost kernel: [ 62.201301] wl0: online cpus 1 > Jan 3 19:14:12 localhost kernel: [ 62.201709] wlan0: Broadcom BCM43a0 > 802.11 Hybrid Wireless Controller 6.30.223.248 (r487574) > Jan 3 19:14:12 localhost kernel: [ 62.441758] wl0: wl_set_mac_address: > error setting MAC addr override > Jan 3 19:15:36 localhost spoof-mac: Trying to spoof MAC address of NIC > wlan1... > Jan 3 19:15:36 localhost spoof-mac: macchanger failed for NIC wlan1, > returned 0 and > said: [ERROR] Could not change MAC: interface up or insufficient > permissions: Too > many open files in system#012Current MAC: 48:d7:05:a1:d8:73 > (unknown)#012Permanent > MAC: 48:d7:05:c3:d3:81 (unknown) > Jan 3 19:15:36 localhost kernel: [ 151.086135] wl0: wl_set_mac_address: > error setting MAC addr override
It's interesting that the "Current MAC" reported actually is different than the "Permanent MAC", which otherwise would indicate that MAC spoofing indeed succeeded. Could it be that the driver's/linux' state of the MAC address *is* changed (and that's what's reported), but that it remains unchanged in the hardware, so that their states are different? If so I think the least we should do to prevent the real MAC address from leaking is to treat errors from macchanger more seriously than we currently do (see #8571). Other than that, the (p)error "Too many open files in system" doesn't make much sense to me. Probably it's just that the (notoriously crappy) broadcom driver returns an incorrect error code. In fact, I had a quick look and the error code returned from wl_set_mac_address() is in turn returned by some function defined in the broadcom driver's "enormous binary blob [wlc_hybrid.o] which contains _all_ of the 802.11 protocol stack presented as a monolithic ethernet driver using WEXT" [1]. From a situation like that, I don't expect much consistency with the running kernel, but I confess I'm no expert in these matters. [1] http://blog.gmane.org/gmane.linux.ubuntu.devel.kernel.general/month=20090501/page=7 > So, > > * David, may you please opt-out from MAC spoofing in Tails Greeter, > and retry? This is crucial advice since a MAC spoofing failure should result in the driver being unloaded (to prevent the device from leaking the real MAC address) and a syslog entry about whether that succeeded or not. However, there's no such log entry in your attached syslog, which is very concerning, and that you actually got a list of SSIDs is even more so. After some digging the explanation is pretty simple: see #8571. Yikes! Note that the above issue (#8571) isn't really relevant for you, David. Like intrigeri suggested, please try again with MAC spoofing disabled in Tails Greeter. It could be that MAC address spoofing is terribly broken in the broadcom driver and sets the device in a bad state, and this is what you are experiencing. Cheers! _______________________________________________ tails-support mailing list [email protected] https://mailman.boum.org/listinfo/tails-support To unsubscribe from this list, send an empty email to [email protected].
