Gary G. Hendershot wrote:
> Thank you Item 1: Got the 4.3 version and loaded it up. All fucntions
> I was interested in just seemd to work without a whole lot of messing
> around with it.
Glad to hear it!
> Thank you Item 2: I am using the Arno firewall and find it works very
> well. Is much more granular in its configuration so I was able to do
> some pretty neat things related to my branch office connectivity
> requirement. This is a welcome addition to the distro.
Cool. Once I get more familiar with Arno's FW it will be made the
primary firewall. astfw is still the default because I understand it
completely and it is so simple...
> Problem 1: I am doing the "voicemail to email" thing. It works as
> advertised. But is still plauged by the same old problem of very low
> volume in the attached WAV file that I have always seen with Asterisk.
> I am sending the attachment in WAV49 format which I had been told
> previously should work. Voice mail retreived using a SIP handset is
> crisp and clear. But an email attached voicemail cannot even be heard.
> Has anyone on the list figured out a workaround for this?
What kind of trunk are you using on the original, incoming call that is
leaving the VM?
> Problem 2: I notice that when I try to do an NFS export (I dont really
> need this so for me the problem is mute) I get errors related to
> runlevel on boot. The system comes up and Asterisk is running and all
> other functions seem to work. I have not really done much to try to
> isolate the cause so I am not very helpful with this I know. Suspect
> someone who needs this function will probably start pounding the table
> soon enough but wanted to give you a heads up.
NFS exports are basically completely untested. I have not used NFS for
anything in years... I'll be happy to take any hints that you might be
able to provide!
> Problem 3: Similar to item 2 above, on a lark I tried to build for
> i686. The build failed with a number of errors that I should have
> documented but did not. Sorry. I was in a hurry to get it running so
> built it again for i585 and there were no issues using the exact same
> build selections as with the i686 attempt. Again, I would expect that
> someone who really needs an i686 build will start fussing soon enough.
I can't say that I have ever tried to build for i686. Quite honestly,
the number of optimizations gained from one to the other are quite
minimal. Changing the target CPU type without using a different device
will cause a problem because the kernel and uclibc are both hardwired to
use a given processor type. Look in target/device/geni586/*.config for
more details. (Hint: to build for i686 make yourself a generic686 and
modify the config files).
> Question 1: I am interested in moving forward with support for a WiFi
> hot spot scenario. I noticed on the list of toys available in build
> enviornment a gizmo call "NoCatSplash". I understand that this is used
> by some to support authentication of WiFi clients. I have previously
> used a home brew web page and authenticated against a RADIUS service on
> another machine. Has anyone on the list implemented a WiFi hot spot
> type scenario using AstLinux? Would you be willing to provide some
> pointers maybe off list so we dont bore folks who are not interested?
NoCatSpash is basically nocatauth without the perl dependency. You
specifically mentioned radius. NoCatSplash does not support and of the
external auth modules (like radius) that NoCatAuth does. NoCatSplash is
basically designed as a minimum to provide an AUP, let the user click "I
Agree" and open the firewall...
> Question 2: I noticed that a build target for VIA is now on the list.
> I understand that for now, this is just a redundant copy of the i586
> build. I also understand that the VIA CPU's have some cute tricks
> available that enhance encryption/decription and multimedia that are not
> available in other i586 variants. As my hardware is VIA based, this is
> interesting to me. Is it your intent to support these features at some
> point in the near term?
The VIA cpus have a feature called "padlock" that is probably what you
are talking about here. Basically, it provides very good acceleration
for encryption using AES and SHA1 hashing (on some versions). It
requires three things:
1) kernel support (done - padlock.ko)
2) OpenSSL support (not done - either we patch 0.9.7e or add support for
0.9.8)
3) Application support. Each application that uses OpenSSL has to make
two calls to initialize any hardware engines. A short list of apps for
these patches:
1) OpenSSH
2) mini_httpd
3) Asterisk?
4) openvpn
As far as the MPEG2 decoder that you are probably referring to, I am
not too focused on supporting it. First of all, MPEG2 is a great video
standard if you plan to watch DVDs. Otherwise MPEG is better. I think
I may have heard something about the C7 supporting MPEG4, but I'm not
sure. Darrick knows a lot about VIAs so maybe he can chime in here....
Either way, MPEG decoders of any kind are outside the scope of AstLinux
target goals ATM.
Thank you for your kind words and intelligent questions!
--
Kristian Kielhofner
_______________________________________________
Astlinux-users mailing list
[email protected]
http://lists.kriscompanies.com/mailman/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to [EMAIL
PROTECTED]
