astlinux-devel Mailing List for AstLinux

On May 10, 2009, at 1:28 PM, Philip A. Prindeville wrote:

> Bridges on the WAN side are handy for hooking up recorders and/or
> analyzers (aka "the FBI tap", or "intercept access point").
>
> -Philip

Question, if a EXTIF="br0" and BRIDGE0="eth0 eth1" and connected to a  
cable modem, how many MAC addresses would the cable modem see? One or  
Two ?

I ask, since if it is 'two' that probably would mess-up the STATIC IP  
pool that the cable modem is provisioned for, since the modem attaches  
itself to the first MAC's it arps.

Lonnie

Thanks, I didn't think of adding INTIF= to the user.conf file. That is a
satisfactory work around for the few times that I need to do it.

On Sat, May 9, 2009 at 8:41 PM, Lonnie Abelbeck
<li...@lo...>wrote:

> Thanks again for the suggestions, much appreciated by the development
> team...
>
> Yes, bridges are a can-of-worms to support in the GUI.
>
> I could filter the interface drop-down list, but when going from bridge to
> non-bridge, this is undesirable.
>
> The drop-down for the interfaces are very convenient, but the interfaces
> must be defined to generate the list, so VLAN's and Bridges require a reboot
> to appear in the GUI interface drop-downs.
>
> One tip when generating a bridge...
> --- user.conf ---
> BRIDGE1="eth1 eth2"
> INTIF="br1" # assuming the 1st internal interface was defined before
> ---
> then you only have to reboot once, but after the reboot, you need to change
> the Network tab to "br1" and remove the INTIF="br1", this is confusing I
> know, but works around the issues you described.
>
> David, my biggest hurdle with GUI support for bridges, it must be a very
> special-special case to require the need to use them.  I know Philip uses
> them, but he is not a typical user by any stretch :-)
>
> I guess if you have a N-port switch and you need N+1 ports, a bridge could
> save the day, though unlikely.
>
> Adding any options to the Network tab incrementally makes it harder to use,
> so any new additions must have an overriding benefit for the user.  If you
> could convince me that bridge support is of general interest, I'll take a
> harder look at the GUI issues with it.
>
> Lonnie
>
>
>
> On May 9, 2009, at 10:21 AM, David Kerr wrote:
>
>  Configuring a bridged interface is somewhat awkward and I think it could
>> be made much easier with a few tweaks to the GUI.  The way you have to do it
>> right now is edit the user config file and add the line
>>  BRIDGE1="eth1 eth2"
>> Then in the GUI Network page select "br1" from the drop down list of LAN
>> interfaces.
>>
>> The problem is that the drop down list does not contain "br1" until after
>> the bridge has been setup... which requires a reboot (or maybe there is a
>> way to do it without a reboot, but I don't know how). The situation is
>> further complicated because I find that after the bridge is setup, the eth1
>> and eth2 interfaces no longer work. So you cannot connect a browser to the
>> GUI through those interfaces. I end up having to connect to serial port and
>> manually editing the network config file and rebooting again.
>>
>> Problem is not so pronounced when going from bridged to non-bridged
>> configuration as you can delete the bridge statement and select "eth1" or
>> whatever without intervening reboot.
>>
>> So, Lonnie, how hard would it be to fix this in the GUI by providing a way
>> to setup a bridged interface without having to edit the user config, and
>> having the GUI be smart enough to allow selection of "br1" if a bridge is
>> being setup.  I'm thinking of a field under the "internal interfaces"
>> heading and before the list of 1st/2nd/3rd interface drop downs. A checkbox
>> followed by an entryfield (or multiple selection list). If checkbox
>> selected, the GUI would write the BRIDGE1="whatever in entry field" and then
>> add "br1" to internal interface drop downs (perhaps even removing the
>> interfaces that were selected for the bridge from the list).
>>
>> by-the-way... is it legal to have multiple interfaces pointing to the same
>> network adapter?  The GUI appears to permit this. For example both external
>> and internal interfaces pointing to eth0.  Or multiple internal interfaces
>> pointing to eth1.
>>
>>
>> David.
>>
>
>
>
>

Does anyone have the capability of building 2652 and testing WEP?

I've only tested WPA2.

Enable "hidden" and "rekey" as options if you can.

Thanks,

-Philip

Bridges on the WAN side are handy for hooking up recorders and/or
analyzers (aka "the FBI tap", or "intercept access point").

-Philip


Lonnie Abelbeck wrote:
> Thanks again for the suggestions, much appreciated by the development  
> team...
>
> Yes, bridges are a can-of-worms to support in the GUI.
>
> I could filter the interface drop-down list, but when going from  
> bridge to non-bridge, this is undesirable.
>
> The drop-down for the interfaces are very convenient, but the  
> interfaces must be defined to generate the list, so VLAN's and Bridges  
> require a reboot to appear in the GUI interface drop-downs.
>
> One tip when generating a bridge...
> --- user.conf ---
> BRIDGE1="eth1 eth2"
> INTIF="br1" # assuming the 1st internal interface was defined before
> ---
> then you only have to reboot once, but after the reboot, you need to  
> change the Network tab to "br1" and remove the INTIF="br1", this is  
> confusing I know, but works around the issues you described.
>
> David, my biggest hurdle with GUI support for bridges, it must be a  
> very special-special case to require the need to use them.  I know  
> Philip uses them, but he is not a typical user by any stretch :-)
>
> I guess if you have a N-port switch and you need N+1 ports, a bridge  
> could save the day, though unlikely.
>
> Adding any options to the Network tab incrementally makes it harder to  
> use, so any new additions must have an overriding benefit for the  
> user.  If you could convince me that bridge support is of general  
> interest, I'll take a harder look at the GUI issues with it.
>
> Lonnie
>
>
> On May 9, 2009, at 10:21 AM, David Kerr wrote:
>
>   
>> Configuring a bridged interface is somewhat awkward and I think it  
>> could be made much easier with a few tweaks to the GUI.  The way you  
>> have to do it right now is edit the user config file and add the line
>>   BRIDGE1="eth1 eth2"
>> Then in the GUI Network page select "br1" from the drop down list of  
>> LAN interfaces.
>>
>> The problem is that the drop down list does not contain "br1" until  
>> after the bridge has been setup... which requires a reboot (or maybe  
>> there is a way to do it without a reboot, but I don't know how). The  
>> situation is further complicated because I find that after the  
>> bridge is setup, the eth1 and eth2 interfaces no longer work. So you  
>> cannot connect a browser to the GUI through those interfaces. I end  
>> up having to connect to serial port and manually editing the network  
>> config file and rebooting again.
>>
>> Problem is not so pronounced when going from bridged to non-bridged  
>> configuration as you can delete the bridge statement and select  
>> "eth1" or whatever without intervening reboot.
>>
>> So, Lonnie, how hard would it be to fix this in the GUI by providing  
>> a way to setup a bridged interface without having to edit the user  
>> config, and having the GUI be smart enough to allow selection of  
>> "br1" if a bridge is being setup.  I'm thinking of a field under the  
>> "internal interfaces" heading and before the list of 1st/2nd/3rd  
>> interface drop downs. A checkbox followed by an entryfield (or  
>> multiple selection list). If checkbox selected, the GUI would write  
>> the BRIDGE1="whatever in entry field" and then add "br1" to internal  
>> interface drop downs (perhaps even removing the interfaces that were  
>> selected for the bridge from the list).
>>
>> by-the-way... is it legal to have multiple interfaces pointing to  
>> the same network adapter?  The GUI appears to permit this. For  
>> example both external and internal interfaces pointing to eth0.  Or  
>> multiple internal interfaces pointing to eth1.
>>
>>
>> David.
>>     

On May 10, 2009, at 1:40 AM, Philip A. Prindeville wrote:

> Darrick Hartman wrote:
>> Lonnie Abelbeck wrote:
>>
>>> Since dnsmasq is now always started, should TFTPD default to
>>> TFTPD=dnsmasq instead of inetd ?
>>>
>>> Dnsmasq's TFTP has more features and is read-only, perfect for IP
>>> Phones.
>>>
>>> I recall Kristian changing this to dnsmasq until he remembered  
>>> dnsmasq
>>> was not always running:
>>> http://astlinux.svn.sourceforge.net/viewvc/astlinux/branches/0.6/target/generic/target_skeleton/stat/etc/rc.conf?r1=1837&r2=1846
>>>
>>
>> It does simplify things and allow us to remove the separate tftpd
>> binary.  I have no objections.
>>
>
> I need to be able to save out config files via TFTP from phones.
>
> -Philip

OK, lets make TFTPD=dnsmasq the default in /stat/etc/rc.conf, but  
leave the tftpd binary for those that may need to write to the server  
via TFTP.

Lonnie

Darrick Hartman wrote:
> Lonnie Abelbeck wrote:
>   
>> Since dnsmasq is now always started, should TFTPD default to  
>> TFTPD=dnsmasq instead of inetd ?
>>
>> Dnsmasq's TFTP has more features and is read-only, perfect for IP  
>> Phones.
>>
>> I recall Kristian changing this to dnsmasq until he remembered dnsmasq  
>> was not always running:
>> http://astlinux.svn.sourceforge.net/viewvc/astlinux/branches/0.6/target/generic/target_skeleton/stat/etc/rc.conf?r1=1837&r2=1846
>>     
>
> It does simplify things and allow us to remove the separate tftpd 
> binary.  I have no objections.
>   

I need to be able to save out config files via TFTP from phones.

-Philip

Lonnie Abelbeck wrote:
> Since dnsmasq is now always started, should TFTPD default to  
> TFTPD=dnsmasq instead of inetd ?
> 
> Dnsmasq's TFTP has more features and is read-only, perfect for IP  
> Phones.
> 
> I recall Kristian changing this to dnsmasq until he remembered dnsmasq  
> was not always running:
> http://astlinux.svn.sourceforge.net/viewvc/astlinux/branches/0.6/target/generic/target_skeleton/stat/etc/rc.conf?r1=1837&r2=1846

It does simplify things and allow us to remove the separate tftpd 
binary.  I have no objections.

Since dnsmasq is now always started, should TFTPD default to  
TFTPD=dnsmasq instead of inetd ?

Dnsmasq's TFTP has more features and is read-only, perfect for IP  
Phones.

I recall Kristian changing this to dnsmasq until he remembered dnsmasq  
was not always running:
http://astlinux.svn.sourceforge.net/viewvc/astlinux/branches/0.6/target/generic/target_skeleton/stat/etc/rc.conf?r1=1837&r2=1846

Lonnie

On May 9, 2009, at 10:21 AM, David Kerr wrote:
> by-the-way... is it legal to have multiple interfaces pointing to  
> the same network adapter?  The GUI appears to permit this. For  
> example both external and internal interfaces pointing to eth0.  Or  
> multiple internal interfaces pointing to eth1.

I forgot to answer this question...

When you click "Save Settings" in the Network tab, you will get an  
error message if the same interface is used more than once... among  
other possible errors.

Lonnie

Thanks again for the suggestions, much appreciated by the development  
team...

Yes, bridges are a can-of-worms to support in the GUI.

I could filter the interface drop-down list, but when going from  
bridge to non-bridge, this is undesirable.

The drop-down for the interfaces are very convenient, but the  
interfaces must be defined to generate the list, so VLAN's and Bridges  
require a reboot to appear in the GUI interface drop-downs.

One tip when generating a bridge...
--- user.conf ---
BRIDGE1="eth1 eth2"
INTIF="br1" # assuming the 1st internal interface was defined before
---
then you only have to reboot once, but after the reboot, you need to  
change the Network tab to "br1" and remove the INTIF="br1", this is  
confusing I know, but works around the issues you described.

David, my biggest hurdle with GUI support for bridges, it must be a  
very special-special case to require the need to use them.  I know  
Philip uses them, but he is not a typical user by any stretch :-)

I guess if you have a N-port switch and you need N+1 ports, a bridge  
could save the day, though unlikely.

Adding any options to the Network tab incrementally makes it harder to  
use, so any new additions must have an overriding benefit for the  
user.  If you could convince me that bridge support is of general  
interest, I'll take a harder look at the GUI issues with it.

Lonnie


On May 9, 2009, at 10:21 AM, David Kerr wrote:

> Configuring a bridged interface is somewhat awkward and I think it  
> could be made much easier with a few tweaks to the GUI.  The way you  
> have to do it right now is edit the user config file and add the line
>   BRIDGE1="eth1 eth2"
> Then in the GUI Network page select "br1" from the drop down list of  
> LAN interfaces.
>
> The problem is that the drop down list does not contain "br1" until  
> after the bridge has been setup... which requires a reboot (or maybe  
> there is a way to do it without a reboot, but I don't know how). The  
> situation is further complicated because I find that after the  
> bridge is setup, the eth1 and eth2 interfaces no longer work. So you  
> cannot connect a browser to the GUI through those interfaces. I end  
> up having to connect to serial port and manually editing the network  
> config file and rebooting again.
>
> Problem is not so pronounced when going from bridged to non-bridged  
> configuration as you can delete the bridge statement and select  
> "eth1" or whatever without intervening reboot.
>
> So, Lonnie, how hard would it be to fix this in the GUI by providing  
> a way to setup a bridged interface without having to edit the user  
> config, and having the GUI be smart enough to allow selection of  
> "br1" if a bridge is being setup.  I'm thinking of a field under the  
> "internal interfaces" heading and before the list of 1st/2nd/3rd  
> interface drop downs. A checkbox followed by an entryfield (or  
> multiple selection list). If checkbox selected, the GUI would write  
> the BRIDGE1="whatever in entry field" and then add "br1" to internal  
> interface drop downs (perhaps even removing the interfaces that were  
> selected for the bridge from the list).
>
> by-the-way... is it legal to have multiple interfaces pointing to  
> the same network adapter?  The GUI appears to permit this. For  
> example both external and internal interfaces pointing to eth0.  Or  
> multiple internal interfaces pointing to eth1.
>
>
> David.