astlinux-devel Mailing List for AstLinux

Once the roadwarrior support is finalized in trunk we'll branch to 0.7.  In any case look for a 0.6.6 with the only change being Asterisk 1.4.25. 

0.6 will be maintained only for security issues. There are some steps required when migrating to 0.7 so we don't want to leave people hanging.  

Darrick

On Fri, 22 May 2009 09:57:47 -0500, David Kerr wrote:
> Why not create a 0.7 branch now and do the final polishing for 0.7 on that
> branch, leaving the trunk for ongoing development.
> As for uclibc/eglibc, I would vote for eglibc as binary compatibility with
> the digium add-ons is attractive to me.
> 
> David
> 
> 
> On Fri, May 22, 2009 at 10:20 AM, Darrick Hartman <dha...@dj...
> > wrote:
> 
> > On 05/22/2009 12:42 AM, Philip A. Prindev> > > I started looking at a version bump for uClibc from 0.9.28 to 0.9.30.
> > >
> > > All of the patches delete...  that's simple enough...
> > >
> > > But there's a whole slew of build options for UCLIBC functionality that
> > > I'm not entirely clear on.
> > >
> > > Anyway, was wondering if anyone had any experience with it, or had any
> > > time to dig into this and do a little research.  It's a blocking issue
> > > for Asterisk 1.6.
> > >
> >
> > Philip,
> >
> > I would urge you strongly to consider holding off on the bump to uClibc
> > for the following reasons:
> >
> > 1).  We nearly have a stable release coming out of trunk.  I believe the
> > only thing we want to finish up is the road-warrior support for IPsec.
> >
> > 2).  We might want to look at eglibc instead of uClibc.  eglibc [1] [2]
> > would allow us to have binary compatibility with glibc.  That would
> > allow codec_g729.so, chan_skype.so, the new Digium fax stuff to all work
> > with Astlinux.  As long as the resulting binaries are similar in size,
> > it would be worthy of looking at.
> >
> > 3).  If you must explore this right now, please create a new branch to
> > do so or use the asterisk-beta branch.  This process will be a huge
> > interruption and may break things for a lon> >
> > I'd be happy to take a look at this when I get back from vacation.  I
> > started playing with eglibc based on the work that is in the openwrt svn
> > repository.  Upgrading to uClibc or moving to eglibc will both be
> > potentially long processes and may impact many more packages than you
> > think right now.
> >
> > Darrick
> >
> > [1]:  http://www.eglibc.org/
> > [2]:  http://lwn.net/SubscriberLink/333755/ddafee65c3805a7a/
> >
> >
> > ------------------------------------------------------------------------------
> > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> > is a gathering of tech-side developers & brand creativity professionals.
> > Meet
> > the minds behind Google Creative Lab, Visual Complexity, Processing, &
> > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> > Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> > pa...@kr....
> >

Why not create a 0.7 branch now and do the final polishing for 0.7 on that
branch, leaving the trunk for ongoing development.
As for uclibc/eglibc, I would vote for eglibc as binary compatibility with
the digium add-ons is attractive to me.

David


On Fri, May 22, 2009 at 10:20 AM, Darrick Hartman <dha...@dj...
> wrote:

> On 05/22/2009 12:42 AM, Philip A. Prindeville wrote:
> > I started looking at a version bump for uClibc from 0.9.28 to 0.9.30.
> >
> > All of the patches delete...  that's simple enough...
> >
> > But there's a whole slew of build options for UCLIBC functionality that
> > I'm not entirely clear on.
> >
> > Anyway, was wondering if anyone had any experience with it, or had any
> > time to dig into this and do a little research.  It's a blocking issue
> > for Asterisk 1.6.
> >
>
> Philip,
>
> I would urge you strongly to consider holding off on the bump to uClibc
> for the following reasons:
>
> 1).  We nearly have a stable release coming out of trunk.  I believe the
> only thing we want to finish up is the road-warrior support for IPsec.
>
> 2).  We might want to look at eglibc instead of uClibc.  eglibc [1] [2]
> would allow us to have binary compatibility with glibc.  That would
> allow codec_g729.so, chan_skype.so, the new Digium fax stuff to all work
> with Astlinux.  As long as the resulting binaries are similar in size,
> it would be worthy of looking at.
>
> 3).  If you must explore this right now, please create a new branch to
> do so or use the asterisk-beta branch.  This process will be a huge
> interruption and may break things for a long, unspecified time period.
>
> I'd be happy to take a look at this when I get back from vacation.  I
> started playing with eglibc based on the work that is in the openwrt svn
> repository.  Upgrading to uClibc or moving to eglibc will both be
> potentially long processes and may impact many more packages than you
> think right now.
>
> Darrick
>
> [1]:  http://www.eglibc.org/
> [2]:  http://lwn.net/SubscriberLink/333755/ddafee65c3805a7a/
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

On 05/22/2009 12:42 AM, Philip A. Prindeville wrote:
> I started looking at a version bump for uClibc from 0.9.28 to 0.9.30.
>
> All of the patches delete...  that's simple enough...
>
> But there's a whole slew of build options for UCLIBC functionality that
> I'm not entirely clear on.
>
> Anyway, was wondering if anyone had any experience with it, or had any
> time to dig into this and do a little research.  It's a blocking issue
> for Asterisk 1.6.
>

Philip,

I would urge you strongly to consider holding off on the bump to uClibc 
for the following reasons:

1).  We nearly have a stable release coming out of trunk.  I believe the 
only thing we want to finish up is the road-warrior support for IPsec.

2).  We might want to look at eglibc instead of uClibc.  eglibc [1] [2] 
would allow us to have binary compatibility with glibc.  That would 
allow codec_g729.so, chan_skype.so, the new Digium fax stuff to all work 
with Astlinux.  As long as the resulting binaries are similar in size, 
it would be worthy of looking at.

3).  If you must explore this right now, please create a new branch to 
do so or use the asterisk-beta branch.  This process will be a huge 
interruption and may break things for a long, unspecified time period.

I'd be happy to take a look at this when I get back from vacation.  I 
started playing with eglibc based on the work that is in the openwrt svn 
repository.  Upgrading to uClibc or moving to eglibc will both be 
potentially long processes and may impact many more packages than you 
think right now.

Darrick

[1]:  http://www.eglibc.org/
[2]:  http://lwn.net/SubscriberLink/333755/ddafee65c3805a7a/

I started looking at a version bump for uClibc from 0.9.28 to 0.9.30.

All of the patches delete...  that's simple enough...

But there's a whole slew of build options for UCLIBC functionality that
I'm not entirely clear on.

Anyway, was wondering if anyone had any experience with it, or had any
time to dig into this and do a little research.  It's a blocking issue
for Asterisk 1.6.

Thanks.

-Philip

You can change the sounds you load up quite easily.

% cat ~/.asterisk.makeopts
MENUSELECT_CORE_SOUNDS=-CORE-SOUNDS-EN-G729 CORE-SOUNDS-EN-ULAW CORE-SOUNDS-EN-GSM
MENUSELECT_MOH=MOH-FREEPLAY-ULAW
MENUSELECT_EXTRA_SOUNDS=
% 


Note: sounds on the RHS prefixed with '-' are suppressed from the
default settings. Sounds without a prefix are added to the default settings.

So what you would want is:

% cat >> ~/.asterisk.makeopts
MENUSELECT_CORE_SOUNDS=-CORE-SOUNDS-EN-ULAW
MENUSELECT_EXTRA_SOUNDS=EXTRA-SOUNDS-EN-GSM
^D
% 


Simple, right?  :-)

-Philip


David Kerr wrote:
> I am using trunk...
>
> Build 2686
> On Alix 2C3
> with geni586-serial
> built excluding certain h/w modules (wifi, rhino, isdn) as I don't
> need them.
> added asterisk-extra-sounds.
>
> Used as home gateway and PBX.  All household net traffic and all
> household voice traffic goes through this box.
>
> Use...
> Asterisk, DynamicDNS, dnsmasq, arno firewall, web interface, bridge
> eth1/2 internal internal interface.
>
> Asterisk... setup with one primary trunk (several backup/test) and
> three internal extensions (Linksys/Sipura ATAs).
>
> Asterisk... Voicemail, Voice Menus, Privacy manager, Queues, etc. 
>
> I have a patch that changes the asterisk-gui to write temporary files
> to /tmp instead of writing to the static-http directory, and also
> during build to create a link to Master.csv.  Purpose is to prevent
> asterisk-gui from writing to the CF card (through unionfs) and instead
> write to ramdisk.
>
> I am working on enhancements to the CDR page in the astlinux web
> interface, but still a work in progress, nothing ready to share yet
> (learning PHP as I go).
>
> The only suggestion you have not incorporated is to remove ulaw
> versions of asterisk-sounds and add in asterisk-extra-sounds (as gsm).
>  The additional sound files are more important to me than high quality
> basic sounds. It is necessary to remove ulaw to make space for the
> additional sound files.
>
> David

Michael Keuter wrote:
>> Hi devs,
>> here ist an update of the nmap package to the latest version. I
>> optionally include some more files helpful for OS detection and
>> services versioning (this would add 1.4 MB).
>
> Hi Philip,
>
> I still found one open patch: nmap, which I sent in January.
>
> Michael
>


Fixed as 2694.

>Hi devs,
>here ist an update of the nmap package to the latest version. I 
>optionally include some more files helpful for OS detection and 
>services versioning (this would add 1.4 MB).

Hi Philip,

I still found one open patch: nmap, which I sent in January.

Michael

--
Email: mailto:mk...@we...

I am using trunk...
Build 2686
On Alix 2C3
with geni586-serial
built excluding certain h/w modules (wifi, rhino, isdn) as I don't need
them.
added asterisk-extra-sounds.

Used as home gateway and PBX.  All household net traffic and all household
voice traffic goes through this box.

Use...
Asterisk, DynamicDNS, dnsmasq, arno firewall, web interface, bridge eth1/2
internal internal interface.

Asterisk... setup with one primary trunk (several backup/test) and three
internal extensions (Linksys/Sipura ATAs).

Asterisk... Voicemail, Voice Menus, Privacy manager, Queues, etc.

I have a patch that changes the asterisk-gui to write temporary files to
/tmp instead of writing to the static-http directory, and also during build
to create a link to Master.csv.  Purpose is to prevent asterisk-gui from
writing to the CF card (through unionfs) and instead write to ramdisk.

I am working on enhancements to the CDR page in the astlinux web interface,
but still a work in progress, nothing ready to share yet (learning PHP as I
go).

The only suggestion you have not incorporated is to remove ulaw versions of
asterisk-sounds and add in asterisk-extra-sounds (as gsm).  The additional
sound files are more important to me than high quality basic sounds. It is
necessary to remove ulaw to make space for the additional sound files.

David


On Wed, May 20, 2009 at 12:48 AM, Philip A. Prindeville <
phi...@re...> wrote:

> Who is using trunk?  And is it a recent version?  What platform?  What
> functionality are you using?
>
> Do you have any patches to contribute?
>
> Thanks.
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

On May 19, 2009, at 11:48 PM, Philip A. Prindeville wrote:

>  And is it a recent version?

trunk-2690

>  What platform?

net4801 and geni586

>  What
>  functionality are you using?

Both are test boxes with Asterisk + HFC ISDN card, ntp, openvpn 
(client + server), firewall

Michael

On May 19, 2009, at 11:48 PM, Philip A. Prindeville wrote:

> Who is using trunk?

(hand is raised)

> And is it a recent version?

trunk-2688

> What platform?

net4801 and net5501

> What
> functionality are you using?

no asterisk on net4801 (ntp, openvpn, router/firewall, dynamic dns,  
etc.)

plus asterisk on net5501


Lonnie

Who is using trunk?  And is it a recent version?  What platform?  What
functionality are you using?

Do you have any patches to contribute?

Thanks.

"Alas poor Yorick, I knew him..."

I thank Kris for having written Astfw.  It served its purpose well for a
good while.  I'm glad to have been able to leverage a lot of that and
having used it as the basis for 3 different Arno plugins (SIP, DMZ-DNAT,
and TRAFFIC-SHAPER).

I'm gladder still, however, to be able to move to an off-the-shelf
product and turn over the maintenance of that to... well, myself in this
case.  :-)

But the point is that it's used and supported by a bigger audience, so
more eyes on the code.

Thanks Lonnie for retiring it with dignity.  :-)

-Philip


abe...@us... wrote:
> Revision: 2688
>           http://astlinux.svn.sourceforge.net/astlinux/?rev=2688&view=rev
> Author:   abelbeck
> Date:     2009-05-16 18:33:54 +0000 (Sat, 16 May 2009)
>
> Log Message:
> -----------
> Remove astfw and astshape, superseded by Arno's Firewall
>
> Modified Paths:
> --------------
>     trunk/package/iproute2/iproute2.mk
>     trunk/package/iptables/iptables.init
>     trunk/package/iptables/iptables.mk
>     trunk/target/generic/target_skeleton/stat/etc/rc.conf
>
> Removed Paths:
> -------------
>     trunk/package/iproute2/astshape
>     trunk/package/iproute2/astshape.init
>     trunk/package/iptables/astfw
>     trunk/target/generic/target_skeleton/etc/runlevels/custom/K24astshape
>     trunk/target/generic/target_skeleton/etc/runlevels/custom/S15astshape
>     trunk/target/generic/target_skeleton/etc/runlevels/default/K24astshape
>     trunk/target/generic/target_skeleton/etc/runlevels/default/S15astshape
>
>   

Surprise.  Wanpipe 3.4.1 is broken.

I've notified Sangoma's lead developer.  I don't know why they didn't
build this in the Astlinux trunk first.  We've even provided them logins
to one of our build servers to do so.

-Philip


Philip A. Prindeville wrote:
> I've done some work on Astlinux recently.  I've tweaked a lot of trunk
> makefiles to allow parallel builds... assuming that the original package
> was parallelization friendly (not all of them are... sigh... a lot of
> people don't know how to write makefiles properly).
>
> Ipsec-tools has been bumped to latest stable (0.7.2 from 0.7.1).
>
> Hostap has been bumped to one version short of latest stable (0.6.8 from
> 0.5.10).
>
> Libnl (netlink) has been added to support more in-kernel wireless drivers.
>
> Wireless-tools was bumped to 29 from 28.
>
> Openssl was bumped to latest stable (0.9.8k from 0.9.8j).
>
> Please let me know if anything doesn't seem to be working correctly.
>
> Wifi is working again, as long as you use the madwifi drivers.
>
> 2686 is a pretty solid build.  You might need to drop the attacked file
> into package/arnofw/arnofw-kernel_chk.patch for the next few days until
> Arno gets things straightened out...
>
> I'm just uploading wanpipe-3.4.1 right now and testing it...  should
> have a commit done within the next couple of hours...  unless Sangoma
> managed to break it (which is more often the case than not).
>
> -Philip
>
>   

I've done some work on Astlinux recently.  I've tweaked a lot of trunk
makefiles to allow parallel builds... assuming that the original package
was parallelization friendly (not all of them are... sigh... a lot of
people don't know how to write makefiles properly).

Ipsec-tools has been bumped to latest stable (0.7.2 from 0.7.1).

Hostap has been bumped to one version short of latest stable (0.6.8 from
0.5.10).

Libnl (netlink) has been added to support more in-kernel wireless drivers.

Wireless-tools was bumped to 29 from 28.

Openssl was bumped to latest stable (0.9.8k from 0.9.8j).

Please let me know if anything doesn't seem to be working correctly.

Wifi is working again, as long as you use the madwifi drivers.

2686 is a pretty solid build.  You might need to drop the attacked file
into package/arnofw/arnofw-kernel_chk.patch for the next few days until
Arno gets things straightened out...

I'm just uploading wanpipe-3.4.1 right now and testing it...  should
have a commit done within the next couple of hours...  unless Sangoma
managed to break it (which is more often the case than not).

-Philip

On May 16, 2009, at 10:11 AM, David Kerr wrote:

> Lonnie,
>   I'll test this weekend.  I like the idea of using the external IP  
> address as and alternative to a web lookup... but there is a catch.  
> What if, for testing purposes, I have to connect my box behind  
> another router and I had selected to use the external IP address.  
> Things could get messed up by setting my dynamic DNS to a non- 
> routable address.

I know ZoneEdit will not allow a Private IP address to be set, so a  
private address is ignored.

>
> So it occurred to me that an "automatic" setting might be useful.   
> If user selected this then the IP assigned to the external interface  
> would be used UNLESS that IP is within the non-routable range of  
> addresses (RFC1918)...
>   10.0.0.0 mask 10.255.255.255
>   172.16.0.0 mask 172.31.255.255
>   192.168.0.0 mask 192.168.255.255
> Or in the automatically assigned range (RFC3330)...
>   169.254.0.0 mask 169.254.255.255
>
> If the assigned IP is within any of these ranges then it is non- 
> routable and make no sense to attempt to update DNS and so astlinux  
> would then do a web lookup (to the selected server) to determine the  
> true external IP address for DNS.

Good idea, but we are patching the inadyn source to add this feature,  
and it would take a more substantial rewrite to try again via the web- 
method if a private address is returned from the external interface,  
so we did not add an 'auto' method.  The default is to use the web- 
method anyway, and that always works.

I don't think it is too much to ask the user to select "External  
Interface" only if it has a public IP address.

>
> Such an automatic option could be the most robust method.
>
> by-the-way, it would also be nice if the web interface status page  
> displayed both the external interface IP address, and the true  
> external IP (if different).

Unfortunately, inadyn hides the Public IP address internally, we could  
patch it more to make this available somehow... let's make sure what  
we have done so far works properly. :-)

>
> Regards
> David

Thanks for the ideas,
Lonnie

>
>
>
> On Thu, May 14, 2009 at 5:43 PM, Lonnie Abelbeck <li...@lo... 
> > wrote:
> Currently in trunk-2675, there has been a few changes to the Dynamic
> DNS support.
>
> One new feature is to obtain the public IP address from the external
> interface (EXTIF) instead of a web lookup to Kristian's
> getip.krisk.org.  It works in my testing, but it needs more people
> testing it.
>
> Additionally, if a web-get-ip method is required, a different server
> can now be specified.
>
> The ZoneEdit bug has been fixed, so the Web interface has done away
> with the "ZoneEdit [generic]" selection.
>
> Anyone using Dynamic DNS, please give this a try.  If you are a PPPoE
> Dynamic DNS user, please report back your results.
>
> Thanks,
> Lonnie

Lonnie,  I'll test this weekend.  I like the idea of using the external IP
address as and alternative to a web lookup... but there is a catch. What if,
for testing purposes, I have to connect my box behind another router and I
had selected to use the external IP address. Things could get messed up by
setting my dynamic DNS to a non-routable address.

So it occurred to me that an "automatic" setting might be useful.  If user
selected this then the IP assigned to the external interface would be used
UNLESS that IP is within the non-routable range of addresses (RFC1918)...
  10.0.0.0 mask 10.255.255.255
  172.16.0.0 mask 172.31.255.255
  192.168.0.0 mask 192.168.255.255
Or in the automatically assigned range (RFC3330)...
  169.254.0.0 mask 169.254.255.255

If the assigned IP is within any of these ranges then it is non-routable and
make no sense to attempt to update DNS and so astlinux would then do a web
lookup (to the selected server) to determine the true external IP address
for DNS.

Such an automatic option could be the most robust method.

by-the-way, it would also be nice if the web interface status page displayed
both the external interface IP address, and the true external IP (if
different).

Regards
David



On Thu, May 14, 2009 at 5:43 PM, Lonnie Abelbeck
<li...@lo...>wrote:

> Currently in trunk-2675, there has been a few changes to the Dynamic
> DNS support.
>
> One new feature is to obtain the public IP address from the external
> interface (EXTIF) instead of a web lookup to Kristian's
> getip.krisk.org.  It works in my testing, but it needs more people
> testing it.
>
> Additionally, if a web-get-ip method is required, a different server
> can now be specified.
>
> The ZoneEdit bug has been fixed, so the Web interface has done away
> with the "ZoneEdit [generic]" selection.
>
> Anyone using Dynamic DNS, please give this a try.  If you are a PPPoE
> Dynamic DNS user, please report back your results.
>
> Thanks,
> Lonnie
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

Currently in trunk-2675, there has been a few changes to the Dynamic  
DNS support.

One new feature is to obtain the public IP address from the external  
interface (EXTIF) instead of a web lookup to Kristian's  
getip.krisk.org.  It works in my testing, but it needs more people  
testing it.

Additionally, if a web-get-ip method is required, a different server  
can now be specified.

The ZoneEdit bug has been fixed, so the Web interface has done away  
with the "ZoneEdit [generic]" selection.

Anyone using Dynamic DNS, please give this a try.  If you are a PPPoE  
Dynamic DNS user, please report back your results.

Thanks,
Lonnie

As of 4pm PDT, trunk builds with Arno's latest include the
dmz-dnat.plugin ...

-Philip

Darrick,  Not sure if I know what I'm talking about here, but would it be
possible to build just the asterisk components with eglibc as a transitional
step, leaving the rest of Astlinux to use uclibc?  Or are things so
intertwined that the whole of astlinux would need to move en-mass?  I'm only
suggesting this as a first step, not final solution.

David

---------- Forwarded message ----------
From: Darrick Hartman <dha...@dj...>
Date: Wed, May 13, 2009 at 9:29 AM
Subject: Re: [Astlinux-users] Fax Support
To: AstLinux Users Mailing List <ast...@li...>


Darren,

If/when we replace uclibc with eglibc we would be able to support the
binary blobs that Digium is selling. (g729, fax, eventually skype)  It
will be at least several months before we would have the time to get
this implemented and tested.  It's a major overhaul.  I'm trying to find
some information which would provide some size comparisons between the two.

Bottom line, if you need something reliable right now, I'd set up a
Hylafax server.

Darrick

Niksa Baldun wrote:
> Darren,
>
> if you don't require running system from CF card, Elastix has excellent
> fax support, you can set it easily through web gui. It would be great if
> AstLinux had something similar, though.
>
> Niksa
>
>
>
> Darren Grant wrote:
>>
>> Hi
>>
>> Up until yesterday I had faxes received on an Exchange server, but that
>> hardware died. So I figured it was time to get creative and dispense with
>> the old modem that hung off a serial port and use Asterisk instead.
Mainly
>> because after 2 days of trying I couldn't get the modem to work with a
>> USB-Serial adaptor required due to the lack of serial port on the new
>> hardware, anyway ...
>>
>> Is there any way to get Astlinux to receive faxes ? Looking over old
posts
>> on the list I see that the digum fax module is not available for
>> Astlinux. I
>> really hope there is a way as I have just had a quick look at
>> AstriskNOW 1.5
>> and what a mess that is, all the documentation is out-of-date, they
>> seem to
>> have switched from astrisk-gui to FreePBX for no apparent reason and just
>> generally left users in the dark ! They have really messed that up and
>> I can
>> see a lot of people abandoning it as a result.
>>
>> Asltlinux is far slicker, it is just a dilema if I can't get Astlinux to
>> receive a fax I'll be stuck.
>>
>> Thanks
>> Darren

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to
pa...@kr....

Kristian Kielhofner wrote:
> On 1/8/09, Lonnie Abelbeck <li...@lo...> wrote:
>   
>> Kristian,
>>
>>  As you know, astfw is being eliminated in 0.7 in favor of Arno's
>>  Firewall.  Arno's Firewall utilizes about 200 possible variable
>>  definitions, definable in a users rc.conf file or a very useful subset
>>  implemented in the web interface.
>>     
>
>   Cool!
>
>   
>>  The only astfw feature not directly implemented is your "IP DMZ"
>>  support... basically have all unmatched unbound packets routed to a
>>  single internal IP address.
>>     
>
>   Yeah, that's basically it...
>
>   Essentially, any packets destined for the external interface that
> don't match any existing states (from the host or other ip_conntrack
> stuff) will get forwarded to that IP.
>   

I submitted a fix for this, Lonnie code reviewed and tested it (and
found a couple of bugs in the process -- thanks Lonnie!).

It's been submitted to Arno.  It should be integrated by the time
1.9.2-BETA goes out this weekend.


>>  I think that now we have a fully configurable firewall, the "IP DMZ"
>>  feature may be unnecessary, but you indicated that you use this.  If
>>  so, could you please elaborate why/how you use it so we can understand
>>  the situation.
>>
>>  If "IP DMZ" support is required, this could be implemented as a
>>  'plugin' like the traffic-shaper is currently done.
>>     
>
>   It's tremendously useful when you need to insert an AstLinux machine
> in front of some other router and you don't want to deal with
> specifically forwarding any traffic - all unknown traffic will end up
> on the previous router.
>
>   Star2Star uses this feature constantly; it's the only way we can
> insert our "Starbox" in front of whatever existing router they might
> have when we only have one public IP available.  Meanwhile all of
> their firewall rules, port forwards, and VPNs "just work".
>
>   I, we, absolutely need this feature.  If I can get up to speed on
> Arno I would be happy to implement it as a plugin.  I feel that
> Star2Star could benefit from Arno as well.  I view this as a win-win.
>
>   
>>  Lonnie
>>
>>
>>  Related variables...
>>  ------
>>
>>  ##IP DMZ Support
>>  ##Uncomment the following lines to support more traditional DMZ setups.
>>  ##If you define DMZIP astfw will automatically forward any new/unknown
>>  ##tcp and udp connections coming in on EXTIF to the IP address that you
>>  ##specify. If you say "auto", AstLinux will use the first DHCP lease
>>  from
>>  ##the instance of dnsmasq running on INTIF.
>>  #DMZIP="auto"
>>     
>
>   IP to forward unknown traffic to.
>
>   
>>  ##You can also specify a IP/hostname/netblock of IPs that should still
>>  have
>>  ##access to the AstLinux system, i.e. not be forwarded to the DMZ host.
>>  ##Define that here.  These are examples of what is possible, only
>>  define one.
>>  #DMZSRC="www.astlinux.org"
>>  ##-or
>>  #DMZSRC="169.207.1.3"
>>  ##-or
>>  #DMZSRC="10.17.69.0/255.255.255.0"
>>     
>
>   IP range to exclude.  This is how Star2Star's management servers can
> still get to any service on the Starbox itself and not be forwarded to
> the customer's existing router (or whatever DMZIP is set to).
>   

We didn't do 100% compatibility with the old variables and semantics. 
You can achieve the same thing, but you have to do so by configuring
Arno's firewall using the existing mechanisms.

Let me know, and I can send you the tarball to patch into trunk if you
want to get an early start on testing it.

-Philip

>   
>>  ##If your DMZIP is not on INTIF, define the other interface here.  You
>>  can use
>>  ##a real name or another variable from this file.
>>  #DMZIPIF="$INT2IF"
>>     
>
>   Pretty obvious.
>
>   
>>  ##You can also specify a list of ports to bypass your DMZSRC exclusion.
>>  ##Use this if you need to connect to a specific service on DMZIP from
>>  DMZSRC
>>  #NODMZPORTS="t25 t110 t143"
>>     
>
>   Same as the exclude address range above except it's ports or a range
> of ports.  This is how the Starbox can still handle SIP/RTP traffic
> to/from the internet at large (any IP address).
>
>   

How about it, Bryce?

-Philip


Philip A. Prindeville wrote:
> I'm looking at build_tools/genmodconf:
>
>     if [ -d ${2}/etc/modprobe.d ]; then
>         target=${2}/etc/modprobe.d/modprobe.rhino
>     elif [ -d ${2}/etc/modules.d ]; then
>         target=${2}/etc/modules.d/modprobe.rhino
>     elif [ -f ${2}/etc/modprobe.conf ]; then
>         target=${2}/etc/modprobe.conf
>         combined=1
>     elif [ -f ${2}/etc/conf.modules ]; then
>         target=${2}/etc/conf.modules
>         combined=1
>     else
>         echo No suitable location for module rules can be found... exiting.
>         exit 0
>     fi
>
>
>
> and wondering who we need to ask to change that to
> "/etc/modprobe.d/rhino.conf" instead of /etc/modprobe.d/modprobe.rhino
> so we can stop seeing the message:
>
>  modprobe ipt_policy: WARNING: All config files need .conf: /etc/modprobe.d/modprobe.rhino, it will be ignored in a future release.
>  modprobe iptable_nat: WARNING: All config files need .conf: /etc/modprobe.d/modprobe.rhino, it will be ignored in a future release.
>
>
> Thanks,
>
> -Philip
>   

Philip,

That looks like a good idea...
----
    if [ -d ${2}/etc/modprobe.d ]; then
-       target=${2}/etc/modprobe.d/modprobe.rhino
+       target=${2}/etc/modprobe.d/rhino.conf
    elif [ -d ${2}/etc/modules.d ]; then
----

Bryce is here on the mailing list...

Lonnie


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

> I'm looking at build_tools/genmodconf:
>
>    if [ -d ${2}/etc/modprobe.d ]; then
>        target=${2}/etc/modprobe.d/modprobe.rhino
>    elif [ -d ${2}/etc/modules.d ]; then
>        target=${2}/etc/modules.d/modprobe.rhino
>    elif [ -f ${2}/etc/modprobe.conf ]; then
>        target=${2}/etc/modprobe.conf
>        combined=1
>    elif [ -f ${2}/etc/conf.modules ]; then
>        target=${2}/etc/conf.modules
>        combined=1
>    else
>        echo No suitable location for module rules can be found...  
> exiting.
>        exit 0
>    fi
>
>
>
> and wondering who we need to ask to change that to
> "/etc/modprobe.d/rhino.conf" instead of /etc/modprobe.d/modprobe.rhino
> so we can stop seeing the message:
>
> modprobe ipt_policy: WARNING: All config files need .conf: /etc/ 
> modprobe.d/modprobe.rhino, it will be ignored in a future release.
> modprobe iptable_nat: WARNING: All config files need .conf: /etc/ 
> modprobe.d/modprobe.rhino, it will be ignored in a future release.
>
>
> Thanks,
>
> -Philip

I'm looking at build_tools/genmodconf:

    if [ -d ${2}/etc/modprobe.d ]; then
        target=${2}/etc/modprobe.d/modprobe.rhino
    elif [ -d ${2}/etc/modules.d ]; then
        target=${2}/etc/modules.d/modprobe.rhino
    elif [ -f ${2}/etc/modprobe.conf ]; then
        target=${2}/etc/modprobe.conf
        combined=1
    elif [ -f ${2}/etc/conf.modules ]; then
        target=${2}/etc/conf.modules
        combined=1
    else
        echo No suitable location for module rules can be found... exiting.
        exit 0
    fi



and wondering who we need to ask to change that to
"/etc/modprobe.d/rhino.conf" instead of /etc/modprobe.d/modprobe.rhino
so we can stop seeing the message:

 modprobe ipt_policy: WARNING: All config files need .conf: /etc/modprobe.d/modprobe.rhino, it will be ignored in a future release.
 modprobe iptable_nat: WARNING: All config files need .conf: /etc/modprobe.d/modprobe.rhino, it will be ignored in a future release.


Thanks,

-Philip

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.
>>
>
>
>
>