Bug#428302: [pkg-wpa-devel] Bug#428302: when using wpa-bridge in /etc/network/interfaces, interface should be added to bridge
On Wed, 13 Jun 2007 09:13:28 am Elmar Hoffmann wrote: Hi Kel, on Mon, Jun 11, 2007 at 12:29:04 +1000, you wrote: This is the design of ifupdown. wpasupplicant package should not try to do the job of bridge-utils ifupdown hook. If the relationship between the two hooks is not flexible then I see no point in assimilating partial operation of one script into another. Bigger changes are required in this case. I do agree that the bridge-utils hooks have their logic kind of backwards in requiring to specify interfaces of the ports in the bridge interface stanza instead of allowing to specify the bridge in the stanza of the port interface and should be fixed. I planned to pursue that issue, too, anyway. The reason I did report this bug nonetheless is that, assuming the bridge-utils hooks were extended to have some bridge-* option to specify the bridge interface, that option and the wpa-bridge option would (have to) carry duplicate information and users had to make sure both stay in sync. So I thought, it would make sense to avoid that - much like one does not have to specify both madwifi-mode and wireless-mode options either. But I guess, again assuming bridge-utils hooks are extended to have that option, it would be ok for your to have the wpasupplicant hooks understand that option too and not require wpa-bridge? That would be nicer than attempting to manage the bridged interfaces over-simplisticly by the wpasupplicant hook alone. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428302: [pkg-wpa-devel] Bug#428302: when using wpa-bridge in /etc/network/interfaces, interface should be added to bridge
Hi Kel, on Mon, Jun 11, 2007 at 12:29:04 +1000, you wrote: This is the design of ifupdown. wpasupplicant package should not try to do the job of bridge-utils ifupdown hook. If the relationship between the two hooks is not flexible then I see no point in assimilating partial operation of one script into another. Bigger changes are required in this case. I do agree that the bridge-utils hooks have their logic kind of backwards in requiring to specify interfaces of the ports in the bridge interface stanza instead of allowing to specify the bridge in the stanza of the port interface and should be fixed. I planned to pursue that issue, too, anyway. The reason I did report this bug nonetheless is that, assuming the bridge-utils hooks were extended to have some bridge-* option to specify the bridge interface, that option and the wpa-bridge option would (have to) carry duplicate information and users had to make sure both stay in sync. So I thought, it would make sense to avoid that - much like one does not have to specify both madwifi-mode and wireless-mode options either. But I guess, again assuming bridge-utils hooks are extended to have that option, it would be ok for your to have the wpasupplicant hooks understand that option too and not require wpa-bridge? elmar -- .'`./\ | :' : Elmar Hoffmann [EMAIL PROTECTED]ASCII Ribbon Campaign \ / `. `'GPG key available via pgp.netagainst HTML email X `- vCards / \ signature.asc Description: Digital signature
Bug#428302: [pkg-wpa-devel] Bug#428302: when using wpa-bridge in /etc/network/interfaces, interface should be added to bridge
tags 428302 - patch tags 428302 wontfix thanks Hi Elmar, On Mon, 11 Jun 2007 01:50:50 am Elmar Hoffmann wrote: When using wpa-bridge in /etc/network/interfaces, the interface should be added to the bridge before wpa_supplicant is started. Relying on the bridge to be configured via /etc/network/interfaces soon enough after the wireless interface(s) and being forced to ifdown and ifup the whole bridge (eventually including the wired interface over which you ssh'ed in...) does not seem right and is quite inflexible. This is the design of ifupdown. wpasupplicant package should not try to do the job of bridge-utils ifupdown hook. If the relationship between the two hooks is not flexible then I see no point in assimilating partial operation of one script into another. Bigger changes are required in this case. The attached patch fixes this. Nack. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
