**** BEGIN LOGGING AT Sat Dec 01 02:59:58 2012
Dec 01 15:23:07 <dwmw2_gone> DonkeyHotei?
Dec 01 15:23:19 <DonkeyHotei> me.
Dec 01 15:23:28 <dwmw2_gone> did you try a hotplug script?
Dec 01 15:24:09 <DonkeyHotei> no, i kinda drifted off, then did something else until i fell asleep
Dec 01 15:24:27 <DonkeyHotei> woke up maybe 15 min ago
Dec 01 15:27:11 <DonkeyHotei> a potential issue with the hotplug script idea is that the script needs to set the mac before /etc/config/network can change it again if desired
Dec 01 15:29:23 <DonkeyHotei> another thing i don't like is that using ifconfig or iproute2 will leave the "true mac" as reported by sysfs as the wrong one, unless it's set at the br2684 level before the vc is created
Dec 01 15:29:38 <dwmw2_gone> really?
Dec 01 15:30:06 <DonkeyHotei> yes, and that tends to confuse owrt's scripts for setting custom macs
Dec 01 15:30:22 <dwmw2_gone> root@geos:/etc/hotplug.d/net# ip link set nas0 addr 00:02:03:04:05:06
Dec 01 15:30:27 <dwmw2_gone> root@geos:/sys/class/net/nas0# cat address
Dec 01 15:30:27 <dwmw2_gone> 00:02:03:04:05:06
Dec 01 15:31:06 <dwmw2_gone> we should be *using* openwrt's scripts for setting custom macs, as much as possible
Dec 01 15:31:59 <DonkeyHotei> yes, when it's an actual custom mac. not for a default.
Dec 01 15:33:13 <nbd> using scripts for this is a bad idea
Dec 01 15:33:20 <nbd> i want to get rid of dependencies on ifconfig/ip
Dec 01 15:34:04 <DonkeyHotei> nbd: my thoughts exactly
Dec 01 15:34:45 <nbd> so, how about just setting a default mac for nas0 in /etc/config/network via a 'config device' section
Dec 01 15:34:48 <DonkeyHotei> nbd: did you read the ml thread? blogic says he agrees with everything conor said
Dec 01 15:35:02 <nbd> i haven't been reading the ML lately, just got back from egypt today
Dec 01 15:35:06 <DonkeyHotei> ok
Dec 01 15:35:44 <DonkeyHotei> there are two problems with using /etc/config/network:
Dec 01 15:36:26 <DonkeyHotei> 1) it requires user intervention to create what should unequivocally be an out-of-the-box default
Dec 01 15:37:01 <dwmw2_gone> I wouldn't advocate doing that
Dec 01 15:37:05 <nbd> why does it require user interaction? just provide a uci-defaults script
Dec 01 15:37:08 <dwmw2_gone> do it in userspace, wherever MAC overrides are usually done
Dec 01 15:37:22 <DonkeyHotei> 2) if there are multiple virtual circuits, they'll all have the same "factory mac" and /etc/config/network won't tell them apart
Dec 01 15:37:24 <dwmw2_gone> but make it derive from the ethaddr on the kernel command line (unless overridden explicitly by the user)
Dec 01 15:37:47 <dwmw2_gone> I thought the whole point in the MAC override was to be able to set the MAC depending on *other* information
Dec 01 15:37:57 <dwmw2_gone> like the 'bus-info' that's reported by 'ethtool -i' for example
Dec 01 15:38:04 * dwmw2_gone currently working on a br2684 patch to fix that :)
Dec 01 15:38:22 <DonkeyHotei> dwmw2_gone: currently, mac overrides in owrt are based on the existing mac
Dec 01 15:38:30 <nbd> doing this in br2684 sounds like a good idea to me
Dec 01 15:38:32 <dwmw2_gone> well that's just pointless
Dec 01 15:38:50 <dwmw2_gone> we could allow br2684ctl to set the MAC
Dec 01 15:38:53 <dwmw2_gone> if it's told what to use
Dec 01 15:38:57 <nbd> yes
Dec 01 15:38:57 <DonkeyHotei> nbd: the daemon, or br2684.ko?
Dec 01 15:39:01 <nbd> the daemon
Dec 01 15:39:12 <nbd> this is policy that should be handled in userspace
Dec 01 15:39:29 <dwmw2_gone> the dæmon would only do the equivalent of 'ip link set nas0 addr foo'
Dec 01 15:39:45 <nbd> yes, makes sense
Dec 01 15:40:01 <nbd> it's better than pushing nas* specific hackery to scripts or netifd
Dec 01 15:40:06 <dwmw2_gone> the dæmon is just two ioctls right now. Make VCC socket, ioctl to make nas0 device, ioctl to bind the vcc to it. then for(;;);
Dec 01 15:40:27 <dwmw2_gone> scripts or netifd have to invoke br2684ctl with the right args anyway though
Dec 01 15:40:43 <dwmw2_gone> how *is* br2684ctl invoked right now? It's scripts, isn't it? on atm device hotplug?
Dec 01 15:40:57 <DonkeyHotei> i'd love to have the daemon do it, but 1) it has no direct communication with the proper field in the driver and 2) it would need ugly hackery to find the right default
Dec 01 15:40:59 <nbd> yes, the script that uses br2684ctl should provide the mac address
Dec 01 15:41:02 <dwmw2_gone> oh, wait. It's an initscript. Which is broken and needs to be fixed.
Dec 01 15:41:11 <nbd> but the logic should not go into anything generic
Dec 01 15:41:29 <dwmw2_gone> DonkeyHotei: the dæmon *can* do it. Just set the MAC address using the normal ioctl/netlink thing
Dec 01 15:41:49 <dwmw2_gone> that *is* direct communication with the proper field in the driver.
Dec 01 15:42:08 <dwmw2_gone> nbd: I think it *is* generic
Dec 01 15:42:09 <DonkeyHotei> dwmw2_gone: i'd much prefer a new ioctl be created. it's the best long-term solution
Dec 01 15:42:12 <dwmw2_gone> the existing MAC override is broken.
Dec 01 15:42:28 <nbd> how is it broken?
Dec 01 15:42:28 <dwmw2_gone> the whole point of a MAC override (for Ethernet devices; forget br2684) is that you don't have a stable/unique MAC address
Dec 01 15:42:39 <dwmw2_gone> so using the existing MAC address as the key for overriding it is... wrong.
Dec 01 15:42:57 <nbd> hm
Dec 01 15:43:07 <dwmw2_gone> a MAC override needs to be based on something like ethtool bus info. "The NIC at PCI slot 0000:00:0b.0'
Dec 01 15:43:17 <DonkeyHotei> dwmw2_gone: this is why i inserted that fugly prom hack into the acx-mac80211 driver
Dec 01 15:43:17 <nbd> ok, so we need to come up with a good generic way to assign a default mac to a device based on some parameters
Dec 01 15:43:19 <dwmw2_gone> otherwise it's just pointless
Dec 01 15:43:34 <dwmw2_gone> # ethtool -i eth1 | grep bus-info
Dec 01 15:43:34 <dwmw2_gone> bus-info: 0000:00:0b.0
Dec 01 15:43:52 <dwmw2_gone> # ethtool -i nas0 | grep bus-info
Dec 01 15:44:07 <dwmw2_gone> bus-info: solos-pci0:0.38
Dec 01 15:44:14 <dwmw2_gone> (after my patch)
Dec 01 15:44:23 <dwmw2_gone> and now, there is *nothing* special-case about the nas0 MAC override.
Dec 01 15:44:58 <DonkeyHotei> nbd: netlink just doesn't cut it when a phy is involved, though
Dec 01 15:45:17 <dwmw2_gone> nbd: I'll fix the br2684 kernel side to provide suitable bus-info.
Dec 01 15:45:29 <DonkeyHotei> thankfully, nas0 doesn't have one
Dec 01 15:45:29 <dwmw2_gone> then it's just a case of userspace MAC overrides becoming non-pointless and non-broken :)
Dec 01 15:45:41 <nbd> DonkeyHotei: so there needs to be a way to change the default mac address for a phy via nl80211
Dec 01 15:46:02 <nbd> DonkeyHotei: or a way to make the driver get the right info in the first place
Dec 01 15:46:13 <dwmw2_gone> we're talking about wireless now?
Dec 01 15:46:45 <DonkeyHotei> nbd: i did the latter for acx, using the same fugly patch basically that blogic hated so much
Dec 01 15:47:31 <nbd> bbl
Dec 01 15:48:04 <DonkeyHotei> dwmw2_gone: look in the patches dir for acx-mac80211 in owrt
Dec 01 15:48:38 <DonkeyHotei> and then look at how ar7-atm gets a mac
Dec 01 15:49:48 <dwmw2_gone> afaik atm doesn't need a mac. only br2684 does.
Dec 01 15:49:49 <DonkeyHotei> of course, perpetuating bad code is not a good thing
Dec 01 15:49:52 <dwmw2_gone> and we can handle that generically
Dec 01 15:50:28 <DonkeyHotei> yes, but i think it should be with a new ioctl from br2684 to br2684.ko
Dec 01 15:50:46 <DonkeyHotei> not the existing ones
Dec 01 15:51:01 <dwmw2_gone> why?
Dec 01 15:51:13 <DonkeyHotei> abstraction
Dec 01 15:51:28 <dwmw2_gone> er, what?
Dec 01 15:51:36 <dwmw2_gone> we have a perfectly valid way to set a mac address on an interface
Dec 01 15:51:39 <DonkeyHotei> and decreased dependence on specific userspace behavior
Dec 01 15:51:43 <dwmw2_gone> you want to duplicate this... why?
Dec 01 15:51:53 <DonkeyHotei> it's not a duplication
Dec 01 15:52:49 <dwmw2_gone> it is. br2684 already copes with the *proper* way of setting MAC addresses.
Dec 01 15:52:55 <DonkeyHotei> this would be br2684-specific _below_ the nl layer
Dec 01 15:53:04 <dwmw2_gone> and if it's set the proper way, it'll use it. Else it'll pick up an address from the ESI of the ATM device.
Dec 01 15:53:34 <DonkeyHotei> exactly ---- there needs to be an ESI
Dec 01 15:53:48 <DonkeyHotei> but where will the ESI come from?
Dec 01 15:53:55 <dwmw2_gone> not if you use 'ip link set nas0 addr foo'. The code is explicitly designed to cope with that.
Dec 01 15:54:09 <dwmw2_gone> read the br2684 kernel code. It *handles* the MAC address being set.
Dec 01 15:54:11 <dwmw2_gone> it's fine
Dec 01 15:54:18 <dwmw2_gone> we just need to set it.
Dec 01 15:54:45 <DonkeyHotei> i read the code, and it reads the esi when the vc is created
Dec 01 15:55:13 <dwmw2_gone> unless it's already been set
Dec 01 15:55:35 <DonkeyHotei> there is nothing to have already set it here
Dec 01 15:55:43 * dwmw2_gone facepalms
Dec 01 15:55:59 <dwmw2_gone> THAT IS WHY I AM TELLING YOU THAT ALL WE NEED TO DO IS SET IT. IN USERSPACE. WITHOUT TOUCHING THE KERNEL CODE
Dec 01 15:56:11 <dwmw2_gone> except to provide the bus-info information, of course.
Dec 01 15:56:23 <dwmw2_gone> which I'm working on, when I'm not beating my head against the table in frustration :)
Dec 01 15:56:37 <DonkeyHotei> i'm not against doing it in userspace
Dec 01 15:57:03 <dwmw2_gone> good. Do it from userspace, using the perfectly good interface that already exists for doing it from userspace, and all will be fine.
Dec 01 15:57:48 <DonkeyHotei> the way i see it, br2684.ko should either have a fallback (from userspace) upon creation of the vc, or a way to obtain one (from userspace) beforehand
Dec 01 15:58:56 <dwmw2_gone> why not do it *before* assigning the VC?
Dec 01 15:59:14 <DonkeyHotei> THAT'S EXACTLY WHAT I JUST SAID
Dec 01 15:59:16 <dwmw2_gone> br2684ctl first creates the device, with ATM_NEWBACKENDIF ioctl
Dec 01 15:59:28 <dwmw2_gone> then you set the mac, using the standard way of setting a mac on an Ethernet device
Dec 01 15:59:45 <dwmw2_gone> then the ATM_SETBACKEND ioctl to actually connect the vc
Dec 01 15:59:57 <dwmw2_gone> no changes to br2684.ko required
Dec 01 16:00:12 <DonkeyHotei> that's fine, but there is no existing code that does it
Dec 01 16:00:44 <DonkeyHotei> in fact, that's the best solution i've heard so far
Dec 01 16:00:51 <dwmw2_gone> except the generic code in openwrt for setting MAC addresses on newly-created devices.
Dec 01 16:01:04 <dwmw2_gone> which may indeed not exist already :)
Dec 01 16:01:33 <dwmw2_gone> hm, interesting observation... at the time the device is *created* there is no VC attached. So we can't easily put anything sane into the bus-info
Dec 01 16:02:03 <dwmw2_gone> however, the name (nas0) *is* chosen by us. So we can simply say 'nas0 is MAC address xxxxx; nas1 is MAC address yyyyy'
Dec 01 16:02:08 <DonkeyHotei> there is code that exists in owrt to set macs on new devices, but what we're describing is not what it does
Dec 01 16:02:14 <dwmw2_gone> the generic mac-setting code ought to cope with identifying a device by name :)
Dec 01 16:02:38 <dwmw2_gone> right. It currently matches only the existing MAC of a device — and *not* its name?
Dec 01 16:02:43 <dwmw2_gone> or can it do it by name too?
Dec 01 16:02:56 <DonkeyHotei> you know, the names are potentially random, especially if changed through nl
Dec 01 16:03:21 <dwmw2_gone> and of course it'd have to get the MAC address to use from the ethaddr= kernel argument. But presumably it already has the hooks for that, for other reasons?
Dec 01 16:03:31 <dwmw2_gone> the name it's *created* with is the name we tell br2684ctl to create
Dec 01 16:04:14 <DonkeyHotei> getting the actual correct mac is something we can worry about after we have a mechanism to set it between ATM_NEWBACKENDIF and ATM_SETBACKEND
Dec 01 16:04:39 <dwmw2_gone> it doesn't have to be *between* them. It can be after ATM_SETBACKEND too. That's no problem
Dec 01 16:05:20 <dwmw2_gone> the br2684ctl init script is broken w.r.t. choosing device names, btw.
Dec 01 16:05:35 <dwmw2_gone> it passes a string as the -c argument, when it should just be a number
Dec 01 16:05:52 <DonkeyHotei> i still think the cleanest thing would be to have a good initial ESI, the way ar7-atm does
Dec 01 16:05:53 <dwmw2_gone> hm, or maybe not. Perhaps I got that from somewhere else.
Dec 01 16:06:20 <dwmw2_gone> then you end up hacking every ATM driver. Better to let userspace set it, like we do for Ethernet
Dec 01 16:06:40 <dwmw2_gone> we don't hack all the Ethernet drivers to magically come up with good MAC addresses either. We fix it up in userspace
Dec 01 16:06:41 <DonkeyHotei> it could easily be moved out of the atm driver
Dec 01 16:07:33 <DonkeyHotei> in fact, there is no reason br2684.ko should even know what the atm driver thinks the esi should be
Dec 01 16:07:53 <dwmw2_gone> using the ESI makes sense as a default when no other MAC address has been provided.
Dec 01 16:08:20 <DonkeyHotei> yes, assuming an esi is provided as a default
Dec 01 16:08:39 <DonkeyHotei> this issue arose because that isn't the case
Dec 01 16:10:01 <dwmw2_gone> no, it's still true that for br2684, if no MAC address is provided, it makes sense to try the ESI
Dec 01 16:10:11 <dwmw2_gone> it *might* be good
Dec 01 16:10:23 <dwmw2_gone> of course, if a MAC address *is* provided, you use it.
Dec 01 16:10:38 <dwmw2_gone> but it doesn't make sense to ignore the ESI, if no explicit MAC address is given by userspace
Dec 01 16:11:07 <dwmw2_gone> if there *is* a sane ESI, you should use it. And if it's not sane, and you haven't got one explicitly provided, what else can you do?
Dec 01 16:11:09 <DonkeyHotei> assuming the esi is good, where did that esi come from, initially?
Dec 01 16:12:12 <dwmw2_gone> EEPROM on the ATM card, typically
Dec 01 16:12:24 <dwmw2_gone> same answer as for Ethernet devices, really.
Dec 01 16:12:40 <dwmw2_gone> except on embedded devices they don't like to scatter little EEPROMs all over the place; it adds to the BOM
Dec 01 16:12:53 <dwmw2_gone> so it ends up being stored as a parameter in the main flash... and here we are.
Dec 01 16:13:07 <DonkeyHotei> i'm assuming solos-pci has the eeprom...
Dec 01 16:13:11 <dwmw2_gone> nope
Dec 01 16:13:19 <dwmw2_gone> nobody's ever cared about the MAC address of br2684 though :)
Dec 01 16:13:32 <DonkeyHotei> so, the geos has this problem too?
Dec 01 16:13:44 <dwmw2_gone> solos-pci certainly *could* store an ESI. Although I think Traverse would have to pay to have some numbers allocated, and those aren't cheap
Dec 01 16:13:53 <dwmw2_gone> they haven't even got a PCI ID of their own for it :)
Dec 01 16:14:16 <dwmw2_gone> if used in one of the rare situations where the MAC is actually important, then yes. Geos would have the same problem
Dec 01 16:14:21 <dwmw2_gone> has never happened yet, as far as I'm aware.
Dec 01 16:14:26 <DonkeyHotei> they aleady have macs for their ethernet, do they not?
Dec 01 16:14:37 <dwmw2_gone> this is solos-pci really, not particularly Geos. Geos is just an AMD Geode board with a solos-pci on board.
Dec 01 16:14:52 <dwmw2_gone> Not sure if they buy the chips with them
Dec 01 16:14:54 <dwmw2_gone> will ask
Dec 01 16:15:10 <DonkeyHotei> i was unable to find a non-geos solos-pci card
Dec 01 16:15:29 <dwmw2_gone> 00:0A:FA:22:00:96
Dec 01 16:15:41 <dwmw2_gone> define 'find'
Dec 01 16:15:56 <dwmw2_gone> 'obtain'?
Dec 01 16:16:04 <DonkeyHotei> i googled for such a thing, came up empty
Dec 01 16:16:10 <dwmw2_gone> http://www.traverse.com.au/distributors
Dec 01 16:16:22 <dwmw2_gone> linitx.com used to have them
Dec 01 16:16:25 <dwmw2_gone> not sure if they still do
Dec 01 16:16:53 <DonkeyHotei> i was assuming those were geos distributors, not solos, because solos is not mentioned separately at all on the traverse website
Dec 01 16:17:49 <dwmw2_gone> http://www.rocksolidelectronics.com/pages/products/s2.php
Dec 01 16:18:54 <DonkeyHotei> i don't see the name solos anywhere in that
Dec 01 16:19:32 <dwmw2_gone> nonetheless, that's a solos :)
Dec 01 16:20:35 <DonkeyHotei> ok
Dec 01 16:20:46 <DonkeyHotei> i wonder whether it has an eeprom
Dec 01 16:23:06 <dwmw2_gone> http://www.coffer.com/mac_find/?string=00%3A0A%3AFA%3A22%3A00%3A97
Dec 01 16:23:23 <dwmw2_gone> looks like the MAC addresses are their own (Traverse)
Dec 01 16:23:28 <dwmw2_gone> so they could assign them to the solos too
Dec 01 16:23:34 <dwmw2_gone> assuming they have enough
Dec 01 16:24:10 <DonkeyHotei> i haven't looked at the solos driver; does it attempt to get an esi anywhere?
Dec 01 16:24:23 <dwmw2_gone> no, because we know there is none.
Dec 01 16:24:38 <DonkeyHotei> even on the rocksolid s2 card?
Dec 01 16:24:49 <dwmw2_gone> it's the same thing
Dec 01 16:25:13 <DonkeyHotei> [Sat 2012-12-01 08:12:13 AM PST] <dwmw2_gone> EEPROM on the ATM card, typically
Dec 01 16:25:22 <DonkeyHotei> so, not quite
Dec 01 16:25:25 <dwmw2_gone> typically.
Dec 01 16:25:32 <dwmw2_gone> the solos-pci ADSL board is *not* a typical ATM device.
Dec 01 16:25:37 <DonkeyHotei> true
Dec 01 16:26:00 <dwmw2_gone> I've just mailed Traverse. They may be able to assign ESI to their ATM devices.
Dec 01 16:26:06 <dwmw2_gone> it's a fairly esoteric requirement though
Dec 01 16:26:17 <dwmw2_gone> *most* people using ADSL do PPP over it.
Dec 01 16:26:32 <DonkeyHotei> but then, typical atm devices won't have need of br2684
Dec 01 16:26:33 <dwmw2_gone> so it might not turn out to be a good use of their resources. I bet Ethernet address ranges aren't cheap
Dec 01 16:26:44 <dwmw2_gone> the ESI is used for other things... presumably
Dec 01 16:26:51 <dwmw2_gone> I haven't much experience of non-ADSL ATM
Dec 01 16:27:20 <DonkeyHotei> well, they could just make the mac consecutive with the ethernet, the way pretty much every dsl router seems to already do
Dec 01 16:27:35 <dwmw2_gone> it's still from their range of addresses.
Dec 01 16:27:44 <dwmw2_gone> that means they can only assign every other address, not every address.
Dec 01 16:28:00 <DonkeyHotei> they have at least 16.7 billion
Dec 01 16:28:15 <dwmw2_gone> if they ship a box using address N for the Ethernet and address N+1 for the ATM,
Dec 01 16:28:17 <DonkeyHotei> i mean million, sorry
Dec 01 16:28:36 <dwmw2_gone> I was lopping zeroes off anyway to translate to English.
Dec 01 16:28:45 <dwmw2_gone> billion/milliard/million :)
Dec 01 16:29:27 <DonkeyHotei> u.s. billion = u.k. milliard, but i thought a million was a million
Dec 01 16:29:29 <dwmw2_gone> but yes, that's a lot of MAC addresses
Dec 01 16:29:38 <dwmw2_gone> yeah
Dec 01 16:29:57 <dwmw2_gone> it is. But I was looking at what you said and just thinking 'fewer zeroes'...
Dec 01 16:30:04 <DonkeyHotei> ok
Dec 01 16:30:23 <dwmw2_gone> the point is the same. They have a metric shitload of MAC addresses. This is a low-volume device.
Dec 01 16:30:31 <dwmw2_gone> I bet they can manage to assign addresses to the ATM devices too
Dec 01 16:30:45 <dwmw2_gone> we just need to come up with a way to store them (in the FPGA flash, I would recommend) and to read them back out again.
Dec 01 16:31:05 <DonkeyHotei> yes, but that would need driver support
Dec 01 16:31:17 <dwmw2_gone> that's the easy part.
Dec 01 16:31:33 <DonkeyHotei> so there goes your argument against hacking every atm driver out there
Dec 01 16:31:54 <DonkeyHotei> because that would leave just ifxmips the odd one out
Dec 01 16:34:15 <dwmw2_gone> no
Dec 01 16:34:29 <dwmw2_gone> I'm talking about *fixing* the solos driver to get the address from the *device* as $DEITY intended
Dec 01 16:34:37 <dwmw2_gone> not to get it from somewhere external
Dec 01 16:35:41 <DonkeyHotei> the device can be either a card or the whole embedded device
Dec 01 16:35:57 <dwmw2_gone> no, in this context the device is the specific device that is owned by a device driver.
Dec 01 16:36:19 <DonkeyHotei> oh.
Dec 01 16:36:21 <dwmw2_gone> I'm basically suggesting that we fix the solos-pci hardware so it actually *does* store its own address.
Dec 01 16:36:49 <dwmw2_gone> same for the solos-pci discrete card as for the solos-pci which is glued to the geos mainboard.
Dec 01 16:37:02 <DonkeyHotei> a good thing, but as you said, not every device can do more than put it in external flash
Dec 01 16:37:05 <dwmw2_gone> there's flash onboard
Dec 01 16:37:44 <dwmw2_gone> yes. We need a generic way for a kernel to override MAC addresses for Ethernet devices, based on something from the uboot environment or something like that.
Dec 01 16:37:49 <dwmw2_gone> and we *have* that
Dec 01 16:38:00 <dwmw2_gone> all we need to do it *use* it for br2684, and we're done.
Dec 01 16:38:22 <dwmw2_gone> it doesn't live in the drivers themselves, or in br2684. Let userspace handle it all.
Dec 01 16:38:54 <DonkeyHotei> i'm sorry, i guess i've been tainted by trying to have done this for wifi to no avail
Dec 01 16:39:09 <dwmw2_gone> what's the problem with wifi
Dec 01 16:39:18 <dwmw2_gone> does 'ip link set wlan0 addr foo' not work?
Dec 01 16:39:23 <DonkeyHotei> because when there is a phy involved, there is a phy mac that nl doesn't see
Dec 01 16:39:25 <dwmw2_gone> the phy doesn't pick up the change?
Dec 01 16:39:31 <DonkeyHotei> lemme get you a link
Dec 01 16:39:53 <dwmw2_gone> that's a driver issue, surely? If the MAC address on the wlan interface changes, the phy should notice and behave appropriately (or veto the change if it can't behave appropriately)
Dec 01 16:40:02 <dwmw2_gone> sounds like a wifi driver (or stack) bug to me.
Dec 01 16:41:58 <DonkeyHotei> http://sourceforge.net/projects/acx100/forums/forum/257272/topic/5016625
Dec 01 16:42:24 <DonkeyHotei> if you follow the discussion, you see different drivers compared to each other
Dec 01 16:42:34 <DonkeyHotei> rt73 and acx, in this case
Dec 01 16:42:49 <dwmw2_gone> ick. I was hoping for a link to the linux-wireless mailing list not a random web forum :)
Dec 01 16:43:16 <dwmw2_gone> first four posts on that patch seem to suggest a bug report, a commit fixing it, and a happy test
Dec 01 16:43:23 <DonkeyHotei> acx is still out-of-tree, so no such luck
Dec 01 16:43:32 <DonkeyHotei> keep reading
Dec 01 16:44:57 <dwmw2_gone> followed by some head-scratching, eventually another patch and the final post being another happy test
Dec 01 16:45:08 <dwmw2_gone> basically a driver was buggy and now it (hopefully) is not
Dec 01 16:45:23 <dwmw2_gone> yes, changing MAC on a wifi device is slightly less trivial than it is on wired (including br2684)
Dec 01 16:46:22 <DonkeyHotei> the being less trivial was what pissed me off the first time i looked at the ifxmips atm driver
Dec 01 16:46:22 <dwmw2_gone> one buggy driver shouldn't necessarily affect our discussion about how this stuff *should* be handled
Dec 01 16:47:30 <DonkeyHotei> the nature of the bug in the thread stemmed directly from the less-trivial nature of changing macs with a phy around
Dec 01 16:48:31 <DonkeyHotei> dealing with that before seeing ifxmips's complete lack of esi tainted my thinking
Dec 01 17:03:31 <OpenWrt-Commits> cshore r34433 packages/net/rp-pppoe/patches/100-configure.patch
Dec 01 17:03:31 <OpenWrt-Commits> [packages] rp-pppoe: Fix configure test for kernel mode pppoe header which fails due to bad includes in configure test
Dec 01 17:05:42 <DonkeyHotei> dwmw2_gone: so, i've lost track: which part did you say you'll do?
Dec 01 22:06:48 <russell--> the uci utility on x86-generic seems to throw a bunch of debugging output
Dec 01 22:08:07 <russell--> i don't see the same thing on recent x86-alix2
Dec 01 22:09:53 <OpenWrt-Commits> swalker r34434 packages/net/tor-alpha/Makefile
Dec 01 22:09:53 <OpenWrt-Commits> [packages] tor-alpha: update to 0.2.4.6-alpha, remove libevent2-openssl bufferevents dependency missed in r32391, add libssp dependency if enabled
Dec 01 22:10:50 <OpenWrt-Commits> swalker r34435 packages/net/tor/ Makefile patches/001-torrc.patch
Dec 01 22:10:50 <OpenWrt-Commits> [packages] tor: update to 0.2.3.25, add fw-helper package & package descriptions, add libssp dependency if enabled
Dec 01 23:05:18 <russell--> this is what it looks like: http://sprunge.us/GPaY
Dec 01 23:13:48 <russell--> UCI_DEBUG:BOOL=ON
Dec 01 23:15:39 <dwmw2_gone> DonkeyHotei: well, I was half-way through adding 'ethtool -i' support to br2684, so we could use the VCC information (device, vci, vpi) much the same as we'd use PCI slot# information to uniquely identify the Ethernet "device"
Dec 01 23:15:53 <dwmw2_gone> DonkeyHotei: but then I realised that at the time the nas%d device is created, the VC isn't *connected*
Dec 01 23:15:58 <dwmw2_gone> so we won't have that information
Dec 01 23:16:10 <dwmw2_gone> and I realised that we (can) explicitly create it with a name of our choosing.
Dec 01 23:16:26 <dwmw2_gone> so I figured the *name* of the device would be perfectly sufficient to look it up and apply the chosen MAC address.
Dec 01 23:16:47 <dwmw2_gone> and that's something that a generic MAC-setting setup (such as openwrt *ought* to have) ought to cope with anyway.
Dec 01 23:17:15 <dwmw2_gone> but if you want to patch br2684ctl to apply a certain MAC address between creating and connecting the vcc, that would also work
Dec 01 23:17:25 <dwmw2_gone> I'd prefer to leave it to the generic MAC-setting code though.
Dec 01 23:18:50 <russell--> hmm, i must have built uci with DEBUG=1 at some point
Dec 01 23:18:58 <russell--> {clean,compile} fixes
Dec 01 23:22:01 <DonkeyHotei> dwmw2_gone: i was trying to make all that clear, but being clear is not a forte of mine
Dec 01 23:26:39 <dwmw2_gone> on the acx thing:
Dec 01 23:26:41 <dwmw2_gone> [Sat01-23:12] <johill> 20:13:05> dwmw2_gone: of course it should work
Dec 01 23:26:41 <dwmw2_gone> [Sat01-23:12] <johill> 20:14:16> dwmw2_gone: but if some driver is stupid and uses perm_addr or something it'll mess up and nothing will work right
Dec 01 23:27:12 <dwmw2_gone> [Sat01-23:13] <dwmw2_gone> johill: sounds about right. http://sourceforge.net/projects/acx100/forums/forum/257272/topic/5016625
Dec 01 23:27:12 <dwmw2_gone> [Sat01-23:13] <dwmw2_gone>  - SET_IEEE80211_PERM_ADDR(adev->ieee, adev->dev_addr); + //SET_IEEE80211_PERM_ADDR(adev->ieee, adev->dev_addr);
Dec 01 23:27:12 <dwmw2_gone> [Sat01-23:21] <johill> dwmw2_gone: well acx100 ... :)
Dec 01 23:27:12 <dwmw2_gone> [Sat01-23:21] <johill> but that patch seems pointless
Dec 01 23:27:13 <dwmw2_gone> [Sat01-23:22] <johill> SET_IEEE80211_PERM_ADDR just sets the address we advertise first
Dec 01 23:27:15 <dwmw2_gone> [Sat01-23:22] <johill> it has no runtime effect
Dec 01 23:27:17 <dwmw2_gone> [Sat01-23:23] <johill> oh he modifies it in add_itnerface
Dec 01 23:27:19 <dwmw2_gone> [Sat01-23:23] <johill> well that's ... stupid
Dec 01 23:27:21 <dwmw2_gone> [Sat01-23:23] <johill> reading docs might be helpfup
Dec 01 23:55:05 <DonkeyHotei> dwmw2_gone: well, AFAICT he fixed it anyway
Dec 01 23:55:19 <Wipster> Regarding #7552, if hostapd's supported_rates option is exposed through uci would that work to solve the constant b43 dropouts when transitioning between OFDM and CCK
Dec 02 01:04:05 <Weedy_lappy> you guys building trunk?
Dec 02 01:04:20 <Weedy_lappy> I can't get it to build for likw 2 weeks
Dec 02 01:04:40 <Weedy_lappy> [  5%] Building C object CMakeFiles/netifd.dir/main.c.o
Dec 02 01:04:40 <Weedy_lappy> In file included from /home/weedy/projects/openwrt/build_dir/target-mips_r2_uClibc-0.9.33.2/netifd-2012-10-29/main.c:23:0:
Dec 02 01:04:43 <Weedy_lappy> /home/weedy/projects/openwrt/build_dir/target-mips_r2_uClibc-0.9.33.2/netifd-2012-10-29/netifd.h:24:29: fatal error: libubox/ustream.h: No such file or directory
Dec 02 01:04:46 <Weedy_lappy> compilation terminated.
Dec 02 01:04:49 <Weedy_lappy> make[6]: *** [CMakeFiles/netifd.dir/main.c.o] Error 1
**** ENDING LOGGING AT Sun Dec 02 02:59:59 2012