[leaf-user] VMware 5 NetDrivers Fixed in 5.2.8-rc1
I just gave a quick test to the latest BuC branch and made the two observations: - starting up a new VM with default devices results in 5.2.8-rc1 installing drivers for all netcards - manually adjusting the cfgfile of VMware, to use the aforementioned "vmxnet3" driver, results in LEAF installing the appropriate driver So the problems regarding VMware which I mentioned in my Aug 31 email (and later) seem fixed. Thanks! -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] More/Many Missing Drivers in 5.2.x Series?!
Having setup BuC5.2.7 under a VM and gotten it all setup I went to run it on my production machine (an old ASUS mobo with Semperon 3400+ CPU) and came up missing some more drivers. Of particular urgency is for me is the 'forcedeth' drive (/kernel/drivers/net/ethernet/nvidia), since this is the netcard built into the mobo. In my diagnosing this absence I ran 'lspci -k' and got an interesting comparison between the drivers included in (and some used by me) in BuC 5.1.5, and the current 5.2.7. In my case I no longer had 'k8temp' driver (for CPU temp monitoring). Also absent were 'i2c-nforce2' (SMbus stuff, maybe temp/fanspeed sensor related) and 'pcieport' (which I couldn't locate within the modules of 5.1.5, but is tagged in lspci as 'PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)'). When I did a more detailed comparison of drivers of 515 versus 527, as a quick & dirty I counted 200 files that were in 515 but weren't in 527 (coming to 4.1MB). If there's a willingness to restore some or all of the drivers that used to be in 515, I'd point to the ones found in: - /kernel/drivers/acpi/*(pwr mgmt?) - /kernel/drivers/i2c/*(temps sensors, etc) - /kernel/drivers/hwmon/*(temps sensors, etc) - /kernel/drivers/cpufreq/*(cpu throttling?) - /kernel/drivers/net/ethernet/*(esp 'atheros' & 'broadcom') - /kernel/fs/ext2/*(ext2 driver?!?!) - /kernel/fs/ext3/*(ext3 driver?!?!) - /kernel/drivers/usb/usb-common(required by other drivers?!) as key candidates, in addition to my current need for 'forcedeth'. (Hopefully it'll be under the 5.2 series? : ) Cheers & thanks again for LEAF - I guess I'm one of the few remaining who use it on old repurposed PC's! -- leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Seeking vmxnet3 driver; was: Re: Missing AMD/PCnet32 Driver from 5.2.*?
On 16/09/01 13:09, kp kirchdoerfer wrote: > HI; > > Am Mittwoch, 31. August 2016, 19:49:43 schrieb groups, freeman: >> I seem to need the an AMD 79C970 driver (which is fulfilled by PCnet32) >> for my VMWare Player v5 testbed. >> >> [...] > Yes you are right, and yes it will be added into next version. > > kp Super, thanks! I also discovered a workaround for the interim - by adding the not-configurable-by-GUI line: ethernet0.virtualDev = "e1000" to the VM's .vmx configfile. (Also valid, to VMware v5 anyway, are 'vmxnet,' 'vmxnet3,' 'e1000e' and 'vlance' [the default and the source of my need for the AMD driver] though IIRC none had drivers within LEAF). KP, might you consider also the addition of the vmxnet3 adapter? (/drivers/net/vmxnet3 folder in the kernel tree.) Per VMware's KB article "Choosing a network adapter for your virtual machine (1001805)" ( https://kb.vmware.com/selfservice/microsites/search.do?language=en_US=displayKC=1001805 ) it's billed as "the next generation of a paravirtualized NIC designed for performance". In any case thanks again for everyone's work on supporting LEAF! -- leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Missing AMD/PCnet32 Driver from 5.2.*?
I seem to need the an AMD 79C970 driver (which is fulfilled by PCnet32) for my VMWare Player v5 testbed. Trying BuC v5.2.7, I notice that the modules.sqfs filesystem contains no "amd" dir under the 'drivers/net' subdir and since the pcnet32 driver is stored in that 'amd' dir, it explains the driver's absence. (The 'amd' dir seems to be missing going back to at least BuC v5.2.2). Could someone let me know if that's a correct observation & all, and if in a future BuC release the 'amd' dir's drivers shall be included? Cheers & thanks for LEAF! -- leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] In BuC v5.1.5 [USB] ez-ipupd.lrp is missing its .conf file
Sorry, I was insufficiently clear. The .conf file that's missing is not the one for the ez-ipupd program, it's the one required by LRCFG to have it show the ez-ipupd package in the list of packages that have editable config files; specifically the file: /var/lib/lrpkg/ezipupd.conf is absent. Cheers thanks again for LEAF! On 15/08/10 12:44, kp kirchdoerfer wrote: Am Sonntag, 9. August 2015, 04:58:18 schrieb groups, freeman: Seems as well to be the case for 5.1.6. It's missing since about three yrs. The commit message by Yves Bluessaeu says: This allow ezipupd to manage multiple configurations in parallel ez-ipupd-conf has been moved to ez-ipupd.example therefor. If that causes pb's, pls let us know. kp -- leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/ -- leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] In BuC v5.1.5 [USB] ez-ipupd.lrp is missing its .conf file
Seems as well to be the case for 5.1.6. Cheers thanks for LEAF! -- leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] [solved using syslog-ng] /var/log overrun by 'asb100' debug msgs
First, I somewhat conjoined two effects of these debug msgs from asb100
so let me clarify the effects and resultant problem (and modify the
subject line):
1) the debug msgs from asb100 (invoked via dev_dbg() in asb100.c) get
dumped into the kernel ring buffer, such that it gets outputted if
'dmesg' is invoked (but this *doesn't* apparently fill or effect my
/var/log partition)
2) they also get dumped into /var/log/debug and /var/log/kern.log (this
*does* cause a filling of my /var/log partition)
It is the filling of my /var/log partition that is of concern to me most
of all.
On 12/04/17 10:51, KP Kirchdoerfer wrote:
The option [CONFIG_I2C_DEBUG_BUS] is already disabled - at least
in 4.2.
So this is not the cause of the problem, unfortunately.
Alas, I guess this forced me to do this right? way ... by reconfiguring
syslog-ng (via /etc/syslog-ng/syslog-ng.conf) to 'ignore' the logging of
these debug msgs.
I chose to have syslog-ng pipe to /dev/null any messages that are of
level DEBUG, and contain text found in both these lines of information.
To accomplish this I added, at the end of the 'destinations' section of
the syslog-ng config file:
destination my_dp_null { pipe(/dev/null owner(root) group(root)
perm(0777) ); };
and at the end of the 'filters' section:
filter my_f__debug__asb100_device_update {
level(debug)
and match(kernel:.* asb100 .* device update);
};
and at the *beginning* of the 'log' section:
log {
source(s_all);
filter(my_f__debug__asb100_device_update);
destination(my_dp_null);
flags(final);
};
Works like a charm regarding stopping the filling of my /var/log partition!
I'm still left with the noisome overrunning of dmesg output but suspect
that I'm SOL for resolving that one (i.e. as with the shorewall logging
msgs also cluttering/overfilling dmesg's output).
PS: Thx for your quick response KP - it promptly moved me along to
finding this solution.
Cheers thanks all, for LEAF!
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
[leaf-user] Incorrect? 'latest_ver' DL link?
I noticed that atop the DL page (http://sourceforge.net/projects/leaf/files/Bering-uClibc/) it says: Looking for the latest version? Download Bering-uClibc_4.2-rc1_i686_isolinux_vga.iso (74.2 MB) .. but wouldn't 4.2 release be a better (latest, finalized) version? Cheers thanks for LEAF! -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Load files from USB flash card
On 12/04/10 16:57, davidMbrooke wrote: Does anybody still use Floppy Disks? I do (bootable CD, configdb and leaf.cfg on floppy). I'd speculate this however - it's probably only the more technical (or old-timer) people who use floppy, so they might be a group of users most able to reconfig different-than-defaults on their own. But if there's no, or minimal, 'cost' associated with having the floppy comprise part of the searched paths then it'd make sense to just leave it in. Cheers thanks for LEAF! -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Seeking tor.lrp Update (and sugg'n re 4.2+ pkg requirements notice)
My tor client (running on BuC 4.2b1) is warning me that the server version I'm using is needing an update: [warn] Please upgrade! This version of Tor (0.2.2.33) is not recommended, according to the directory authorities. Recommended versions are: 0.2.1.32 0.2.2.35 0.2.3.10-alpha 0.2.3.11-alpha 0.2.3.12-alpha 0.2.3.13-alpha (I'm partial to 0.2.2.25 myself, given that it's non-alpha, but would be thankful for any version that makes the tor network more secure.) The version repo for tor is here, if it's helpful: https://archive.torproject.org/tor-package-archive/?C=N;O=A = BTW, I happened to notice that atop the 4.x packages page (http://leaf.sourceforge.net/bering-uclibc/index.php?module=pagemasterPAGE_user_op=view_pagePAGE_id=13MMN_position=33:33) it mentions that the listed pkgs only work for 4.2+. Question: Will I be able to still use these pkgs with a 4.2 beta 1 platform? Suggestion: Clarify on that page that the limitation for 4.2 is for 4.2 *release*+, or 4.2 beta 1+ or ...? Suggestion: Adjust the text for the 4.x pkgs (on the left side of most leaf.SF pages) to instead read 4.2+ pkgs, to aid in people noticing this diversion from the usual 4.X coverage? Suggestion: Adjust the text atop the actual page of listed pkgs, that currently reads Please note: These packages are only for Bering-uClibc versions 4.2 and above. to be in red. I felt lucky that I noticed it because I don't usually peruse the page and instead just home in on the pkg that I want to look into. I guess that I find this diversion (from the past 10 yrs of a major LEAF version having common pkgs) startling. Cheers, thanks for LEAF! -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Seeking tor.lrp Update (and sugg'n re 4.2+ pkg requirements notice)
On 12/04/16 13:06, KP Kirchdoerfer wrote: [Tor version]0.2.2.35 has been committed to git and will available soon. Thx KP! Generally the packages are for 4.x, but kernel related packages for 4.2 only. We don't test newer packages on oler releases, though they may work. Eeek! I've been using LEAF for 10+ yrs and this is news to me. I have to admit it's been more than a while since I perused the doc'n but if this isn't noted somewhere in the docs I'd submit that it'd be worthy. Tho based on this (that pkgs are only tested against the newest LEAF ver), is it really fair to refer to the pkgs as being for 4.x when it's actually not really known if the pkgs will work on older versions? Just a suggestion for something to think about! Cheers thanks again for LEAF your tor update KP! -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] dmesg overrun by 'asb100' debug msgs
I'm using BuC 4.2 beta 1, on an ASUS P4E mobo, using the sensors pkg. My dmesg log is getting overrun with repetitions, every 7-8 secs, of this pair of debug lines: [ 687.583914] asb100 0-002d: starting device update... [ 687.777041] asb100 0-002d: ... device update complete and this is filling my /var/log partition :( What little google offers about this particular iteration of this debug msg (asb100 0-002d: starting device update...) is essentially seen here: http://lm-sensors.org/ticket/1698 and ends with a response to the OP's identical-to-my complaint, by someone who sounds confident in the fix: You have enabled I2C Bus debugging messages (CONFIG_I2C_DEBUG_BUS) when configuring your kernel. Simply unselect this option and the messages will go away. In light of this might someone be able to compile the kernel with this option disabled? I'd be happy to give it a quick test if the kernel will be compatible with 4.2 beta 1 (if the modified kernel requires a newer BuC platform it'd have to wait for me to do an upgrade). Cheers thanks as always for LEAF! -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Change the order of eth0,1 etc
I think I found my issue (BTW I'm 4.2 beta 1).
I have leading whitespace for many of my /etc/modules entries, so those
weren't being loaded via the modutils script because it filters for only
lines whose first char is alphanum:
grep ^[a-z0-9A-Z] /etc/modules |
presumably to omit comment lines ... but it's a tad too restrictive for
me so I used instead:
grep -vE ^[[:space:]]*(#|$) /etc/modules |
to omit both comment lines and empty lines. (FWIW there's a second
instance of the problematic-for-me grep filter in that modutils file.)
In my case the netcard drivers were being loaded by the auto-loader
portion of modutils, and in the same order as I had in my modules file
so I hadn't noticed.
I also discovered that I had a typo in my modutils file for one of my
drivers. In light of this I'd put in an RFE for:
- when parsing of the /etc/modules file and an module file cannot be
found (or gives an error), it puts out an error msg to the console
(I know that if an entry in /etc/modules does not exist as a file that
no err msg is output.)
(I'd also put in an RFE for more output from the modutils file as it
does its work - could it indicate when it's doing each of the 3 internal
steps of module loading:
- parsing /etc/modules,
- walking /etc/modules.d,
- finally, autoloading
so the user can see when exactly modules are being loaded? That would
probably help tremendously with diagnosing module-loading issues.)
Myself, I have the section messages (within modutils) output at all
times since diag output is pretty 'cheap' to implement, but it could
instead be set to only show this info if $VERBOSE is true.
Cheers thanks for LEAF!
On 12/03/31 05:41, Andrew wrote:
31.03.2012 00:27, groups, freeman написал:
On 12/03/26 05:11, Andrew wrote:
26.03.2012 07:03, ads...@genis-x.com написал:
How do I change the order of NIC detection? or how can I force the system
to
load e1000e BEFORE the igb driver?
Bering-uClibc_4.2_i686_syslinux_vga
{{ snip }}
Hi.
Just add e1000e in /etc/modules - it is processed before hardware detection.
H. I seem to be suffering the same issue but I'm using 4.2 *beta 1*.
In my case I'm using the tg3 module, and when that file merely exists in
/lib/modules mdev (I believe) finds it and loads it before the modules
listed in my /etc/modules get loaded.
So my question would be: do I need to upgrade to 4.2 *release*, to have
my /etc/modules file 'respected' (i.e. to not have tg3.ko auto-loaded),
or is something else afoot in my case?
Cheers thanks for LEAF!
scott
As I remember, nothing changed in module-related logic for a long time
(except switching to more easy hardware detection using hotplug script).
/etc/modules is parsed before modules probing for long time.
Can you do lsmod and look, when actually tg3 was loaded (on top there
are freshest modules)?
Try to remove modules.lrp from list of packages (to avoid module
loading), and try to load tg3 manually - will it loaded successfully?
Maybe it depends from some other driver (some bridge or so on, that is
supported as module).
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
Re: [leaf-user] Change the order of eth0,1 etc
On 12/03/26 05:11, Andrew wrote:
26.03.2012 07:03, ads...@genis-x.com написал:
How do I change the order of NIC detection? or how can I force the system to
load e1000e BEFORE the igb driver?
Bering-uClibc_4.2_i686_syslinux_vga
{{ snip }}
Hi.
Just add e1000e in /etc/modules - it is processed before hardware detection.
H. I seem to be suffering the same issue but I'm using 4.2 *beta 1*.
In my case I'm using the tg3 module, and when that file merely exists in
/lib/modules mdev (I believe) finds it and loads it before the modules
listed in my /etc/modules get loaded.
So my question would be: do I need to upgrade to 4.2 *release*, to have
my /etc/modules file 'respected' (i.e. to not have tg3.ko auto-loaded),
or is something else afoot in my case?
Cheers thanks for LEAF!
scott
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
Re: [leaf-user] Leaf Upgrade
On 12/02/23 14:30, Robert K Coffman Jr. -Info From Data Corp. wrote:
I'm running it on older low end (P4 class) PCs with various NICs.
Me too.
I boot from old hard disks that spin down after boot.
Me, CD-ROM + floppy for config.
Is there some way I
could push a disk image onto those? I can figure out the modules piece
separately...
This should be totally easy and simple to do if you have a normal LEAF
setup where everything runs from a ramdrive.
In such a case you can remove all files on the HD, format the HD,
whatever, that won't affect the running system at all.
You can even do a 'dd' and reimage the HD, if that's what you meant by
'push a disk image'.
Keep in mind where the image file is saved tho - if the file (say due to
it being too big to live in /tmp) exists on the HD and you overwrite it
('dd') with itself, you could get wacky corruption.
OTOH if you can create a partition on the HD that is outside the
physical cylinders that will get written during the imaging then you
could mount that filesys, dd the HD from an images stored on that
filesys, and then boot up into your new system.
So yup, totally doable.
scott
- Bob Coffman
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
Re: [leaf-user] Leaf Upgrade
On 12/02/22 13:43, Robert K Coffman Jr. -Info From Data Corp. wrote: The current release (4.2 beta) is too large for the root drive of my storage (vfat /dev/sda1). If I move these files into a subdirectory rather than the root of the hard drive, how do I reflect that in leaf.cfg and syslinux.cfg? Your quandary confuses me. If the storage space needed by 4.2 beta exceeds what you can put in the root then it would also exceed what you can put in a subdir. Are you instead hitting the limit of max_number_files_in_root_of_FAT_filesystem? (Maybe ~512 files)? In that case then moving some files to a subdir would help (but I would be surprised about anyone hitting this limit). I don't unfortunately know offhand how to choose a subdir for LRP files tho, having never so need or really wanted. When I peek at the 'init' script in the initrd.lrp file (which does the pkg loading), and see stuff like: echo $dev $t $PFX/pkgpath.disks the language used (.disks, $dev) makes me think that $PKGPATH is a list of *drives*. However maybe you can specify, in the leaf.cfg file, that some or all packages are listed as: subdir/package.lrp instead of just package.lrp ... and this could possibly work? (However if you have actually run out of drive *space* you could make a bootable 'parted magic' CD and use that to resize your partitions. Backup first tho, if at all possible!) Good luck! scott Thanks! - Bob Coffman -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] LEAF 4.0 Packages - D/L problems
1) The 4.0 packages now download as files named '4_0_pkgname.lrp' instead of the traditional 'pkgname.lrp' - I suspect this is unintentional. 2) The EasyRSA package that downloads as a singular package is not the newest (i.e. it doesn't contain KP's addition of the 'build-ca' script), although when one D/L's the CD image, the EasyRSA.LRP contained therein does contain that script is is thus the newest (I believe). 3) At least some of the files error as '404' when trying to DL them - 'astsmpls.lrp' is one. Cheers thanks for LEAF! -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Missing /usr/Sbin files in v4 EasyRSA
On 12/01/23 00:31, n22e113 wrote:
Try:
# /usr/sbin/pkitool --initca
# /usr/sbin/pkitool --server ${SERVER}
http://ubuntuguide.org/wiki/OpenVPN_server
I ended up just pulling in the missing scripts (from the easy-rsa/2.0
dir) from the OpenVPN source:
http://packages.debian.org/source/wheezy/openvpn
and they worked straight out of the box.
Thanks for the tip tho!
Cheers!
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
Re: [leaf-user] Missing /usr/Sbin files in v4 EasyRSA
On 12/01/23 07:23, groups, freeman wrote: I ended up just pulling in the missing scripts (from the easy-rsa/2.0 dir) BTW the output of 'help easyrsa' displays the version 1.0 README file, instead of what I think it should show, which would be the ver 2.0 README file. Cheers thanks for LEAF! -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Missing /usr/bin files in v4 EasyRSA
There appear to be missing, from the current (v4) EasyRSA package, a handful of files from the /usr/bin dir ... at least when compared to the v3 EasyRSA package. e.g. clean-all, build-ca, build-key-server, etc FWIW I'm trying to follow the v4 VPN setup instructions at: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_a_Virtual_Private_Network Cheers thanks for LEAF! (BTW, thanks for the info about initrd, will be looking into it next time time permits :) -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Missing /usr/Sbin files in v4 EasyRSA
On 12/01/22 10:42, KP Kirchdoerfer wrote: Look in /usr/sbin My bad, I was in fact originally looking in /usr/Sbin. I also noticed that clean-all is there, however the one I actually need, build-ca, is definitely missing. Cheers! -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Manually unpacking mounting initrd.lrp
Hi, I'm testing with 4.2b1 and want to examine the uncompressed-then-mounted contents of the initrd.lrp file. On my running 3.1.1b3 I'd gunzip the lrp file via: gunzip -c initrd.lrp /tmp/initrd.minix and then loop-mount the output as a minix filesys ... but that doesn't work now :( First question is what is the underlying filesystem inside the initrd on this 4.2? Also, is loop.o now built-in to the kernel so no need to load it as a module? (Hope so, since I can't find loop.o for this 4.2 version.) When I've been trying to mount the uncompressed lrp via: mount -o loop /tmp/initrd.minix /mnt2 I get: mount: mounting /dev/loop0 on /mnt2 failed: Invalid argument == and when I specify minix as the filesys: mount -t minix -o loop /tmp/initrd.minix /mnt2 I get the unhelpful: mount: mounting /dev/loop0 on /mnt2 failed: No such device yet both /dev/loop0 /mnt2 exist: drwxr-xr-x2 root root40 Jan 19 13:26 /mnt2 brw-rw1 root disk7, 0 Jan 19 12:16 /dev/loop0 Any help would be much appreciated ... and thanks as always for LEAF! -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Migrating to OpenVPN, BRIDGE Mode
Sort of a brief, general question, having spent 8 hrs on this and gotten nowhere. I currently have LEAF uC v3.1.1b3 router, with extensive shorewall rules for eth1 (my LAN). If I want to migrate to using OpenVPN, road warrior setup (incl using bridging and not routing to access the eth1 network), I need to remove eth1 from my interfaces file and activate br0, I believe. However since all my shorewall rules refer to eth1 I need to change those to be for br0, yes? Just want to confirm that last point since it'll be a pile of work (incl the fact that I have a eth1:1 interface that'll complicate things) to do such a switch. I guess I could use the routing method, but prefer the bridging method because I want to use Windows network shares, etc. Cheers thanks for any feedback or tips! (And BTW, thanks for LEAF!) -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] BuC4 - Pkgs HTML Page Broken?
Hi, taking a peek at BuC4. Wanted to check the packages page by clicking on link on left side of LEAF's SF site, which sends me to: http://leaf.sourceforge.net/bering-uclibc/index.php?module=pagemasterPAGE_user_op=view_pagePAGE_id=13MMN_position=33:33 However when I view the page in FF I get: == XML Parsing Error: not well-formed Location: http://leaf.sourceforge.net/bering-uclibc/index.php?module=pagemasterPAGE_user_op=view_pagePAGE_id=13MMN_position=33:33 Line Number 385, Column 277:dt id=PKG_5459. a href=http://leaf.git.sourceforge.net/git/gitweb.cgi?p=leaf/leaf;a=blob_plain;f=bering-uclibc4/bin/packages/libelf.lrp;hb=HEAD;libelf.lrp [32 k]/a/dtddpThe libelf library from elfutils/ppHomepage: a href=https://fedorahosted.org/elfutils//ppLEAFhttps://fedorahosted.org/elfutils//ppLEAF/a Package by anonymous, 2011-02-07/ppVersion: 0.148 Rev 1 uClibc 0.9.30.3 - == Yet when I go there in IE (XP-32, SP3, IE8) I get the proper page. Just an FYI and thanks for LEAF! -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Problems with BlackBerry device and Leaf Router
BB via WiFi, through a LEAF router (v3.1.1 something), works fine - personal experience. (If special ports needed to be opened then every open HotSpot would need special config to support BB users ... so no special config being required makes sense, right?) I'd verify that your BB plan supports: - data - and also that it supports UMA - and that your BB device using UMA is supported by your carrier (Rogers Canada only recently got the 9700 supported via UMA; the 8900's UMA support had been around for a long time prior) (Within the BB WiFi you can do pings, try pinging the LEAF router by numeric IP addy, then try pinging google.com) I'm curious as to who is your cell carrier, and BB model. Good luck, BB data over WiFi should be a cakewalk (assuming your plan + carrier + carrier_support_for_device all support UMA). -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Packages Download URL? bug
Under both Firefox IE getting err 400 for packages. E.G. for BuC v3 packages, try: 1. 6wall.lrp [45 k] gives link of: http://leaf.cvs.sourceforge.net/*checkout*/leaf/bin/packages/uclibc-0.9/28/6wall.lrp?rev=HEADcontent-type=application/octet-stream and resultant page: === An Exception Has Occurred An illegal value was provided for the content-type parameter. HTTP Response Status 400 Bad Request === TIA for LEAF! -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Packages Download URL? bug
FWIW one can remedy the URL by removing the trailing content-type=application/octet-stream text, and get a proper URL to download. The downloaded file would seem to be the correct one for what the link indicates (e.g. the newer packages contain very recently-dated files). HTH. Mike Noyes wrote: On Mon, 2010-07-12 at 11:11 -0400, groups, freeman wrote: Under both Firefox IE getting err 400 for packages. -snip- Everyone, I have an open ticket with SourceForge Staff concerning this issue. http://sourceforge.net/apps/trac/sourceforge/ticket/11869 ( #11869 (ViewVC) – sourceforge ) -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Bering-uClibc 3.1.1-beta3 - Still some missing i2c modules
davidMbrooke wrote: there are some other core i2c modules that come from source package i2c, (for example i2c-dev, i2c-proc). Those are missing. I found that the i2c-core.o and i2c-proc.o files from the BuC3.1.1b1 release worked on my BuC3.1.1b3 setup. scott -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Bering-uClibc 3.1.1-beta3 - Still some missing i2c modules
KP Kirchdoerfer wrote: Am Samstag, 6. Juni 2009 16:45:17 schrieb davidMbrooke: there are some other core i2c modules that come from source package i2c, (for example i2c-dev, i2c-proc). Those are missing. Thx for reporting; corrected both issues for the next version. kp As a sanity check on the fix you implemented for the missing i2c-* files, might you check that the modules.dep file now contains the correct dependencies upon i2c-core, etc (e.g. by i2c-viapro)? Thanks for LEAF! scott -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] [Few] More nits re 3.1.1b2
Hi, a few more things I noticed, my perspective is functional differences between BuC 3.0b2 and BuC 3.1.1b2. no shutdown facility - /sbin/shutdown doesn't exist - /sbin/halt has no '-p' (poweroff) option =-=-=-=-=-=-=- My setup: boot from CD using pure isolinux, cfg stored on floppy (i.e. not booting of a *floppy image* residing on the CD) - Using lrcfg: if I have removed the CD from the tray then I get failure attempting to save configdb.lrp (incl unhelpful/absent error msg/feedback?) - It also leaves the floppy mounted upon exit =-=-=-=-=-=-=-=- (I filed the busybox interfaces-file parsing-netmask bug as: https://bugs.busybox.net/show_bug.cgi?id=315 ) =-=-=-=-=-=-=-=- About local.lrp - I thought that it was supposed to contain refs to /usr/local/bin /usr/local/sbin - Sorry! =-=-=-=-=-=-=-=- Thx for the responses, and for LEAF! scott -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] pppd vs Fatal signal 11 @ 3.1.1b2 (incl pppd debugging tip)
KP sent me a fix for this Fatal Error 11, which made the problem go away for me, so just a heads up that there seems to be a known problem with the PPP(oE) of 3.1.1b2. Hat tip, of course, to KP :) scott -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] More nits re 3.1.1b2
Hi, thought that I'd enumerate anything odd or minuscule possible bugs
that occur to me as I work with 3.1.1b2.
- busybox, when reading the /etc/network/interfaces file (via 'ifup
-a'), can't handle a line that says, for example:
tab_charaddresstab_chartab_char192.168.0.1
however it can read and accept the line if the there's only a *single*
tab_char between the end of the token address and the provided
numeric ip addy. This contrasts with the behaviour of BB in the 3.0b2
release of BuC, which has no problems with multiple tab chars.
- file /etc/shorewall/zones has different (greater) permissions than any
other shorewall config file in that folder
- created processes are given predictable, incrementing PIDs (versus BuC
3.0b2 which assigns random PID's)
- in the 1680 floppy installation the file from local.lrp:
/var/lib/lrpkg/local.local
contains no entries to specify inclusion of the usr/local/bin and
usr/local/sbin directories.
- Problem parsing /etc/modules
There's a new routine (compared to BuC3.0b2) for parsing the
/etc/modules file, that unfortunately breaks the reading of the modules
file if the user has employed any leading tabs or spaces before the name
of the module (indenting). The part of /etc/init.d/modutils that doesn't
work for me is this:
grep ^[a-z0-9A-Z] /etc/modules |
while read module args
do
insmod $module $args 2/dev/null
lsmod | grep -n -q ^$module || \
logger modutils module $module could not be loaded
done
which I replaced with
while read module args; do
# Only insmod lines without leading # marks
if [ ${module:0:1} != # ]; then
insmod $module $args 2/dev/null
lsmod | grep -n -q ^$module || \
logger modutils module $module could not be loaded
fi
done /etc/modules
(Yeah, I use indenting a lot to make my files more easily read).
-- My workstation=Win XP SP3.
- Problem with formatting option using imaging-1680 exe:
When running the imaging-1680 exe pulled from:
http://downloads.sourceforge.net/leaf/Bering-uClibc_3.1.1-beta2_img_bering-uclibc-1680.exe
on a blank, 1.44MB floppy I affirm (check) the options for Writing on
floppy and Formatting. On 3 different floppies I got a Disk error on
track 1, head 0; Address mark not found; the drive cannot find the
sector requested. This seems to be a bug since when I attempt to use an
older imaging-1680 exe (e.g. from
http://easynews.dl.sourceforge.net/sourceforge/leaf/Bering-uClibc_2.4.1_img_bering-uclibc-1680.exe
) the format goes fine on one of the 'problematic' diskettes (untested
on the others). And when I thereafter use the current 3.1.1b2
imaging-1680 exe but affirm only Writing on floppy I am able to have a
1680-sized floppy with the current 3.1.1b2 files.
- Possible WinImage version/licencing problem:
When I run the 3.1.1b2 imaging-1680 exe it gives a pop-up window saying
that the version of WinImage used to create the imaging exe is not
licenced for redistribution of the resultant exe. This contrasts with
the 2.4.1 imaging-1680 exe which does not offer that admonition. This
might be a no-no for a project like LEAF :)
Thanks as always for LEAF, hopefully this is helpful to the project!
scott
groups, freeman wrote:
Hi, just starting to look at 3.1.1b2 and seem to have noticed that the
folder
\2.4.34.6\kernel\drivers\i2c
is missing the the modules tarball, that I grabbed from:
http://downloads.sourceforge.net/leaf/Bering-uClibc_modules_2.4.34.6.tar.gz?use_mirror=internap
I think this may cause bustage for the sensors (monitoring) functionality?
Thanks as always to everyone for their work on LEAF!
scott
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
Re: [leaf-user] pppd vs Fatal signal 11 @ 3.1.1b2 (incl pppd debugging tip)
KP Kirchdoerfer wrote:
Am Sonntag, 29. März 2009 18:09:53 schrieb groups, freeman:
Hi, working with the new 3.1.1b2 release.
I am working with the floppy image in a pretty near-to-defaults setup,
just to try to get the pppd working (PPPoE actually).
I'm having trouble getting the pppd to behave - in the syslog I'm
seeing, every time I try to cause a PPPoE connection, my attempt ending
with:
Mar 29 12:55:54 firewall pppd[618]: Local IP address changed to
69.196.xxx.yyy
Mar 29 12:55:54 firewall pppd[618]: Remote IP address changed to
206.248.xxx.yyy
Mar 29 12:55:54 firewall pppd[618]: Fatal signal 11
[...]
So I wonder first, is anyone else successfully using pppd (PPPoE) under
BuC 3.1.1b2?
And does this 'Fatal signal 11' indicate maybe a problem with the
executable, or compile options?
I have no idea; but I'm running pppd and pppoe without pb's.
Ok, thx for the feedback - it looks like me or my setup?!
From where do you get the 10.x adresses?
They seem to be what pppd assigns as the defa...@startup ip address if
the ppp connection is a demand connection, until pppd has received an
IP addy from upstream.
=-=-=-=-
Let me update on my testing:
- I had some bad/missing settings for my PPP setup that seemed to be the
cause of all of my grief *except* Fatal signal 11.
- pppd tip: include the option:
dump
in dsl-provider file and in one of the logfiles you'll get pppd's
interpretation of what options it's seeing (it seeks options from a few
files and identifies which options from which files). This is how I came
to observe the difference between my old, working 3.0b2 setup, versus
this new one.
- pppd tip: do that logging of the 'dump'ed options from within the
init-invoked pppd (i.e. don't use 'pppd call dsl-provider' from the
shell to see what options are active - I noticed discrepancies in the
listed options depending on how pppd was being invoked).
- pppd tip: In 3.0b2 some of my options that were placed in the 'ppp'
options file (/etc/ppp/options) did not get recognized under 3.1.1b2 so
I had to move them to the pppoe options file (/etc/ppp/peers/provider)
to get respect?!?!
So what I have now is an identical set of pppd options in my testing of
3.1.1b2 as to my working 3.0b2 and I still have one showstopper prob
left, the Fatal signal 11.
My LCP IPCP transactions all happen nice (PAD*, IPCP reqs, acks, naks)
and I get assigned proper ip addy for dns1, dns2, my_ip and remote_ip,
then boom. From ppp.log:
Mar 30 11:18:14 fw pppd[631]: local IP address 206.248.xxx.yyy
Mar 30 11:18:14 fw pppd[631]: remote IP address 206.248.xxx.yyy
Mar 30 11:18:14 fw pppd[631]: primary DNS address 206.248.154. 22
Mar 30 11:18:14 fw pppd[631]: secondary DNS address 206.248.154.170
Mar 30 11:18:14 fw pppd[631]: Fatal signal 11
Mar 30 11:18:14 fw pppd[631]: Exit.
Noticeably absent is the 2 lines that should follow the 2ndary DNS line,
which under 3.0b2 says:
Mar 30 09:30:29 R11 pppd[5793]: Script /etc/ppp/ip-up started
(pid 25879)
Mar 30 09:30:32 R11 pppd[5793]: Script /etc/ppp/ip-up finished
(pid 25879), status = 0x0
In the pppd code, this is a wee walk between the line of code for the
2ndary DNS and the line of code for launching of the etc/ppp/ip-up
script where normally I would next see a log entry:
if (go-dnsaddr[0])
notice(primary DNS address %I, go-dnsaddr[0]);
if (go-dnsaddr[1])
notice(secondary DNS address %I, go-dnsaddr[1]);
}
reset_link_stats(f-unit);
np_up(f-unit, PPP_IP);
ipcp_is_up = 1;
notify(ip_up_notifier, 0);
if (ip_up_hook)
ip_up_hook();
/*
* Execute the ip-up script, like this:
* /etc/ppp/ip-up interface tty speed local-IP remote-IP
*/
if (ipcp_script_state == s_down ipcp_script_pid == 0) {
ipcp_script_state = s_up;
ipcp_script(_PATH_IPUP, 0);
}
}
- per the pppd code, the 'Fatal signal 11' /is/ in fact a SIGSEGV exception.
- Here's my minimal list of packages, sorted alpha:
config 0.6 Rev 8 uClibc 0.9.28
configdb
dnsmasq 2.47 Rev 1 uClibc 0.9.28
dropbear 0.52 Rev 1 uClibc 0.9.28
etc 3.1.1 Rev 6 uClibc 0.9.28
initrd 3.1.1 Rev 6 uClibc 0.9.28
iptables 1.3.5 Rev 4 uClibc 0.9.28
moddb
modules 2.4.x Rev 5 uClibc 0.9.28
ppp 2.4.4 Rev 3 uClibc 0.9.28
pppoe 2.4.4 Rev 2 uClibc 0.9.28
root 3.1.1 Rev 6 uClibc 0.9.28
ulogd 1.24 Rev 5 uClibc 0.9.28
- Here are my pppd options, sorted alpha:
asyncmap 0 # (from /etc/ppp/options)
debug debug# (from /etc/ppp/peers/dsl-provider)
defaultroute # (from /etc/ppp/peers/dsl-provider)
dump # (from /etc/ppp/peers/dsl-provider)
eth0 # (from command line)
eth0 # (from command line)
hide-password # (from /etc/ppp/peers/dsl-provider)
ktune # (from /etc/ppp/peers/dsl-provider
[leaf-user] pppd vs Fatal signal 11 @ 3.1.1b2
Hi, working with the new 3.1.1b2 release. I am working with the floppy image in a pretty near-to-defaults setup, just to try to get the pppd working (PPPoE actually). I'm having trouble getting the pppd to behave - in the syslog I'm seeing, every time I try to cause a PPPoE connection, my attempt ending with: Mar 29 12:55:54 firewall pppd[618]: Local IP address changed to 69.196.xxx.yyy Mar 29 12:55:54 firewall pppd[618]: Remote IP address changed to 206.248.xxx.yyy Mar 29 12:55:54 firewall pppd[618]: Fatal signal 11 (Is this 'Fatal signal 11' a SIGSEGV exception?) There's other odd stuff that happens, but this seems to be the show stopper. I do have the proper PPPoE-supporting modules loading up. When my pppd daemon loads it reports early this odd entry, in logfile messages: Mar 29 12:55:52 firewall pppd[ 618]: local IP address 10.64.64.64 Mar 29 12:55:52 firewall pppd[ 618]: remote IP address 10.112.112.112 but then proceeds to have a fruitful negotiation authentication and gets assigned a proper dynamic, public IP addy as reported in daemon.log (IPCP ConfAck id=0x2, IPCP ConfAck id=0x2d, etc) and as seen in the syslog file, but then immediately gives the 'Fatal signal 11' error. So I wonder first, is anyone else successfully using pppd (PPPoE) under BuC 3.1.1b2? And does this 'Fatal signal 11' indicate maybe a problem with the executable, or compile options? Cheers thx for any leads! scott -- leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Missing i2c folder from Modules in 3.1.1b2?
Hi, just starting to look at 3.1.1b2 and seem to have noticed that the folder \2.4.34.6\kernel\drivers\i2c is missing the the modules tarball, that I grabbed from: http://downloads.sourceforge.net/leaf/Bering-uClibc_modules_2.4.34.6.tar.gz?use_mirror=internap I think this may cause bustage for the sensors (monitoring) functionality? Thanks as always to everyone for their work on LEAF! scott -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] [write-protectable USB key-fob a boot media] What's the current way to save your changes?
Gordon Bos wrote: Craig Caughlin wrote: 1.)If you're using the Bering-uClibc CD, how do you make changes and then back those up? You'll need writeable media ;) Although deprecated the 3.5 floppy disks are still a good choice because of their write inhibit switch. The only other media I know to have this by default are SD flashcards but these may prove to be a lot harder to implement. The next time I rebuild I'd use a USB key with a write-protect switch instead of my current CD floppy - AFAIK the write-protect switches on these things are as 'non-overrideable' as the write-protect switch on a floppy. This might be a helpful ebay search to find USB key-fobs that have the somewhat rare 'external write-protect switch' feature: http://computers.search-desc.ebay.com/usb-write-protect-flash_Drives-Storage_W0QQcatrefZC12QQdfspZ32QQfromZR40QQftrtZ1QQftrvZ1QQftsZ2QQsabfmtsZ1QQsacatZ165QQsaobfmtsZinsifQQsatitleZusbQ20Q22writeQ20protectQ22Q20flash Some observations from my experience since I'm on the topic: I use the syslinux advice in setting up my USB as a harddrive (i.e. having a master boot record and partition table) and then creating a FAT partition in slot 4 (i.e. in Linux's fdisk I create a new primary partition, and create Partition Number *4*) [ http://syslinux.zytor.com/usbkey.php ] Even if your USB fob is larger, limit the size of the partition you create to be 250MB or smaller for greatest boot-from-USB compatibility (i.e. older hardware - P3, P4 single-core, etc sometimes won't boot from a partition larger than 250MB) Good luck! scott - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] [write-protectable USB key-fob a boot media] What's the current way to save your changes?
Jim Ford wrote: Is there anything against using a SD to CF adaptor, eg: http://tinyurl.com/6nzbau Then using it in a CF to IDE adapter (which is a set-up I use)? You would then effectively have a write protectable IDE disk. Jim Nope, that would do just as well ... in fact it's be a tad simpler because of the IDE connection vs USB ... but the write-protect switch would be way inside the case when it comes time for a saved change to the config. Many ways to skin a feline ;) scott - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] BuC 3.0beta2 support MP (aka MLPPP/MultiLink PPP)?
I've got a BuC 3.0beta2 box connected via PPPoE using DSL. I'm wanting to implement single-physical-connection MLPPP but it's not working, so at the top level I'm wondering if anyone has tried this (MLPPP using one or more physical connections) and had success or failure? Specifically for myself, I've tried to activate it by beginning with adding the option: mp to my /etc/ppp/options file, but then my PPP connection does not connect. The most striking message I get is this: Jun 15 10:14:48 ssh pppd[17384]: Couldn't set MRRU: Inappropriate ioctl for device According to this very lucid post: http://osdir.com/ml/ppp/2003-07/msg00061.html this 'ioctl' error can be caused by the kernel option CONFIG_PPP_MULTILINK having not been activated. So I'm wondering if someone might be able to tell me if this kernel option is active for the BuC 3.0RC2 kernel (Linux R50 2.4.33 #1 Mon Sep 4 15:52:08 CEST 2006 i686 unknown)? (And if it's not active, is it possible that someone could compile me one where it is?) PS: You may ask: why my desire for a single-physical-link MP? It's apparently one way to evade the bandwidth throttle of big brother (Bell Canada). Notably Bell Canada is not my ISP, they are the incumbent local carrier, mandated to share their physical last-mile copper ... so they are my ISP's ISP, but Bell is throttling *my* traffic. Actually they aren't throttling /my/ traffic, since I'm not a regular heavy downloader I can't even get the throttle to activate on my traffic but I'm curious about this MP feature and it apparently it can actually be done on a single physical line ... so I'm just wanting to see if I can make it work. More info for anyone curious: http://www.dslreports.com/forum/r20484600-TomatoMLPPP-released-evade-throttle-or-bond-two-DSL-lines http://www.dslreports.com/forum/r20456553-MLPPP-Guide-on-Linux http://www.dslreports.com/r0/download/1307973~5489c0c998b786b6fec6adafa42fba5e/mlppp%20guide.pdf Cheers thanks for LEAF! scott - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Missing USB drivers on USB image
Hi, I'm testing with BuC 3.1, having downloaded the USB image and dd'd it onto a 256MB USB stick. (Mobo is a very new ASUS Wolfdale.) However the bootup would not complete - none of the .LRP files get found (nf!) and finally I get the msg: /linuxrc: source: line 277: can't open var/lib/lrpkg/root.dev.own Kernel panic: Attempted to kill init! I was able to fix this (i.e. able to get to the 'login:' prompt) by adding some modules to the initrd.lrp package. The two missing USB-support modules that I think are key here are: ehci-hcd.o usb-ohci.o (though only one would presumably be needed for me I suggest that both be placed into the standard USB image so that all USB implementations are supported 'off the shelf'). Also, I noticed something of a problem if the (existing USB driver) usb-uhci was not the last item in the /boot/etc/modules file, so I'd recommend that the following 3 entries be the last ones in the /boot/etc/modules file for the USB bootable image (unless there's some good reason not to): ehci-hcd usb-ohci usb-uhci Cheers thanks for LEAF! scott - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Seeking busybox_allyes for 3.0RC2 (uC 0.9.28)
Wow, I've been around and around (e.g. BuC Dev. Guide, Chapter 1. Development) trying everything under the sun to get a busybox built - I did get it built using buildtool, but then observed that 1.2.x doesn't have the arp command which I assume was patched in. I was seeking the patch, in .svn land, I found the busybox config files, there was a folder for 1.00 but it was empty - the folder 0.60 had a .config but I figured it was too old... (http://leaf.cvs.sourceforge.net/leaf/src/bering-uclibc/configs/busybox/). So here I am having given up on doing it myself :( asking the list if someone might compile a busybox with basically all the features active... then again I'm recalling that kernel module version checking tripped me up so I had to turn that off, and there were a couple of applets that wanted libm that I turned off... Is the thing to do here is provide someone the config file I ended up with? Or maybe someone has already built something that's basically what I'm looking for ... the one applet I really wanted for my router was usleep, but I thought it'd be nice to have a more or less fully-featured busybox since I sometimes use a LEAF micro setup as a quickie drive management OS. Or if I'm really close but just need some info or direction to do it myself - when I use my new busybox the bootup panics since it thinks that vars PKGPATH LRP are empty (I'm sure they're not) ... and I'm missing the arp applet, etc :) Thanks for any thoughts or help, scott - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Seeking Samba v3 Pkg for BuCv3
Paul G Rogers wrote: I'm setting up a FAT32 fileserver and thought that LEAF would make a nice tight base upon which to build that ... and I know LEAF quite well. Pardon my asking but, why on Earth would anyone want Samba on a perimeter firewall/router?! Uh, cuz I'm not setting up a router, I'm setting up a FAT32 fileserver! I have my choice of platform here and was hoping to use LEAF due to my familiarity and its small size and modular nature. And as one might then guess, I already have a LEAF router in place protecting us all :) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Seeking Samba v3 Pkg for BuCv3
Martin Hejl wrote: Hi bino, I see that it's not just me that see BuC is to hot to just positioned as router/firewall I see BuC as Platform that we can build anything on top of it. one _can_ - but it doesn't mean that the people working of LEAF should necessarily spend their time on working on things like that (as opposed to making the core product better/more stable/more versatile for what Bering uClibc was meant to do). Well, on one hand one can propose that there is no more and no less a good reason to assemble Samba 3 versus Samba 2 - whatever was the impetus for Samba 2 can well apply to Samba 3. But as was pointed out, Samba 3 is significantly larger. That may make the possible userbase of Samba 3 smaller than Samba 2 thus reducing the justification for assembling it. However storage available to an embedded device has probably increased some fair amount over the time of Samba 2 to Samba 3, meaning that a larger package might be not so unattractive to users nowadays. (Naturally I, for one, can attest to that :) RAM is big cheap, CD's are big cheap, CF/USB drives are big cheap, etc. And I agree that someone else providing an assembled package is an option but it's not something I see in my own near future, and since - Samba was an already-provided package, - the provided Samba version (v2) is officially unsupported by the Samba people - Samba /4/ is in beta and looks to be soon released - a supported SMB service would seem to be standard/requisite functionality for something like LEA... i.e. an embedded appliance that is not a firewall - LEAF is otherwise such a good candidate for the OS of a NAS device! - LEAF is otherwise such a good candidate for the OS of /many/ embedded applications I felt that it could/would justify some effort to assemble an updated Samba 3 package. I understand that LEAF is primarily a Firewall project and so the effort to put together an updated SMB service should not be extraordinary of course, but I have to admit that I feel sad that it looks like Samba would not get updated simply due to the result being a large package. One more thing ... Flash Storage is easier to get than RAM ... at this point .. i also thinking of CRamFS. Sure. And soon enough, LEAF will be just one more not quite as bloated as the rest distro. LEAF might have a unique advantage and difference though, in that the default product is tiny and one then adds-on whatever functionality one desires ... so it's impossible for an end-user to have a bloated system unless they *want* a bloated system. And FWICT the massive collection of all-optional packages (in excess of a hundred) is a 'selling point' for LEAF. So I don't think that bloat is really concern here. If it's expected that Samba 3 would be a good chunk of work to get working then I totally agree that it's not necessarily a good expenditure of time given LEAF's primary purpose as a firewall but I'd plead that large size alone not be a package killer. In any case thanks everyone for your work on LEAF! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Seeking Samba v3 Pkg for BuCv3
Hi folks, as always thanks for everyone's work on LEAF! FWIW I'm presently on Bering v3.0 RC2. I'm setting up a FAT32 fileserver and thought that LEAF would make a nice tight base upon which to build that ... and I know LEAF quite well. I'm having some difficulty with the provided v2.2 of Samba and started to look into the Samba maillist, etc, for support. However v2.2 of Samba is no longer supported ... as of a couple of years ago no less! So I'm wondering if I might beseech someone to compile Samba v3 as a LEAF package? If there's anything I can do to facilitate this (uh, other than the compiling itself, which would be a huge undertaking for me) then please let me know! Here's what Samba provides as the most recent version 3 code: Current Stable Release: Samba 3.0.24 (gzipped) http://us1.samba.org/samba/ftp/stable/samba-3.0.24.tar.gz Cheers thanks for any assistance or info! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Using NIC DFE-580TX, Cute Mobos
Kwon wrote: Thank you for posting! Btw, what tool did you use for the above measurements? Is that a software tool and open source? A hardware gizmo called P3 Killawatt: http://www.p3international.com/products/special/P4400/P4400-CE.html Cost is approx $30; sometimes they're available on ebay. (Though it's not clear from the marketing spiel the device also tracks: hours uptime, and cumulative kWh consumed [which reset when unplugged from the power source]). Good luck on your green efforts! scott; canada - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Using NIC DFE-580TX
Kwon wrote:
I am thinking of using the following for Bering uClibc for a quiet low
power solution:
http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=301
Please post again of your findings? Thanks!
I can share with you my measurements about power consumption for one of
these:
My machine is a VIA EPIA-V Mini-ITX with a VIA C3/EDEN EBGA Processor
('CentaurHauls' 1.0GHz). I have a very similar-looking case as the one
you linked to and of course a similar DC-DC power converter board inside.
When up and running Linux but otherwise idle it draws:
V: 115.5
A: .20
W: 14
VA: 23
PF: .62 (power factor)
When in the BIOS setup (which I consider to be running the CPU @ 100%) I
measured:
V: 115.6
A: .35
W: 24
VA: 40
PF: .61 (power factor)
These were measured using a P3 Killawatt. The PC had only a CF card as
storage, and the PCI slot was unpopulated. The only fan was a 4cm fan on
the CPU. RAM was 1 stick of ??? MB.
The 'wall wart' power supply had these specs:
Manufacturer: www.sr-power.com.tw (now called?: www.srpower.com.tw)
Model: BW6012
Input: AC 100-240V 1.8A
Output: 12-14V 5-4.28A
These little mobo's, they /are/ very cute, eh?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Contrast this with conventional PC's (in firewall config with VGA card +
3 NIC's):
- a P1, underclocked, that goes down to about 20W,
- a P3-733, underclocked to 366MHz, that goes down to about 25W
Have fun!
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
Re: [leaf-user] OOT:LCD terminal
I'm not sure why the two items you linked to aren't 100% suitable for you... but matrix orbital at http://www.matrixorbital.com/ makes RS-232-connected LCD displays that also have input (buttons) functionality all built-in. A 2-line LCD like I have is something like $40-$50 IIRC. I'm using one of their 2-line displays on my LEAF box to give me some stats (but not using the inputs functionality, FWIW). HTH. bino_oetomo wrote: Dear All ... I'm thinking of using LEAF for non router function. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Bering uClibc 3.0, PPTPD and Shorewall
Eric Faden wrote: Found it. hosts.allow. -Eric Wow. I went thorough the same painful discovery of hosts.allow as did Eric (for me it was p9100). At the time I posted about this issue and made some suggestions but nothing was agreed upon between all we various opinions :) Perhaps with a another victim and the new configdb a suitable adjustment can be made to minimize the likelihood of someone else consuming hours to discover the 'reach' of hosts.allow. So...since packages no longer own particular config files (i.e. the config data is stored in a single location, regardless of the package/s that requires it) could a *menu option* be added to p9100.lrp, pptp.lrp and whatever other packages are known to be impacted by hosts.allow, that permits editing of the hosts.allow file?. (Call it a hint to the user that hosts.allow is important to the package they are configuring). Thoughts? scott - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Bering-uClibc on extended floppy images
Heh, I spent some time messing with 1680 floppies in a DOS/Windows environment. What I observed was that 1680 size isn't recognized properly in pure DOS and/or XP, so it was in my case a very unfriendly format. Given how much simpler one's life is with 1440 size disks (including, one presumes, higher reliability due to a lower density) and how free abundant 1.44 floppy drives are I just used two of 1440 floppy drives to give myself lots of room. Nowadays my happy place is where I boot from CD-ROM and save config to 1440 floppy. scott; canada Mats Erik Andersson wrote: Fellow Bering-users, in case you will never use a floppy based Bering system, please stop reading now in order not to waste your time. Possibly, you could record for future use that a maniac wrote something and you will be able to find it in the list archive, should need arise. The end conclusion is that 1730 kB payload can reliably be achieved on one floppy. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] FeatureVsBug: saving config removes 'unloaded' config files
Way back on Aug 23, regarding apkg Eric Spakman wrote: A 'complete' backup is always done for a few reasons: -it removes stale changed config files from no longer installed packages. -it's fast because the configdb is not big -it's much simpler and robust it's the removal of stale files from not-presently-installed packages that caused me some grief. I was testing sensors.lrp etc and was rebooting often so I commented out many of the packages. I got sensors working and then restored my complete set of packages. However all my previous config was gone since these packages were not installed at the time that I saved my fixed sensors configuration. This is a real booby-trap, IMO. (I was lucky as I had been backing up my floppy quite often and was able to reconstruct all my settings). To make sure this wouldn't bite me again I wanted to change the behaviour of the Save config so that it backed up whatever is specified by all of the /var/lib/lrpkg/*.local files regardless of whether that particular package is presently installed. To accomplish this I had to 1) make sure that all *.local files would live in the config.db file. I added /var/lib/lrpkg/*.local to the file /var/lib/lrpkg/config.local 2) I then adjusted apkg to use the *.local filelist, not the contents of $PKGDB: in file /usr/sbin/apkg the line cat $PKGDB | while read x; do became 2 lines ls $PKGDIR/*.local | while read x; do x=`basename $x .local` = I guess that it can be considered a feature but this propensity to remove inactive configuration data is IMO a bug. I like that LEAF has the ability to do this remove_stale_saveconfig but I'd prefer to have a separate menu option - #1) the normal, default save which works from *.local, and #2) the 'housecleaning save config' that saves only presently-loaded-package configs. Thoughts? scott; canada - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] FeatureVsBug: saving config removes 'unloaded' configfiles
Eric Spakman wrote: Hi Scott, I don't want to make the config system more complex than it needs to be, also for future enhancements like remove packages and current options like upgrade and show config changes (which will show strange output because the default config file wouldn't exist anymore). I also find the selfcleaning feature important. For myself, the value of not having an arrangement that is predisposed to dataloss my config setup is far, far greater than keeping my config housekept and as small as possible. (And I don't see that having a standard, safe SaveConfig in addition to the current HouseCleanSaveConfig would add that much complexity). I will write down a warning in the documentation that if you remove packages and want to preserve old config changes, you should scp or backup the configdb. My guess would be that few people will read it (rightly or wrongly) and even those who do will be prone to forgetting in the days/weeks/months after they read it and are messing with their system. I've gotta say that since the consequence is so grave (losing data) that I am a little bummed out that more is not being done to prevent other people falling into this trap. Anyway, such is the beaut of open source that I can fix things up for myself the way I like (only downside there is that any time I upgrade I have to port over any changes). A question, why did you need to reboot often to test the sensors package? You can load and unload modules on a running system and it's also possible to restart or reload daemons with their init.d files without rebooting. I was having no luck with the 'expected' modules needed (there are literally dozens to chose from) so I did insmod lots of *.o files to see if that gave me any success. However the last few modules would complain about being out of memory (512MB on this PC?!) so I figured that some sort of unpleasantness was going on underneath and thus rebooting was the best was to test conclusively. Anyway, thanks for considering my request and of course, thanks for LEAF! scott; canada - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] BuC3b2: USB Ethernet Adapter Success
Just sharing my success at employing a USB network adapter on BuC3 beta2. I have a USB CATC (Netlink II) adapter and found these modules needed to make it work: usbcore usb-uhci (AIUI for some people usb-ohci might be used here, instead) catc (In particular I was pleasantly surprised to find the catc LEAF module for this obscure USB adapter). Cheers thanks for LEAF! scott; canada - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] [ANN:] Second maintenance release 2.4.2 for LEAF Bering-uClibc 2.4
KP Kirchdoerfer wrote: The Bering-uClibc team releases LEAF Bering-uClibc 2.4.2 This version provides another fix dnsmasq 2.27 and the usual shorewall update (now up to shorewall version 3.0.7). Thanks! Yesterday I had observed (on BuC 2.4.1), 2 instances of the dnsmasq process disappearing from the process list ... and the obvious consequent ill effect. Previously, I had observed one instance of this phenomena but that was just after I had installed configged the whole system so I wasn't confident that it wasn't PEBKAC. So I was just about to make a post about dnsmasq dying and I saw this. Thanks as always, for LEAF! scott; canada leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] [RFE] LEAF on CD - other improvement(s)? [SysLinux/ISOLinux]
Sorry, a small word omission (**) that made obscured the functionality I was trying to describe (and made me look all-too-easily impressed). groups, freeman wrote: Instead of timing-out to the LEAF bootup, I can also elect to have the system boot a DOS diskette *image-file*, for e.g. if I want to ... Spell checkers don't get missing words, do they :( scott leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] [RFE] LEAF on CD - other improvement(s)? [SysLinux/ISOLinux]
I'm of the mindset that the way the LEAF CD-image is presently constructed is unnecessarily obtuse. Regarding BuC 2.4.1 in particular (though I recall that recent versions of BuC-from-CD all work this way): The LEAF ISO is bootable and this is effected via a floppydisk image that is stored on the CD (bootdisk.ima). This virtual diskette then boots the LEAF system (curiously, identical copies of syslinux.cfg and LEAF.cfg exist on the floppy image as well as on the CD - which copy does one adjust to effect a change?!?!) I've been using a CD/floppy LEAF config for a few years now and this is how I have mine setup. The CD boots, and first invokes Bootable CD Wizard v1.50Z - Freeware Multiple-Image Bootable CD Manager [ http://bootcd.narod.ru/bcdw_e.htm ]. This is just a boot manager. By timeout default, this BCDW then chains to isolinux.bin which loads the LEAF system from CD ( physical floppy diskette). My 'static' LRP packages are on the CD and I make 'partial' backups to the floppy. Instead of timing-out to the LEAF bootup, I can also elect to have the system boot a DOS diskette, for e.g. if I want to partition a USB/CF device, install syslinux on a H/D, configure ISA network adapters with DOS-based utils, etc. (forgive me but I 'grew up' on DOS so I'm most efficient doing things in that environment.) When booting LEAF I have on the root of the CD isolinux.cfg and on the floppy, I have the LEAF.cfg. Once I have performed any upgrade to a newer version of LEAF (for which I need to do some changes to files that are not stored as part of partial backups, so I do a full backup to floppy then move the biggie LRP file to the CD) I need to only make changes to files that are stored on floppy. A very sweet setup, IMO. So my RFE here would be: would the powers-that-be wish to adjust the boot method of the CD so as to obviate the need for a bootable floppy image to exist on the CD? IMO this would reduce confusion about how things chain to one another in the boot sequence, and perhaps be a more easy installation for new users (e.g. no need to rebuild bootdisk.ima to effect changes, and then burn a new CD)? I'm in the process of creating a FreeDOS bootable diskette image to provide unencumbered (re licencing), distributable DOS image that can be used in conjunction with the isolinux-booting LEAF CD. I'm also happy to provide my mkisofs 'recipe' since the danged thing took some time to get working correctly. Anyone interested? Powers-that-be? (FWIW BCDW is not GPL'd but /is/ freeware that has no licencing/distribution encumbrances that I can ascertain.) scott; canada ermo wrote: Hi, I'm using BuC 2.4.1, booting from CD and reading my configuration from floppy. I figured that, since all modules are on the CD, I wouldn't need to load a separate modules.lrp from floppy. But as BuC doesn't use modprobe(modutils?), it gets kinda hairy. I finally figured out what the somewhat terse comments in /etc/modules mean, but I think it might be a good idea if at least the cd version of BuC gets the following additions to /etc/modules in the standard modules.lrp (hopefully I got most of them right): # (snip beginning of /etc/modules) # Want to load modules from the official Bering uClibc cd image? Use: # ! mount iso9660 /dev/cdrom # and uncomment the (relevant) ! dir ... lines below leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] QoS for VoIP (for a QoS Newbie)
I've got myself a sweet Sipura SPA-2100 but even though it has built-in QoS routing that seems to perform superbly (http://www.tomsnetworking.com/2005/06/22/review_spa2100/page4.html) I prefer to place it behind my LEAF firewall so as to: - learn QoS - keep my LEAF unit as the PPPoE login unit, since I can get superb debugging info from it and I recently needed such debugging. My setup is BuC v2.3 with eth0=net, eth1=LAN, eth2=DMZ (where I'd place the Sipura). My DSL pipe is 3000/800. The box is a P-75 (is this enough horsepower for implementing QoS? I'd have usually one [maybe sometimes two] G.711 streams [~100 kbit/s per stream]). So ... am I a masochist for wanting to delve into QoS (since I can just use the SPA for the QoS and lose my non-critical LEAF-as-PPPoE-login functionality)? I'm self-taught in all my other stuff and don't mind learning, but is QoS a /really/ nasty beast? Does anyone have a config used for VoIP that they could share to save me a bunch of work? Any How-To's kicking around? Is QBox a good place to look for a starting setup (i.e. dissecting QBox to see how they've done it, and port that functionality over to my LEAF box)? The BuC doc'n for LEAF takes me to the doc's for Bering (dated 2003: Chapter 22. Managing QoS with Bering: http://leaf.sourceforge.net/doc/bk04ch22.html ). Is this info still largely relevant and applicable for BuC v2.3? TIA for any info, and of course, for LEAF! scott; canada leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Packages Unavailable - SF problems?!
I've noticed for the past day-ish that two packages I'm interested in (tc, qos-htb) have been unavailable from the sf website. e.g. URL: http://cvs.sourceforge.net/viewcvs.py/leaf/bin/bering-uclibc/packages/qos-htb.lrp?rev=HEADcontent-type=application/octet-stream times out eventually and gives this as the resultant document: Connection: close Seen in FF (+ Privoxy). =-=-=-=- Well, more checking in IE had one of my requests succeed (but the other continues to fail) so I'd peg this as massive-slowness at SF's end. Some wget testing shows that 85% of attempts to download are failing. FWIW I got this msg on one attempt: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /viewcvs.py/leaf/bin/packages/uclibc-0.9/20/tc.lrp. Reason: Error reading from remote server Anyway, if the problem is specific to LEAF then here's a heads up about the issue. Thanks as always! scott; canada --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[Solved?!] Re: [leaf-user] Seeking pppd debug tips
Whew, what a journey down source code lane... One thing that was killing my effort was that the debug statements in the source code were using printf's, so the fact that, by default, pppd spins itself off into the background means that one would never see the printf's at all! Wanting to find out how to keep it in the foreground I did a man on pppd and nodetach came up, however it didn't work for me (wrong pppd). Scanning the executable led me to a similar -detach which did. In the end, getting this sort of debugging info needs to be done from the *command line*. However the options (in dsl-provider, etc) will be employed... One note - the order of options in the command line, and file dsl-provider, is important. It seems the options are scanned and the lines parsed in order of appearance. This means that one cannot employ an option /that is intended for a plug-in [e.g. rp-pppoe.so]/ until *after* the plugin has been declared. So to get my access concentrator's name I issue (yes, while ppp is running in the background with a live connection): pppd -detach plugin /usr/lib/pppd/rp-pppoe.so rp_pppoe_verbose 1 call dsl-provider eth0 and I get this sort of info: Plugin /usr/lib/pppd/rp-pppoe.so loaded. RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2 Plugin /usr/lib/pppd/rp-pppoe.so loaded. RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2 Access-Concentrator: bas88-city99 Got a cookie: 01 ff 03 ff 05 ff 07 ff 09 ff 0b ff 0d ff 0f 10 -- AC-Ethernet-Address: 00:08:02:fd:fe:ff -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- :: -detach tells is not to disappear into the background so that we can the the printf() output :: plugin /usr/lib/pppd/rp-pppoe.so tells pppd to first load the plugin. The plug-in needs to be loaded or it will abend upon parsing any plug-in-specific parameter/option :: rp_pppoe_verbose 1 tell the rp-pppoe.so plugin that we want the verbose output :: call dsl-provider eth0 invokes our own DSL connection options. Normally pppd is invoked from /usr/bin/pon, which is invoked by the reference to ppp that appears in /etc/network/interfaces Fun stuff: insert the option dryrun as the first parameter of the pppd invocation and you'll get no actual ppp login but instead, an enumeration of the options that are being employed. pppd draws, variously, from /etc/ppp/options, /etc/ppp/peers/dsl-provider and the command line). My list comes up with some repeated entries indicating some sort of weirdness with the parsing of options. Thanks one and all for LEAF! scott; canada --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Seeking pppd debug tips
Eric Spakman wrote: But pppd/pppoe is logging to /var/log/ppp.log, did you also looked at that one? My ppp.log is always empty. All logging that I can find is located in daemon.log. (I've got an old ppp.log that had chat entries from a modem connection but /pppd/, in all cases, seems to log to daemon.log). Instead of adding the rp_pppoe_verbose 1 option to your interfaces file you can also try to set it as an argument in your dsl-provider script, like: plugin /usr/lib/pppd/rp-pppoe.so rp_pppoe_verbose 1 No success. The pppoe plugin's startup msg comes up but I get no connection and the ppp process seems to self-terminate. Thanks for the things to try. scott; canada Eric --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Seeking pppd debug tips
Hi, I'm using BuC 2.3 with a dynamic-IP, PPPoE, DSL connection. pppd and pppoe are both version 2.4.2 Rev 2 (current, per the packages page). I'm seeking info from my ppp(oe) software about (esp) the name of the access concentrator I'm connecting to. If I had a standalone pppoe executable I'd issue pppoe -A. (My ISP is instructing me to do this for debug purposes). I've used debug in the dsl-provider file and gotten some low-level ppp handshaking but no concentrator name. I've tried kdebug 1 to no avail. I've browsed the pppd ( pppoe plugin) code and discovered a parameter rp_pppoe_verbose (saying Be verbose about discovered access concentrators). The only place its use didn't cause an error message (and where the code indicates to me that this parm should be used) was when I put in into my interfaces file, as follows: provider dsl-provider eth0 rp_pppoe_verbose 1 (when I first omitted the 1, I got an intelligent error msg, too!) I then issued svi networking restart to re-load everything but saw no changes to what's logged in daemon.log et al. I have a specific hope that the sort of info (esp concentrator name) that I'm seeking is available, because browsing the executable gives me juicy lines of text like: rp_pppoe_verbose [...] $Id: discovery.c,v 1.2 2004/01/13 04:03:58 paulus Exp $ Access-Concentrator: %.*s (and which jive with the source code). Help?! (Thanks for any, and for LEAF) scott; canada --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [Solution?!] Re: [leaf-user] p9100 not working
Eric Spakman wrote: To the package maintainer: - is it possible to remove the dependency on /etc/hosts.allow since it would seem to be redundant with shorewall rules? It is possible to remove the dependency, but there is a reason why p9100 (and a few other packages) are compiled with libwrap support. LEAF is modular, so it is possible to use LEAF without shorewall as a pure router or printserver (or whatever), libwrap gives some extra security in the cases where iptables/shorewall isn't installed. What you say makes sense (including what followed, about hosts.allow not being part of pppd.lrp) but I'll offer this counter-position. To have two places where one must permit an IP address (shorewall hosts.allow) is a little obtuse, IMO. In terms of LEAF as a non-shorewall router, etc I'd propose that since the default LEAF distro includes shorewall that might tip the scales in favour of recognizing that shorewall rules are the better, *single* place for IP restrictions to be placed. Also, newbies (the people most likely to get tripped up by this double-permission requirement) are less likely to be able to solve this, then someone who is employing LEAF as a non-shorewall device, whose users are much more likely to be able to self-solve, recompile with libwrap support, etc. Maybe 2 pppd.lrp packages - one default for use with shorewall (no dependency on hosts.allow) and one standalone? (recognizing too that more packages = more work for the kind, volunteer maintainers). This conundrum all might all originate from trying to make LEAF do more than one thing - firewall router vs router vs print server (doing two+ things - and the commensurate double-permissions requirement, is maybe a not-unexpected outcome of trying to do more than one thing and causing neither task to be performed optimally). Is there any reason that someone who wants to use LEAF as a, say, print server, *shouldn't* use shorewall to effect IP addy restrictions? (Saving space on a floppy is obvious but is there anything more substantial? And true, adding in a complex package like shorewall vs compiled-in libwrap support exposes a greater risk of code-bug that impacts security). Anything else? :) Anyway, I'm obviously not an impartial party here but wanted to offer the devil's advocate position, in terms of identifying the 'cost' associated with the 'benefit' of this multiple-use strategy. Too, things that make life tough for newbies (I'm not one, FWIW) are a Bad Thing, again IMO. Regardless of the final decision I thank you for your taking the time to reply and explain. (I also like what Hillel Seltzer said, in terms of hosts.lpd instead of hosts.allow' and IMO think that would be a alternate, ideal solution since hosts.lpd could [TTBOMK] be safely made a part of the pppd.lrp package?!) scott; canada --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] RE: Bering uClibc Package Updates
I'm of the mindset that this is, for all practical intents and purposes, ill advised and here's my reasoning. The packages are the products of various authors, Tom Eastep for one. Unless he and all contributors were to adhere to some protocol there's the definite potential for problems. Consider that (for example) the shorewall config files often contain documentation within them. If one uses an older config file in its entirety then one will lose the documentation of new features that was within the newer config file. The old config might well work fine and as expected, but you'd not be aware of new features because the docs were in the newer config files. And there's of course the possibility of non-backward-compatibility (maybe not outright bustage but unexpected/unforeseen effects). Also, seeking support for a newer installation with older config files might leave the supporting folks confused. I have no complaint with what Tom (et al) does - I can't even fathom how things /could/ be done differently, let alone the imposition of 'compatibility protocols' upon such participants for whose work and contributions I am so grateful. I'd definitely love to see something like this but have resigned myself to death, taxes, gravity and tedious LEAF upgrades. FWIW I'm still using LEAF (BuC 2.3), 'bout 5 years after discovering this project. A thank you to Brad for seeing a 'problem' and expressing willingness to attempt to tackle it though! scott; canada (a wistful sigh, thinking back to Eigerstein days :) [EMAIL PROTECTED] wrote: I have wondered if there was any better method for upgrading from a previous version of Bering uClibc, and I assumed that what Charles said below was the best possible solution. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] lrcfg backup problem
Jim Ford wrote: I'd be interested in the experience (and workarounds) of others. I use a CD-ROM drive and find that gives me a number of benefits... - CD-ROM is read-only, so integrity of its files can be preserved - simple, no-hassle 1.44MB floppy for config changes - faster package saves since only config files are saved to the floppy - much faster bootup than using only a floppy (or two!) scott; canada Jim Ford1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
[leaf-user] Notes on mini_httpdS + webconf
Whew, that was a bit of an exercise. Some issues I discovered and some quick things that I learned - maybe this will help others. Likely I need some correction/clarification too?! FWIW I use a CD for the bulk of the packages and a floppy for 'partial' backups of the packages that I adjust. =-=-=-=- 1) The online PDF doc wasn't available while I was playing/testing so maybe all my issues/questions are answered therein. 2) I had never played with SSL or certificates so I was learning on the fly. 3) Late in the game I discovered the help option on the main (first) menu of lrcfg. It had some useful info there about mini_httpds. 4) the config file for mini_httpds (/etc/mini_httpds.conf) has a line to specify the certificate file, by default this says: certfile=mini_httpd.pem this file is actually stored in the directory /var/webconf/www. For clarity I changed my entry to read: certfile=/var/webconf/www/mini_httpd.pem This (actual directory) was evident after I peeked into /etc/init.d/mini_httpds and saw that there was a specific directory change into the /var/webconf/www directory. Note that (AIUI) if you use a different http daemon (i.e. non mini_httpd*) then that certfile line may need to be different, e.g.: certfile=/var/sh-www/www/mini_httpd.pem 5) I discovered that in order to use SSL (via mini_httpds) I'd need to acquire a certificate and thus go_through_hassles or self-sign a certificate. Guess which I chose... 6) To create the self-signed certificate one needs needs to install (albeit it only temporarily, for the purpose of this certificate generation) the openssl.lrp package. 7) I found this single command gave me exactly the certificate file that I needed: openssl req -new -newkey rsa:1024 -days 9500 -nodes -x509 -keyout /var/webconf/www/mini_httpd.pem \ -out /var/webconf/www/mini_httpd.pem 8) I chose 9500 days until expiry so as to not have to do this process again for 26 years. 9) This command causes two sections to appear in the certfile file (/var/webconf/www/mini_httpd.pem): 'RSA PRIVATE KEY' 'CERTIFICATE'. This is unusual because normally the output files mentioned on the openssl cmdline are different and thus each of the two files gets only one 'section'. mini_httpds seems to need both sections in that single PEM file. 10) It was a bit of a challenge to diagnose what mini_httpds was unhappy about because it gave no output, and the filesize of mini_httpds.log stayed at all times as zero. I got some hints about what I was doing incorrectly by removing the '2/dev/nul' parts from /etc/init.d/mini_httpds. 11) mini_httpd.pem has cooties! Nobody wants to backup this file (well, neither mini_httpds nor webconf). I fixed this by adding 'var/webconf/www/mini_httpd.pem' to file: /var/lib/lrpkg/webconf.list 12) I then did a *full* backup of webconf (to floppy) and re-burned that on my CD, because a partial backup would not backup that file. ... Should this mini_httpd.pem file be part of a 'partial' backup? Should it be a part of mhttpd.lrp or webconf.lrp? It should probably have an entry in one of the package.list file ?! 13) A funny thing happened at some point - some of the files in /var/webconf/www had their group membership removed, so they said 'nogroup'. I changed all these to be group=root. Until I made that fix I couldn't see the full index.cgi page (i.e. the column at the left was missing and all I got was the 'general information' blurb). 14) AIUI one can safely ignore all logfile entries which state socket :: - Address family not supported by protocol. This 'complaint' refers to (AIUI) the fact that I don't have IPv6 support going on. 15) happy logfiles: when mini_httpds is loaded running you'll see in daemon.log these two lines: started as root without requesting chroot(), warning only mini_httpd/1.19 19dec2003 starting on R11, port 443 16) More on generating the self-signed certificate... If you type into your browser window (for example) https://192.168.0.254 to access the webconf screen you'll possibly get notified that the certificate does not match the host you are connecting to (Domain name mismatch - firefox v1.07 warning window). This seems to be related to the Common name field of the self-signed certificate you are making. All of the fields don't matter *at all*, except this field. Basically, if this field is set to 192.168.0.254 then one won't get a complaint about Domain name mismatch (firefox v1.07 syntax). In my case, because I have an entry in my hosts file (on my usual workstation) as: 192.168.0.254 router I would be entering: https://router into my browser. Thus at the time I generated a certificate I set my Common name to be router and I don't get the domain-mismatch warning. I still have to accept the certificate though, since it is self-signed and thus not automatically trusted. 17) Curiously, the file
[leaf-user] 404 Error seeking leaf-guide-collection.pdf
This error was observed and posted by another on Oct 16 and the problem has returned (or persisted). I'm seeking to acquire the PDF doc. On page: http://leaf.sourceforge.net/doc/guide/ I click the hyperlinked text pdf version, which links to: http://leaf.sourceforge.net/doc/guide/leaf-guide-collection.pdf however I am greeted with: An error has been encountered in accessing this page. 1. Server: leaf.sourceforge.net 2. URL path: /doc/guide/leaf-guide-collection.pdf 3. Error notes: File does not exist: /home/groups/l/le/leaf/htdocs/doc/guide/leaf-guide-collection.pdf 4. Error type: 404 5. Request method: GET 6. Request query string: 7. Time: 2005-10-31 11:25:24 PST (1130786724) Reporting this problem: The problem you have encountered is with a project web site hosted by SourceForge.net. This issue should be reported to the SourceForge.net-hosted project (not to SourceForge.net). If this is a severe or recurring/persistent problem, please do one of the following, and provide the error text (numbered 1 through 7, above): 1. Contact the project via their designated support resources. 2. Contact the project administrators of this project via email (see the upper right-hand corner of the Project Summary page for their usernames) at [EMAIL PROTECTED] If you are a member of the project that maintains this web content, please refer to the Site Documentation regarding the project web service for further assistance. BTW, thanks for all the work that you folks do on LEAF. scott; canada --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] Leaf guide - Available on Archive.org
You can get a Nov 2004 version of the guide from here: http://web.archive.org/web/20041106175146/http://leaf-project.org/doc/guide/leaf-guide-collection.pdf (When sites/pages can't be found on the net but you know they used to be there, archive.org is your friend.) scott; canada Fabricio Vargas wrote: Hi Could anyone send me the leaf guide collection in PDF format? link http://www.leaf-project.org/doc/guide/leaf-guide-collection.pdf does not work Thanks Fabricio Vargas --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] uClibc Boot CD problem
Kory Krofft wrote: when Nero burns it, sh-httpd becomes sh_httpd. FWIW, this is a feature of burning proper-spec ISO-9660 CD's. That charset for 'ISO' filenames is limited (i.e. dashes are not valid filename chars) so Nero is 'helping' you by renaming the file for ya, to be compliant with the full ISO-9660 spec. IIRC Easy CD Creator has options to have it relax on how militant it is about strictly following ISO rules. Nero probably does too. Either of the following options, when passed to mkisofs (part of the CDRecord kit), will permit the dashes in filenames: -relaxed-filenames -no-iso-translate (I use the former but the it looks like the latter also permits dashes). scott; canada --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] CF DOM errors
I get
hda: packet command error: status=0x51 { DriveReady SeekComplete Error }
hda: packet command error: error=0x50
today, on a non-LEAF box I'm playing with. Curiously hda is a CD-ROM - I
get it any time I try to mount /dev/hda and there's no CD inserted. For
a h/d, IIRC it comes up only once, at boot up (I've seen it before on on
a 100 MB ole IDE h/d. My research at the time led me to conclude to
ignore it cuz it's harmless, as Matthew said.)
scott; canada
Roger E McClurg wrote:
I have a test machine that has a CF. I can boot from the CF, and access
it normally, but it gets the following errors:
{DriveReady SeekComplete Error}
{DriveStatus Error}
I have tried a number of different CF brands, but all have the same
result.
Does anyone have an idea what the problem is?
Best Regards,
Roger McClurg
[EMAIL PROTECTED]
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] My leaf crashed
Bad floppy drive/disks can give said effects. My drive/disk is currently in that transient-problem state itself (I'm fairly certain it's the drive, not the disk). scott; canada ALParada wrote: Hello, I had a problem with Leaf yesterday that surprised me a little bit. Last --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] [OT] Seeking Supplier of Assembled LCD Display
LCD displays have been used on a few LEAF boxes so I'm trying to pick any experienced or knowledgeable brains. A customer of mine has need for a 1/2-height-5.25-bay mountable LCD display, say 2x16 line (sorry, not for a LEAF box but another 'appliance' animal). What I've been having difficulty doing is locating a supplier of a complete unit - LCD, controller, bezel, mounting frame (at a reasonable price) ... so I wonder if anyone can point me in the direction of a good one? The pilot roll-out is 20 units alone so it'd end up being a good sale for a company that has previously served you well or that you/friend works at. Thanks for any leads and too, for LEAF! scott; canada --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] beep.lrp question
I think you want to be notified, audibly, once the entire system has
booted up, shorewall is loaded, etc, etc.
Me too.
I tucked in a call to my script in /etc/init.d/cron, just because it's
nearly the last thing to boot up ('S89').
Quick dirty hack that worked for me.
scott; canada
Troy Aden wrote:
This is where I am stumped. I want to use this beep tune when my system is
fully booted. I am assuming that I need to insert './etc/beep_song in some
init script but I have no idea where. Can anyone help me out?
Thanks in advance!
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering-uClibc 2.2.2 Not avalible....?
I'm getting the same thing. FWIW the ISO image is coming in OK, but I've tried 3 or 4 of the different mirrors (for the 1860-exe) and they're all failing (I tried both with my usual Moz and with IE). E.g.: The mirror you've selected, telia.dl.sourceforge.net does not currently have the file you requested. (This is an error on our part which will be fixed). Thanks for LEAF! scott; canada Troy Aden wrote: http://prdownloads.sourceforge.net/leaf/Bering-uClibc_2.2.2_img_bering-uclib c-1680.exe?download I have tried to download it from every mirror and I keep getting he mirror you've selected, url does not currently have the file you requested. (This is an error on our part which will be fixed). I their any way I could get this file? Thanks in advance! Troy --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] LRP router failing? - Alcatel SpeedTouchHome (STH)DSL line-quality info
About your 'strongest' comment... This is by no means far-fetched, IMO. We're all probably more accustomed to hardware being either working or non-working and are infrequently confronted with a situation of degradation or 'dying' gear. A story from my past: I was working in telecom - PC-based voice systems. We had an installation where we could plug a regular telephone into a jack and all was well, but when we plugged into the PC it couldn't 'see' the line. Checked with different ports, another PC, none could see the line but dang it, a set plugged in directly would work fine. We finally got around to testing the loop resistance and it was just outside of spec. The phone set was more 'tolerant' and the PC-boards were by-the-book. So the idea that different gear may be stronger or more tolerant is not off-the-wall at all. Thanks for letting us know how it all turned out. scott; canada [EMAIL PROTECTED] wrote: snip What if the Windows machine has the strongest NIC(I don't know what that means, but humor me)? It would drop no packets. Let's say the laptop is not as strong as the Win98 box, but better than the LEAF boxes (which use identical NICs, btw). The laptop therefore drops 2% to 50%, and the DachBoxen rarely lose fewer than 50%. That would also explain why the problem has been steadily worsening for the past month. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] LRP router failing? - Alcatel SpeedTouchHome (STH) DSL line-quality info
Charles Steinkuehler wrote: Thinking about this some more, I'm beginning to suspect the DSL line. If I may, would this possibility not have been obviated when Dale connected a Win98 box to the line and had no loss in pings? But taking that bad-copper theory further I'll make mention of the value of a Alcatel SpeedTouchHome DSL Modem. Someone once posted elsewhere that they'd never bother to buy a DSL line tester because the STH has such great diagnostics built-in. I'll first make mention of a great GUI for eyeballing the STH stats, without navigating the crude command-line interface: Nubz Alcatool. It can be downloaded here (for Win, Mac OS 8, 9, X): http://www.nubz.org/alcatool/Download.html To see the stats that are probably relevant for you you'll want to fire up the Alcatool, login with the 'telnet' password for your STH, then in the bottom right corner, click Line Stats, then in the new window click Line Info. This will give you (by default) download-only stats. To activate the upload stats click on ResetLine, wait a few secs, and you'll have the info. What to look for: Instead of my repeating, just eyeball this page: http://www.dslreports.com/faq/6728 (ignore the stuff about 'Expert' password - the Alcatool handles all that invisibly). Me, I'm on a 3.0 MB service, but have been downgraded (by the techs at my local central office) to a 1.5MB 'profile' because I'm 'measured' as 5 km from the CO (as the copper flows, so to speak). FWIW I run happily and merrily at 98-101% 'capacity occupation', 5-6db noise margin so take the suggestions of limits mentioned the dslreports as suggestions and not as carved in stone. If you do want to have a change to your DSL profile and are currently on Fast Used ATM rate (you can tell because those fields are 0 and the 'interleaved' fields are = 0) and are pushing the limits (i.e. = 6db noise, 97% capacity occupation) you could ask the CO to change you to interleaved ATM rate. The effect is an increase (IIRC: 5-10ms) in latency but throughput remains basically unchanged. Or you could have then just change you to a slower profile, staying as Fast ATM rate. Or both. I've also observed that a newer STH modem (i.e. 'G' series) gives me a higher speed connection than an older, K-series STH modem. Good luck. scott; canada --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] basic functionality/usability questions
I hope that the 'powers that be' cast an eye on this because it might be worthy of a change. From the PPPoE package, in the file /etc/ppp/peers/dsl-provider, there is a parameter labelled as follows: # Set maxfail to 0 for unlimited connections attemps maxfail 10 As indicated, the default package has this parm set to 10. As I read this, if your PPPoE connection does not come back up after 10 re-attempts, the PPPoE module shall stop trying. So you may wish to change this to zero, and see if that makes your machine more resilient to temporary outages. If my understanding of this parameter is correct perhaps the Bering team will want to change this to value to be 0, for the default package? Thanks for LEAF! scott; canada Kevin Kloet wrote: I've been using bering for a while and more recently bering-uClibc. I've been able to sort out my technical problems and the system works very reliably for me. however, due to my lack of linux prowess, i've never found out how to do basic things that i'd take for granted in a commercial solution. take for instance when there's a connectivity problem on my ISP's end - should bering automatically restore the connection when it becomes possible to do so (ie. the ISP sorted the problem)? i don't know how to do something like release and renew the IP (using PPPoE, btw). normally i restore the connection by hard or soft rebooting the router - but it's not a very elegant solution and I really should know better - i'd love to be enlightened. i'd also like to be able to tell what he problem is from within bering (ie. if my username and password is being rejected by my ISP because their authentication server is down). if one of more of you could lay out that procedure and any other basic functionality/usability i might find useful i'd appreciate it - some recommended reading would be just as good. cheers guys. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] RFE's for LEAF - auto-run LRCFG in root pkg, using local.lrp, 720K support, beeping/sound, PPP delay at boot-up, verify saved LRP packages, persistent 'confirm writes' setting
Hi folks, thought that I would toss out a few RFE's to see if I can encourage their inclusion. I'd be very happy to spend some time to make inclusion as easy as possible for the Bering Team, if any of these changed are desired. 1) LRCFG is invoked from /root/.profile The default installation has 'lrcfg' auto-run at boot-up. This is the first thing that I turn off because only about a third of the time am I logging into my box to make use of the (fantastic, BTW) menu system. However this appears in the /root/.profile script, which means that one must backup the /entire/ root package to save the change (and re-burn it to CD-ROM, in my case). - Suggestion: move this invocation from /root/.profile into /etc/profile where a backup of the ETC package will save the change. 2) using local.lrp to override the login-script Again, on the login-script issue ... the way that I have extricated my customized changes of the login script of a new release is to have a script (login_all) saved in my LOCAL package. I then adjust the /etc/profile script so that instead of the contents just being executed, it looks like: if [ -f /usr/local/bin/login_all ]; then . /usr/local/bin/login_all else ...whatever was originally in this file fi This is the sort of change that would not negatively impact anyone else (unless they also have a login_all script) but would lead people to perhaps make better use of the LOCAL package. The value of this change depends on how many people adjust the auto-login script (including alias definitions). (BTW it's not unheard of, given people's desire to adjust the command prompt, etc). 3) There's no 720K diskette support. I would normally use one occasionally to transfer files (since I seem to have lots of them and many fewer 1.44 disks). Perhaps this support could be added with minimal cost to time/package size? 4) beeping First, thanks again to Eric Spakman who responded to my bleating and put together a uClibc BEEP.LRP package. I find this thing /really/ useful, to let me know when my LEAF box has detected a drop in my DSL connection, as well as giving me feedback when I'm backing up packages (I get 'failure' sounds if a backup fails for some reason and before the sound effects I had to carefully read the screen to know if success was achieved or not, waiting for one backup to finish before I could keypress to start the next backup). I wonder whether including the beep executable (5K uncompressed) into a main package (initrd?) might be considered. It could be globally invoked (say via a script called do_beep) and as such could be globally controlled via some setting, so that those who want a silent/noisy box could easily make it so (maybe have the default to have beeping off). I have a script that invokes some predefined sounds so that I don't need to redo a full command-line of various frequencies durations, every time I want a sound effect: - good (a 1-note, quick, high-pitched tone) - goodfinal (a 3-note, high-pitched tone) - bad (a 1-note, low-pitch tone) - badfinal (a longer, 2-note, low-pitch tone) - ping (a 1-note, very quick, 'heartbeat' beep - an indicator of progress happening, e.g. waiting for a ppp connection to come up) - link_up (a 3-note, very quick, escalating-freq effect that tells me when my PPP connection has come up; similar to what presently appears in /etc/ppp/ip-up) - link_down (inverse of link_up, for notifying me when my DSL has dropped) I'll propose that my wish to include these sound effects is not /completely/ off-the-wall, since this effect is already employed by the ipup ip-down scripts of the PPP module. 5) ppp delay at startup I find that when I reboot my DSL modem and LEAF, my LEAF box gets ahead of my modem and I need to reset things manually to get the connection up. Obviously fine for when I'm here but a bummer if the power drops and my LEAF box reboots unattended. In /etc/init.d/networking I added in a call to a delay script (stored via LOCAL.LRP!) that is a delay loop that stops waiting when a ppp device is found via ip route. If this feature is useful to other people perhaps it might be included with base packages? 6) In setting up my 2.2 system at one time I ended up with a corrupted ETC.LRP file (the worst one to get corrupted - it figures). Might it be desirable to have a configurable setting in the LRP backup script, where one can request that a gunzip be effected upon the newly-saved-to-floppy to verify that the file is readable and not corrupted? (Goes well with do_beep badfinal :) 7) The 'confirm writes' setting is not saved between invocations of LRPKG. Is this feature worth adding in? (I adjust the default to he CWRT=OFF, myself, but have to backup the entire CONFIG package to save the change - it beats having to turn if off every time I go to do a backup). As always, thanks for LEAF! scott; canada
[leaf-user] Should RC Candiate Releases Have Significant Changes Made to Them?
Hi folks, first let me say that I love LEAF and really appreciate all the time and effort that is made by people to produce formal releases, etc. But I'd like to share my slight disquiet, if I may. I've been working through the most recent beta releases of uClibc 2.2, awaiting the final release beast so that I could nail-down on that one and then go back to having my lovely, stable LEAF box and have it run for a year or two before I felt compelled to upgrade again. Back a few releases on the 2.2 beta/RC tree, I recall seeing: Changes between 2.2.0_b4 and 2.2.0_b5 initrd * switched to dash with echo and hetio patches which to me seems a bit strange, changing the shell (if I read that correctly) well into a beta release cycle. But things went smoothly and I personally benefited from the 'echo' patch (I think). Then... Changes between 2.2.0_rc1 and 2.2.0 weblet * splitted weblet contents and sh-http server which seems to have ended up with a couple of minor bustages - the missing blank.gif and the text/html issue? Now I can't say that the weblet split was the cause of the subsequent bustages but just in general, would one normally make changes such as splitting a package, after much beta and RC, right before a final release? I tend to think that no, not normally. So I just wanted to posit that /my/ preference, in terms of a release moving through beta and into RC and finally full release status would be for it to settle, with as little feature _addition_ as possible, afore it becomes a formal release. Ideally a release would live as RCxx, become accepted then move to full release-grade with usually no changes made at all? I guess that milestone releases such as Eiger, Bering 1.0/1.2, etc, seemed to be so very well vetted that the recent intra-beta changes seem to be not in keeping with that tradition and (trying not to sound snotty about it all) I would say that right-before-release-changes have had the somewhat predictable effect of having the full, final release - 2.2 - quickly discovered as having some avoidable bugs within. (FWIW it's not entirely easy for me to 'complain' about how the 2.2 release was 'administered' - since I'm a beneficiary of the donation of time that others have made. But I care about LEAF, and have proselytized widely about this product [and shall continue to do so!] and feel that this is one instance where things could have been done better ... so I'm speaking up. Confronting this nagging-in-my-mind issue is merely indicative of the fact that I care about this project.) I apologise if any toes were stepped. :) And again, thank you to everyone who contributes to, and participates with the development of LEAF. I STILL love it! scott; canada --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Should RC Candiate Releases Have Significant Changes Made to Them?
Martin, thanks for your thoughtful feedback. Sorry about mis-appraising that the blank.gif issue was newly introduced. For a suggestion in terms of QA, in a perfect world (I don't where to find it either, BTW) I imagine that one would embark on a new release with an idea of what one wanted to achieve. If a security bug were discovered part-way though that would warrant being added, on the fly, to the desired new-functionality-in-the-release but once, say, a 5-step beta was half-way though I would propose that new stuff try to to be added to the mix. The way to achieve this would be, I guess, forks, akin to the way that Mozilla has done with the various milestones branches. Obviously, however, there is none of the /huge/ base of developer manpower here nor the broad userbase nor the need (per corporate-product-embedders) that Mozilla has ... so the 'demand' would not seem to to merit the additional time complexity on the part of developers - at least to the degree that Mozilla has done (including FireFox - 4 branches, as of July this year). In a more practical sense, would it be feasible and not-too-time-consuming to maintain 2 branches of the BuC development - one that works on a 'stable' release base and one that works on bleeding-edge stuff, with the idea that some time in the near future the bleeding edge shall move to stable? I've no idea about the demands that would place on others and would positively respect a decision as simple and terse as yes, more work - not interested. (Not that I'm asking for a 'decision' - I guess that I've achieved something here by talking about it and becoming better informed myself, as would hopefully other readers). Also, akin to what you pointed out - everyone (non-developer) may well just be using the 'stable' branch, thereby not giving the beta/bleeding-edge branch much of a workout so any bugs therein would not get noticed until they became a stable release anyway. Again, thanks for sharing your side of the equation. I understand better, your/the-BuC-team's decisions. And no, I've seen no open-toed shoes at all! I just wanted to be extra careful about 'complaining' about the decisions of others, others who devote orders-of-magnitude more time than I to this project and for whose efforts I am truly grateful. My usual sign-off for posts here: Thanks for LEAF! scott; canada Martin Hejl wrote: freeman groups wrote: Then... Changes between 2.2.0_rc1 and 2.2.0 weblet * splitted weblet contents and sh-http server which seems to have ended up with a couple of minor bustages - the missing blank.gif and the text/html issue? Since I was the person guilty of that - can you show me the version of weblet that included blank.gif? As far as I can tell, this file has been missing forever, and it was noticed (or rather reported) shortly after the release of 2.2 - so that one didn't have anything to do with the split. You're right about text/html issue though. Now I can't say that the weblet split was the cause of the subsequent bustages but just in general, would one normally make changes such as splitting a package, after much beta and RC, right before a final release? I tend to think that no, not normally. Depends. In theory, the split was simply a packaging change - not a single line of code/config was changed (if I remember correctly). So, it was deemed worth the risk to go with that. That a file was lost during the packaging change was unfortunate, but sh*t happens ;-) So I just wanted to posit that /my/ preference, in terms of a release moving through beta and into RC and finally full release status would be for it to settle, with as little feature _addition_ as possible, afore it becomes a formal release. Ideally a release would live as RCxx, become accepted then move to full release-grade with usually no changes made at all? Feel free to propose a QA scheme for a release cycle. But with the given manpower, I'd guess it would simply mean longer timespans before new features can be released. QA (if properly done) takes time, and that time cannot be used for development. So unless there's a much larger userbase that's willing to test a beta release, I don't see a way to change that. Yes, one could have thown in another release candidate instead of releasing 2.2 - but I doubt the error would have been found (since the people who are willing to work with a beta are often the ones who feel most comfortable on the console, as opposed to a web browser - which is, unfortunately, also the case for the core developers of Bering uClibc). Maybe that assessment of the LEAF user-base is wrong - I'd be happy to be corrected. I favour the release early, release often approach. Yes, it means that bugs will slip through, but it also means that new features don't sit on the developer's harddrive, before the majority of users can use it. And it means that bugs are spotted more quickly, because more people test
Re: [leaf-user] editing lrp files in windows
The easiest thing might be to ssh/telnet/serial-port-terminal into your existing box and 'clipboard-copy' off the relevant settings. Note that the editor (at least as I have it set - 'e3' mode, IIRC) does auto-indenting so pasting things that are indented leads to staircase-shaped indentation. Another choice is to use WinSCP (v3.6.8, current as of 04/08/25: http://unc.dl.sourceforge.net/sourceforge/winscp/winscp368setup.exe) to copy off the config files in question, then upon the new setup (you'll have to setup enough of a base system to be able to ssh/SCP back in), copy the config files back over. Note that you'll lose any updated doc'n/version-identifiers that would have appeared in the newer config files, by replacing them wholesale with your older ones. Also, you can fully 'unzip' the .LRP files by renaming them to be whatever.TGZ, and then winzip is able to handle them as the tar/gzip files that they are, and then you could do the editing/copypaste fully on your windows box and then presumably re-zip (actually re-tar + gzip) them up with WinZip - this last step I've never done so I can't say for sure that WinZip will co-operate. Remember that most Win/DOS editors end lines with CRLF, instead of *nix's LF-only. I recommend DOS2Unix (which converts CFLF into LF: http://gatekeeper.dec.com/pub/micro/pc/simtelnet/msdos/txtutl/dos2unix.zip and if you need to do the reverse (to make things more usable on your Win box, pre editing, the above-mentioned zip file also contains Unix2DOS.exe). From an encouraging and sympathetic, fellow Windoze-prisoner... scott; canada [EMAIL PROTECTED] wrote: I am running Bering uClibc 2.1.3 and am going to upgrade to 2.2. Since I am happy with most of my settings in my current 2.1.3 I wanted to copy and paste a lot of my settings from the old to the new. I only have windows OS machines so I was hoping there might be some text editor that runs in windows xp to copy text from my .lrp files and paste them to the new release. If not, then I will write all my settings down by hand and then retype it in the new release. . What a beating!!! Thanks, Andrew --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Bering uClibC ISP Problem - stalled web-page loading, etc - PPP(oE), MTU, MRU, CLAMPMSS
Prefix:
Well, I'm sure glad I searched the maillist further (looking into my
hunch of MTU/MRU issues), my problem was solved with the CLAMPMSS=yes
setting in shorewall's 'Config' file.
So the rest of this email is perhaps only of use to anyone who stumbles
down my well-worn path, except for one question:
Regarding the CLAMPMSS setting, it is noted in the config file that:
# MSS CLAMPING
#
[...]
#This is used to overcome criminally braindead ISPs or servers which
#block ICMP Fragmentation Needed packets.
About the 'criminally braindead ISP' comment - since my situation is
that I'm shifting my login from one router at my ISP to their other
router (by way of changing my login name - they bought out my former ISP
and I was recently caused to use the new ISP's login router
[problematic] vs the original login router [working fine]) I'd like to
know how large a bunghole I should feel in justified in tearing into my
'new' ISP, for their 'braindead' setting.
I'm also wondering if there's maybe an RFC I can cram down their throats
or some such, that authoritatively points out their dead brain?
Sorry for the heated words but I've just spent about 16 hours working
around my 'braindead ISP'... :( :( :(
In the end though, LEAF (and this list) have come through and solved my
problem - so thanks for LEAF and the people who contribute to this list!
scott; canada
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I'm using Bering uClibc 2.2.0b5, with a DSL net connection and I'm
stumped...
I was setup with an ISP who has sold out to another. My login details
with the first ISP ([EMAIL PROTECTED] - aka nbn login) have
persisted under the new owners. A couple of days ago I'm having trouble
completing PPP connections - PAP auth goes through OK but the connection
would not complete. I call their tech support who tell me to change my
login to be off their own router (some customers are having a similar
problem to mine and this seems to cure them), via
[EMAIL PROTECTED] (aka ody login). Happiness - PPP comes up OK
and my LEAF box makes pretty sounds (thanks for beep.lrp!).
But... I can't go anywhere - www page loading fails, outbound VNC
connects fail, etc.
Using wget I've observed that I can get some %'age of a web page, for
instance. In the case of the ibm.com webpage (~26,000 bytes total) I
often get a complete timeout (0 bytes) or sometimes 2,421 bytes, or even
as much as ~13,000 bytes. Interestingly the number of bytes, though it
varies, is often one of a few different numbers (1,086 bytes, 2,421
bytes, etc). FWIW wget indicates (when using the 'ody login') that the
ISP's cache is always 'MISS'ing (X-Cache: MISS from cache.ody.ca).
Pinging works 100% of the time (e.g. to www.yahoo.com) on both logins.
Now, about this secondary login ('ody') - they run a proxy server upon
it. Might this be the source of my misery? Is there anything I
can/should do to my LEAF box to make it play well with their proxy? Is
the proxy issue moot since ... I can connect to a POP3 server and have
some interaction with it but the connection hangs after (presumably)
only a couple'a hundred bytes? I would expect that there's no
caching/proxy going on for an outbound port 110 connection to a small
ISP's POP server?!?!
More curiosity ... I use dyndns and my ipupdate.lrp works well and gets
the proper IP addy I've been assigned (via http://checkip.dyndns.org, a
web page which I can retrieve in its entirety - it's presumably small
enough). But when I visit http://.privacy.net, who display for you
your IP addy and reverse-DNS hostname, I get an incorrect IP addy and a
hostname of squid1.ody.ca (the incorrect IP addy is presumably that of
the caching proxy server, as indicated by the hostname). So this is
weird - I would expect privacy.net to give me my proper IP addy and not
that of my caching proxy?!?! Is this indicative of a possible proxy
misconfig at my ISP's end?
Shorewall's logfiles show no activity so it's not a port-blocking issue,
especially since from a given source (www, pop3) I can get /some/ data
but not much before the connection 'hangs'. In fact there is no action
from any of the logfiles at all (i.e. files in /var/log).
Regrettably, my ISP says they only support PPPoE connections directly
off of a Windows box and as my luck would have it when I connect my eth
directly into my XP box (and using 'nbn login') I get proper web access,
etc.
(As an aside:
- the original login is now working but I'm concerned that it's not
stable/reliable [older Cisco router, due to be replaced within 2 weeks]
and that my ISP may impose the proxy [or whatever is causing me the
grief with the 'ody login'] upon this other 'login' so I feel that I
need to figure this thing out and get it behaving with the 'ody login'.
- I created a base uClibc (2.2.0b5) floppy image and changed as
little as possible to give me access to the net and it gives the same
symptoms as with my fully-customized
[leaf-user] How do I set 50-line mode for VGA console (Bering uClibc 2.2b5)
For SSH ttyS0 I can achieve this but I cannot figure out how to have my VGA monitor console on my Bering uClibc box give me 50 line display, akin to the DOS command mode con lines=50 cols=80 I've tried adding each of the following to isolinux.cfg (even separately testing with syslinux.cfg) but none had /any/ effect: vga=2 vga=ask vga=ext vga=extended etc. In my reading I've discovered that I may be in need of one or more of: setfont svgatextmode vidmode (aka rdev) fbset but these all seem either unavailable or can't be found in handily, pre-compiled uClibc versions or appear to be unduly complex. Is there an easy way to do what I want? Even a complex way? Thanks for LEAF! scott; canada --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering uC 2.2b5 bug? shorewall: handling of two 'blacklist'ed interfaces
From Tom's response I gather that he'd directing me to the shorewall doc'n in order that I might provide more diag info. (In my own defence I would propose that I had been compliant with what's suggested therein: If you receive an error message when starting or restarting the firewall and you can't determine the cause, then do the following: ... I thought that I had somewhat identified the cause - two blacklist-optioned interfaces - but am truly more than happy to provide additional info... =-=-=-=-=-=-=-=- Make a note of the error message that you see. local: 8: eth1:0.0.0.0/0: bad variable name =-=-=-=-=-=-=-=- shorewall debug start 2 /tmp/trace Well, the entire output is ~ 36,000 lines so I'll not include it. The context for the error message (which appears on line 7,685) is: [...] + echo eth0:0.0.0.0/0 + interface_has_option eth1 blacklist + local options + chain_base eth1 + local c=eth1 + true + echo eth1 + return + eval options=$eth1_options + options=dhcp + list_search blacklist dhcp + local e=blacklist + [ 2 -gt 1 ] + shift + [ xblacklist = xdhcp ] + [ 1 -gt 1 ] + return 1 + interface_has_option eth2 blacklist + local options + chain_base eth2 + local c=eth2 + true + echo eth2 + return + eval options=$eth2_options + options= + list_search blacklist + local e=blacklist + [ 1 -gt 1 ] + return 1 + interface_has_option ipsec0 blacklist + local options + chain_base ipsec0 + local c=ipsec0 + true + echo ipsec0 + return + eval options=$ipsec0_options + options= + list_search blacklist + local e=blacklist + [ 1 -gt 1 ] + return 1 + local hosts=ppp0:0.0.0.0/0 eth0:0.0.0.0/0 *** ERROR MSG HERE *** local: 1: eth0:0.0.0.0/0: bad variable name *** ERROR MSG HERE *** + find_file blacklist + local saveifs= directory + [ -n -a -f /blacklist ] + saveifs= + IFS=: + [ -f /etc/shorewall/blacklist ] + echo /etc/shorewall/blacklist + IFS= [...] =-=-=-=-=-=-=-=- Look at the /tmp/trace file and see if that helps you determine what the problem is. Nothing enlightening for me. Be sure you find the place in the log where the error message you saw is generated -- If you are using Shorewall 1.4.0 or later, you should find the message near the end of the log. I didn't see any error msg at the end of the file, instead it appeared to occur in the place where one would expect it - in the early part of the shorewall sequence. =-=-=-=-=-=-=-=- =-=-=-=-=-=-=-=- I've reviewed the support docs, etc, and am inclined to think that I've provided everything that I reasonably can in terms of reproducibility and figuring out what triggers the 'error'. To reiterate some comments I made previously: I ultimately verified this with the 'virgin' floppy image of 2.2b5. IOW I booted up a 'virgin' 2.2.b5 floppy, added in the blacklist options to the two interfaces, executed an 'svi shorewall restart' and observed the indicated error. FWIW, if one or the other of the two interfaces in /etc/shorewall/interfaces is given the 'blacklist' flag then all is well, the problem only arises if both are flagged. So I tend to think that the problem originates from 1 interface having the option of 'blacklist'. =-=-=-=-=-=-=-=- If I'm omitting some obvious test method or info then please forgive me and let me know what I should be doing next. I have omitted identifying the shorewall version assuming that identifying the platform as Bering uClibc 2.2b5 would be sufficient. In case it's not: [EMAIL PROTECTED] /root # shorewall version 2.0.5 FWIW this appears to be a new bug in the b5 release - checking with an offsite up-and-running b4 release indicates that it doesn't complain (bad variable name) about two interfaces having the blacklist option: Adding Common Rules Setting up Blacklisting... Blacklisting enabled on eth0 Blacklisting enabled on eth1 Adding rules for DHCP As well my up-and-running Bering 1.2 system doesn't mind two interfaces having the blacklist option either: Enabling RFC1918 Filtering Setting up Blacklisting... Blacklisting enabled on ppp0 Blacklisting enabled on eth0 Setting up Kernel Route Filtering... =-=-=-=-=-=-=-=- Personally, I have a sneaking suspicion that it /might/ have something to do with the new 'dash' that is the shell on 2.2b5, but that's just a (long) shot, in the dark. Thanks for LEAF! scott; canada Tom Eastep wrote: freeman groups wrote: Playing around with 2.2b5 I gave it my usual setup which includes having two interfaces flagged as blacklist-respecting (via /etc/shorewall/interfaces) even though I don't have any entries in the blacklist file. Thus, upon shorewall's startup it gives this error message (middle line): Adding Common Rules Processing /etc/shorewall/initdone ... local: 8: eth1:0.0.0.0/0: bad variable name See http://shorewall.net/troubleshoot.htm under shorewall start and shorewall restart Errors Setting up Blacklisting... Blacklisting enabled on eth0:0.0.0.0/0 -Tom
[leaf-user] Bering uC 2.2b5 bug? shorewall: handling of two 'blacklist'ed interfaces
Playing around with 2.2b5 I gave it my usual setup which includes having two interfaces flagged as blacklist-respecting (via /etc/shorewall/interfaces) even though I don't have any entries in the blacklist file. Thus, upon shorewall's startup it gives this error message (middle line): Adding Common Rules Processing /etc/shorewall/initdone ... local: 8: eth1:0.0.0.0/0: bad variable name Setting up Blacklisting... Blacklisting enabled on eth0:0.0.0.0/0 I ultimately verified this with the 'virgin' floppy image of 2.2b5. FWIW, if one or the other of the two interfaces in /etc/shorewall/interfaces is given the 'blacklist' flag then all is well, the problem only arises if both are flagged. Thanks for LEAF! scott; canada --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Re: Bering-uClibc 2.1.3 Question (2. PS1)
This is what I have in my /etc/profile. It gives a shell prompt akin to:
/var/log #
It also updates whenever I change to a new directory, in terms of
adjusting the prompt to indicate the new current directory that I am in.
Can ya tell, I'm an ole DOS hag ;)
--
unalias cd
# this line below gives full path
cdx() { cd $* ;export PS1=`pwd` # ;}
# this line below gives only current folder
#cdx() { cd $* ; export PS1=`pwd | sed -e 's/.*\//\//g'` # ; }
alias cd=cdx
cd
--
This final cd makes the first shell you see upon login prompt the
newly-defined one. Otherwise it shows the standard '#' as the prompt
until you invoke some sort of 'cd' command.
Another version of the cdx() function, if you have multiple boxen and
want to indicate the username hostname where you are sitting, is:
cdx() { cd $* ;export PS1=`echo -n [EMAIL PROTECTED] `pwd` # ;}
scott; canada
M Lu wrote:
With bering shell, you can set PS1 but then you cannot use 'cd' and see the
new directory. So the way I do is that I have to define a new command, e.g.
'nd' inside /etc/profile like that
export PS1=`pwd`
nd(){ cd $* ; PS1=`pwd` ; }
now you can use 'nd' instead of 'cd' and it will show the current directory.
It is not very convenient but if you need to know where you are, you can
always type 'nd .'
If anybody knows of something more elegant, please share with us.
Thanks.
Chris Lee [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi,
Some Newbie questions:
2. PS1
It is possible to set PS1, so that it show current folder? (e.g. [firewall
/etc] #)
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] PPPD and dynamic dns (pppoe)
Erich Titl wrote: Scott List I don't have an ip_ip.d nor an ip_down.d ... I am using the stock PPP.LRP PPPOE.LRP packages ... so maybe you're talking apples and I'm eating oranges? M... this is from Bering 1.2 ppp.lrp tar tzf ppp.lrp ... etc/ppp/ip-down.d/ etc/ppp/ip-up.d/ ... Oooops, my bad - it appears that I was actually having a delicious banana (looking an an old setup's .LRP extractions) called Bering 1.0. My *sincere* sorry for the misinfo. scott; canada --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] PPPD and dynamic dns (pppoe)
Via BEEP.LRP my Bering 1.2 box makes lovely, helpful sounds (hint, hint :) when the link goes up down. This happens from within scripts /etc/ppp/ip_up /etc/ppp/ip-down so AFAICT you should be able to get notification via these scripts. I don't have an ip_ip.d nor an ip_down.d ... I am using the stock PPP.LRP PPPOE.LRP packages ... so maybe you're talking apples and I'm eating oranges? My DSL modem is configured to be a pass-thru bridge, so all the PPP/PPPOE brains lie within my LEAF box. One possible way that you can check for the up/down status is to see if your defaultroute has disappeared, something like (pseudocode): if ( ip route | grep default ) = then link is down... else link is up... endif scott; canada Erich Titl wrote: Hi everybody I am playing with ppp/pppoe and VPN connections on Bering boxes. The nature of VPN requires the ipsec connections to be restarted when the IP address on the gateway changes, Having little experience with pppoe and no inclination to invent the wheel once more I'd like to ask for a few pointers - Is there a method which is invoked at IP change (comparable to dhcp hooks) - Is there an easy way to detect a line down condition on the DLS end, e.g. does PPPD report this somewhere? I already tried to to set a few scripts in ip_up.d ip_down.d to now avail yet. Thanks for hints Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] login and password - CR,LF DOS2Unix
Sorry to KP for originally sending my reply only to him ... pesky reply-to setting of this LEAF list :/(yes, I know...) K.-P. Kirchdörfer wrote: If you can edit leaf.cfg with a decent editor (not adding CR/LF) like notepad, I was curious about this because my recollection was that notepad didn't handle LF-only files very well and I made these observations (I'm running XP Pro SP-1 and the notepad program that comes with). When I described below how I opened any file I had, in advance, removed all CF with the DOS2Unix proggie. A hex-viewing of the files confirmed that DOS2UNIX was doing what I expected... - notepad displays the LF as a box-like character and doesn't start each line on a new line like one would expect - one is presented with a continuous stream (line) of characters - in a file of 5 lines with each line having only 1 character (hey, I was just quickie testing) plus the LF I was presented with 5 box-characters and no single-char-per-line characters that I had therein?!?! - in a file with multiple blank lines at the top I was also presented with a stream of box-chars but no single-char-per-line chars - if one has multiple lines in the notepad doc and one saves it, then one gets the CRLF end-of-line action - at one time I had opened saved a file with notepad (making no changes to the file) and notepad had prepended two chars to the file - 0xFE 0xFF So if I may, I'd probably not suggest use of notepad to people as it doesn't play nicely with LF-only files. I am guessing that it looks at the first 1 or 2 chars of a file and makes some determination about the filetype, and doesn't recognize LF-only-delineated files very well. My suggestion is for people to edit any files to their heart's content with their editor of choice and when done, run the DOS2UNIX utility which strips the CR chars. It works under pure DOS as well as a DOS box under XP (and I would expect 9x, ME, 2K, NT as well). It can be d/l from: http://gatekeeper.dec.com/pub/micro/pc/simtelnet/msdos/txtutl/dos2unix.zip Thanks for LEAF! scott; canada --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Seeking uClibc Compile of Beep.LRP
K.-P. Kirchdörfer wrote: You may try to compile it yourself - it isn't that hard to set up an uClibc environment: http://leaf.sourceforge.net/mod.php?mod=userpagemenu=91018page_id=52 kp Thanks for the suggestion KP but this is way beyond my ability at this time as I have two in-use Linux boxes - one LEAF router and one Debian mail server (both stable and not a place for me to 'learn' compiling) and no experience in compiling anything Linux, tho I'm an old MS C v6.0a (compiler) hack. The thing that impedes me is the initial setup of a Linux-running compile-box; I wish that I could find a .IMG (or even a DriveImage .PQI) of a complete Linux system that I could dump onto a h/d and boot up. From there I could probably manage the untarring of code and invoking 'make something-or-other' but it's the initial setup of libraries, paths, etc, that dissuades me. In any case might I ask again for the LEAF community to consider my request for someone to compile BEEP.LRP since it won't be happening at my end anytime soon? Thanks one and all for your work on LEAF! scott; canada --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] uClibc 2.2.0b4 RFE^2 - Enhanced support for dropbear's login banner
How about a super-sized RFE? Basically, it might be a GoodThing to have some default banner for the dropbear service which states that'unauthorized access is prohibited', etc. This would, by default, provide some foundation upon which criminal charges could be brought against someone attempting to infiltrate one's LEAF router (possibly difficult or impossible if there is no clear warning about unauthorized access) or simply act as a deterrant. It would also make an example of how the banner must be a filename and would assist those who wish to employ/change such a banner. To effect this for myself I made the following changes: - created file /etc/dropbear.banner which contains: This router is private property. Authorized access ONLY! All others may be prosecuted. - added a line to /var/lib/lrpkg/dropbear.conf /etc/dropbear.bannerEdit the login banner - and added a line to /var/lib/lrpkg/dropbear.list etc/dropbear.banner Thanks for LEAF! scott; canada --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] uClibc 2.2.0b4 RFE- Increased clarity re need for filename for dropbear banner
Via LRCFG one can edit the config file for dropbear, /etc/default/dropbear. There's a parm within, as follows: # optional banner to display before the user authenticates DB_BANNER= However whenever I make it non-blank (followed with svi dropbear restart) I cannot thereafter connect in via SSH. Oops, reading the error in /var/log/messages tells all: syslog; premature exit: Error opening banner file 'poop' So may I make an RFE: can line 7 of /etc/default/dropbear, which presently says: # optional banner to display before the user authenticates be changed to reflect the need for a filename, e.g.: # optional banner FILENAME to display before the user authenticates I had obviously thought that the banner entered would be just some raw text. Thanks for LEAF! scott; canada --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] uClibc 2.2.0_b4 - Caution using via-rhine - kern el BUG at slab.c:1130!/In interrupt handler - not syncing/Kernel pani c
Luis, thanks again for your feedback. In all honesty my time is too limited to go further into this and I think that I have a pretty good handle on my interrupts so freeing more is not, IMO, likely to solve it for me. Going to a different mobo/netcard is not appealing to me because of the time constraints and that I /love/ recycling old hardware into something useful (and I'm really, really cheap too :) The use of the /kernel/drivers/net via-rhine.o was the quickest, cheapest solution for me but maybe one day someone else will end up here and be able to test your ideas further. scott; canada Luis.F.Correia wrote: Hi! -Original Message- From: freeman groups [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 3:13 AM To: LEAF Subject: Re: [leaf-user] uClibc 2.2.0_b4 - Caution using via-rhine - kernel BUG at slab.c:1130!/In interrupt handler - not syncing/Kernel panic Luis, thanks for your thoughts. Luis.F.Correia wrote: Hi! Without any cable attached to the network cards, try to cat /proc/interrupts and check if there is any interrupt sharing... I didn't do that particular check but I know who was getting what interrupts and no-one was sharing. Beware, most boards have a quirk that makes the leftmost PCI slot to share the same int of the closest ISA slot, which means if you have a PCI right next to an ISA card, chances are that thay might get the same one... --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] uClibc 2.2.0b4 Bug? - tmp_size parameter within LEAF.CFG
(Really ... this is the last 'bug' that I'm aware of :)
In LEAF.CFG there are 3 memory size parms that can be adjusted:
syst_size
tmp_size (commented-out by default)
log_size
When I try to use the line:
tmp_size=3M
I get the following error message upon boot-up:
[...]
LINUXRC: Mounting a 6M TMPFS filesystem...
tmpfs: Bad mount option size
It happens upon execution of this line (158 in /linuxrc [aka
/var/lib/lrpkg/root.linuxrc]):
qt mount -t tmpfs tmpfs /tmp ${tmp_size:+-o size=$tmp_size}
I am guessing that the ${tmp_size:+ is a test for the existence of the
var tmp_size and that if it exists then the remainder (-o
size=$tmp_size) is appended. When I echo the command it shows what I
would expect and when I enter this echo'd command then I have a valid
mount made. However it just doesn't seem to want to work within the script.
I was able to make expected behaviour return by removing the space
between the -o and the size parm:
qt mount -t tmpfs tmpfs /tmp ${tmp_size:+-osize=$tmp_size}
(is this no-space-delimiter syntax officially valid?)
... or by performing the test a second time:
qt mount -t tmpfs tmpfs /tmp ${tmp_size:+-o} ${tmp_size:size=$tmp_size}
There's possibly (probably?) a more correct fix but I don't know what it
would be.
Thanks for LEAF!
scott; canada
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] uClibc 2.2.0b4 - Backup Bug? - excluded files cannot be included elsewhere
I have noticed that if a file is excluded by a package - say ROOT - (e.g. root.exclude.list containing the line var/lib/lrpkg/backdisk) then I can't have that file included within a different package - CONFIG - (e.g. having the line var/lib/lrpkg/backdisk within the file config.list). FWIW I ensured that I had a blank line at the end of the config.list file. This sort of doesn't make sense, does it? Just because the ROOT package doesn't want a given file included I should not have to worry about that impact on CONFIG's included files, if I have specifically indicated this file to be included in CONFIG? My understanding of the logic of file inclusion/exclusion is that any files that are included in other packages are effectively added to the exclusion list of all other packages, which makes some sense (or else a given file might end up being stored in 2 or more packages). But in addition to this exclusion logic it appears that excluded files from all packages are applied as exclusions to a given package ... which seems to me to be counter-intuitive. Might it make more sense for a given package's inclusion list to override all other packages' exclusion lists? Otherwise this requires the user to search out who else is excluding a given file, and to remove that entry, so that they can actually include it in a different package. I'll be honest and say that I can't entirely conceive how this would effect the overall packaging scheme and may well have unwelcome side-effects. The line that seems to be involved is line 87 in /usr/sbin/lrcfg.back.script: cat /var/lib/lrpkg/*.list /var/lib/lrpkg/*.links $TMP_EXCLUDE which would seem to cause a concatenation of all the other packages' included list files as well as their excluded list files. The workaround is simple, I guess: remove the conflicting line from the exclude list of the first package and place it into the include list of the destination package. One has to go grepping around to find the culprit though (once one has figured out what is happening, which is the time-consuming part). Still love LEAF though! (If computers were really, /really/ easy then I wouldn't have a job! ;) scott; canada --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] uClibc 2.2.0b4 - : not found error message at bootup - RESOLVED
Found this and figured it out so I thought that I'd share. This message comes up at bootup if one has CRLF's in one's LEAF.CFG file. I.E. instead of the more proper LF only, as used in the Linux world. You probably were editing your LEAF.CFG file in a DOS/Windows environment and saved it. Probably the easiest way to remove the CR's from the CRLF combination is the DOS2Unix utility. The best one of those that I have found is located here: http://gatekeeper.dec.com/pub/micro/pc/simtelnet/msdos/txtutl/dos2unix.zip The nice thing about this version is that it works under pure DOS, from 6.22 all the way up to XP. scott; canada --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] uClibc 2.2.0b4 - RFE: CR Handling in LEAF.CFG; was: : not found error message at bootup - RESOLVED
I had intended to make an RFE here, about the handling of CR within LEAF.CFG... As mentioned, LF alone are the proper way to end lines on a Linux system. Curiously the file isolinux.cfg (syslinux.cfg too?) doesn't seem to have a problem if there are CRLF in it. My RFE is that perhaps the parsing of LEAF.CFG can be made tolerant of the CR characters just as the parsing of isolinux.cfg is? =-=-=-=-=-=-=-=- In support of this RFE: it may reduce the stumbles that a new user (DOS/Windows) has, and that it may reduce some tech-support queries posted to this list. Against this RFE: it'll take someone's time to effect this, and that if not by mucking LEAF.CFG and discovering that CR's don't belong in the Linux world then a new user might well encounter this fact elsewhere, with some other file ... where it is perhaps less obvious and thus more confounding. In support of this RFE: it is somewhat likely that no files other then sys/isolinux.cfg and leaf.cfg would get edited in DOS since all other files are 'hidden' inside .LRP files and would normally be edited on the LEAF box itself. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Sorry, a correction: that specific error (: not found) appears only if: a) one has blank lines in LEAF.CFG and b) there are CFLF in this file. There are other symptoms of CRLF within LEAF.CFG: (FWIW I have a CD-ROM on hda [boot-device] and a h/d on hdb [unused] - possibly this impacts the reported 03:00 within the ... device 03:00 message?) - pivot_root: pivot_root: Device or resource busy - VFS: Can't find a Minix or Minix V2 filesystem on device 03:00. - FAT: bogus logical sector size 0 - VFS: Can't find a valid FAT filesystem on dev 03:00. - umount: /initrd: Invalid argument - freeramdisk: failed ioctl on /dev/ram0: Device or resource busy - LEAF Bering-uClibc V2.2.0 uClibc-0.9.20 (none) ttyS0 - (none) login: - where instead of the firewall name one gets this (none) - the packages get installed (LINUXRC: Installing - root: ...) but not loaded or run. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- As always, thanks for LEAF! scott; canada freeman groups wrote: Found this and figured it out so I thought that I'd share. This message comes up at bootup if one has CRLF's in one's LEAF.CFG file. I.E. instead of the more proper LF only, as used in the Linux world. You probably were editing your LEAF.CFG file in a DOS/Windows environment and saved it. Probably the easiest way to remove the CR's from the CRLF combination is the DOS2Unix utility. The best one of those that I have found is located here: http://gatekeeper.dec.com/pub/micro/pc/simtelnet/msdos/txtutl/dos2unix.zip The nice thing about this version is that it works under pure DOS, from 6.22 all the way up to XP. scott; canada --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] uClibc 2.2.0b4 - Backup Limitation (was: Bug?) - excluded files cannot be included elsewhere
Charles Steinkuehler wrote:
Excludes override includes of the same specificity (this is a feature
of tar). You can read up on tar (google for man/info pages), and find
more details about the packaging system in the SF FAQ's:
[... Doing some reading ... thank you again Charles ... bookmarking the
/index/ page of this set of doc'n for my future reference
{http://sourceforge.net/docman/?group_id=13751} ...]
Bummer about tar. However there are surely some things that could done
fairly easily to circumvent this if the functionality was desired. For
example:
- rename *.exclude.list files to be *.exclude.list_tmp
- rename BACKING_UP_PKG.exclude.list_tmp to be
BACKING_UP_PKG.exclude.list
- perform the: cat /var/lib/lrpkg/*.list /var/lib/lrpkg/*.links
$TMP_EXCLUDE
- rename *.exclude.list_tmp file to be *.exclude.list
- continue with the backing up process
In this way the exclude files that are not related to the BACKING_UP_PKG
are made to 'disappear' while the exclude list is created, then returned
to their original names. No more contamination by other packages'
exclude lists!
I'll leave it to the powers to be to consider if they think that this is
a worthwhile exercise.
FWIW this is characterized as:
[...] a fundamental limitation with the LRP packaging system
but to me seems simple to circumvent (in terms of ignoring the /exclude/
rules of other packages). I do admit that there may be
unintended/unforeseen consequences.
If the LEAF developers would be willing to implement this revised
exclusion-handler (if bustage wasn't onerous) I'd be willing to do a
simple regression test - backup all packages with current exclusion
handling, then do a backup with the new exclusion-handler and see if any
of the default 1.68-floppy-based files are any different. The only
assistance I would ask is if someone could draft the code that does the
renaming since:
mv *.exclude.list *.exclude.listed
doesn't do what I would expect (it doesn't work at all: e.g. mv: unable
to rename `dhcpcd.exclude.list': No such file or directory even though
dhcpcd.exclude.list is there) and I am not at all well-versed in shell
scripting.
U ... one afterthought that may obviate the whole idea, or make it
significantly more complex (beyond my skill/time limits) - the 'I 'X'
lines of a PACKAGE.local file?
Thanks again Charles, and all the LEAF developers!
scott; canada
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] uClibC 2.2.0b4 Bug - leaf.cfg media ordering acting reversed
Re:
Can you let us know where you found the conflicting documentation?
from 'PDF page #' 126, from file (that I re-downloaded today):
http://leaf.sourceforge.net/doc/guide/leaf-guide-collection.pdf
Loading partial backup from floppy disk after booting cdrom
Check syslinux.cfg on boot cd to see if PKGPATH includes partial
backup device the default is
PKGPATH=/dev/cdrom:iso9660,/dev/fd0:msdos
set the load order in lrpkg.cfg file on the floppy disk to load
CDROM version of the package then the floppy version of the partial
back of the package.
This :f ( the default ) will first load the cdrom version then the
floppy updates it they exist.
Use :R to load the floppy version a full package and totally avoid
the cdrom version of the package.
This section of the leaf-collection PDF is from the Bering User's Guide
and this particular text is to be found (original source?) at (Ch. 11):
http://leaf.sourceforge.net/doc/guide/bubooting.html
=-=-=-=-
Please forgive my questioning the way you have done things Charles: but
to me it seems a little 'inverted' to have the package-list 'read' from
right-to-left (where the default=:f[orward]). For we English-readers
'forward' would normally connote left-to-right, non?
As you said (snipped for clarity):
( loaded last) is *FIRST* and ... (loaded first) is listed last.
However please have no doubt how thankful I am for this partial-backup
functionality though! It's tres cool :)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re:
NOTE: Multiple package path entries is a little-used (especially prior
to the deprication of the boot= entry in the kernel command line)
Is there some other way to effect the cd-rom + (partial-backup) floppy
setup or is it that simply very few people go this route?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Thanks for LEAF, folks!
scott; canada
Charles Steinkuehler wrote:
freeman groups wrote:
I have a CD-ROM f/d partial-backup setup happening. I was finding
that no matter the changes made to a config file and saving it
('partially') to the floppy, when I rebooted I was met with the
'original' cd-rom-stored settings.
My relevant leaf.cfg lines:
PKGPATH=/dev/cdrom:iso9660,/dev/fd0u1440:msdos
snip
I was able to work around this by merely reversing the order of the
media on the PKGPATH line so no major hardship, but my observation
seem to be in conflict with the documented (expected) behaviour.
Might someone else be able to confirm that this is not happening to
'just me'? Alternatively I could do more testing if someone would
like to tell me a preferred setup - I have 2 f/d, a h/d and a cd-rom
on my test box so I can make an efficient (quick reboots) testbed.
Can you let us know where you found the conflicting documentation?
As the person who actually wrote the partial backup scripts in the
first place, the problem sounds like it's with the documentation. In
the PKGPATH list, the most authoritative source (ie: loaded last) is
*FIRST* in the PKGPATH list, with the least authoritative (ie:
loaded first and possibly overwritten) source is listed last, which
matches the behavior you're seeing (ie: by default PKGPATH entries are
read from right to left), and the documentation I provided:
http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/README.txt
quoute
package[:searchorder][,package[:searchorder]]
package is an LRP package file (without the .lrp extension)
searchorder controls the pakckage load behavior, and is one of:
f forward search, load multiple packages *DEFAULT*
F forward search, load first package found and stop
r reverse search, load multiple packages
R reverse search, load first package found and stop
A forward search starts with the PKGPATH entries (read right to
left) and looks at the boot= device last
A reverse search starts with the boot= device, and goes through
the PKGPATH entries (read left to right)
quote
Note that the boot= device is no longer used, so the floppy disk needs
to be added to the PKGPATH variable.
NOTE: Multiple package path entries is a little-used (especially prior
to the deprication of the boot= entry in the kernel command line) and
often mis-understood feature of the backup scripts, so I would not be
suprised to find some incorrect documentation floating around.
---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] uClibC 2.2.0b4 Bug - leaf.cfg media ordering acting reversed
I have a CD-ROM f/d partial-backup setup happening. I was finding that
no matter the changes made to a config file and saving it ('partially')
to the floppy, when I rebooted I was met with the 'original'
cd-rom-stored settings.
My relevant leaf.cfg lines:
PKGPATH=/dev/cdrom:iso9660,/dev/fd0u1440:msdos
and
LRP=root config etc local modules iptables dhcpcd keyboard
shor_wall ulogd dnsmasq dropbear weblet
(i.e. no use of overriding :f, :F, etc). My understanding is that the :f
parameter is the default action, meaning that the cd-rom-based package
would get loaded and then the floppy-based one (if it existed); left to
right reading of PKGPATH.
Here's an output from bootup with the LEAF.CFG settings as described:
=-=-=-=-
LINUXRC: Installing - root: /dev/fd0u1440 /dev/cdrom config:
/dev/fd0u1440 etc: /dev/fd0u1440 local: /dev/fd0u1440 modules:
/dev/fd0u1440 /dev/cdrom iptables: /dev/cdrom dhcpcd: /dev/cdrom
keyboard: /dev/cdrom shor_wall: shor_wall(nf!) ulogd: /dev/cdrom
dnsmasq: /dev/cdrom dropbear: /dev/fd0u1440 /dev/cdrom weblet:
/dev/cdrom - Finished.
LINUXRC: Loaded Packages
=-=-=-=-
which AFAICT means that the packages are getting loaded off the floppy,
then the cd-rom, e.g.:
root: /dev/fd0u1440 /dev/cdrom
I was able to work around this by merely reversing the order of the
media on the PKGPATH line so no major hardship, but my observation seem
to be in conflict with the documented (expected) behaviour.
Might someone else be able to confirm that this is not happening to
'just me'? Alternatively I could do more testing if someone would like
to tell me a preferred setup - I have 2 f/d, a h/d and a cd-rom on my
test box so I can make an efficient (quick reboots) testbed.
Thanks for LEAF!
scott; canada
---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] uClibc 2.2.0b4 bug? - partial backup of etc package ignoring /etc/ folder
I've been attempting to move to a cd-based setup and have been getting
into partial backups as a consequence. I've noticed some unexpected
behaviour (bugs?) and would like to bring my observations to the
attention of the Bering/uClibc team.
I began by wanting to do a partial backup of the etc package. However
the proposed partial-backup package created was very small (~ 350
bytes). I took a look at it's contents and it includes the stuff beneath
/var/lib/lrpkg but nothing from within /etc. Note that the etc.lrp has
no etc.local file so the default 'partial' handling takes place where
the package's files beneath /etc and /var/lib/lrpkg should be included.
The etc.list 'include file' for the etc.lrp package is simply:
etc
var/lib/lrpkg/etc.*
I then looked at the script - /usr/sbin/lrcfg.back.script and line 50
(the culprit, I believe) says:
sed -n -e \\:etc/:p -e \\:${LRPKG#/}:p $PKGLIST $INCLUDE
and AFAICT it's only keeping components from beneath
etc/
... which means that it doesn't affirm the line in etc.list that says
etc
since there's no trailing backslash (where this absence of a trailing
backslash is the proper syntax, AFAICT).
I 'fixed' the problem (to the limited extent of my understanding of
regexpr) by using:
sed -n -e \\:\^etc\$:p -e \\:etc/:p -e \\:${LRPKG#/}:p $PKGLIST
$INCLUDE
i.e. by adding the part:
-e \\:\^etc\$:p
which AFAICT means that a line that contains only 'etc' will meet the
criteria and thus a partial backup of etc.lrp will be complete.
I checked this out and it seems to work as I was expecting.
BTW maybe I can ask: should not all the sed matches on line 50 there
have the \^ criteria (match starting at the beginning of the line)
within, so that matches must be relative to the root directory, as
opposed to accepting any directory which includes etc/? AFAICT a
folder of /getc/somedir would (erroneously?) meet the criteria of
-e \\:etc/:p
? Then again I don't quite fathom the syntax of the sed commands on LEAF
as they seem to be somewhat different than the norm. Anyone have a good
link for understanding this sed's syntax that might help educate me?
As always, thanks for LEAF!
scott; canada
---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] uClibc 2.2.0_b4 - Caution using via-rhine - kernel BUG at slab.c:1130!/In interrupt handler - not syncing/Kernel panic
Luis, thanks for your thoughts. Luis.F.Correia wrote: Hi! Without any cable attached to the network cards, try to cat /proc/interrupts and check if there is any interrupt sharing... I didn't do that particular check but I know who was getting what interrupts and no-one was sharing. ... In all fairness though I should check specifically what you took the time to recommend, so here's the cat (after unplugging the cable which I forgot to do in my first retest)... [BTW, can I ask why you suggested I have no network cable plugged in - this shouldn't make a difference, right?] [EMAIL PROTECTED] /root # cat /proc/interrupts CPU0 0: 4547 XT-PIC timer 1: 2 XT-PIC keyboard 2: 0 XT-PIC cascade 4:650 XT-PIC serial 8: 0 XT-PIC rtc 10: 0 XT-PIC eth0 14:134 XT-PIC ide0 NMI: 0 ERR: 0 Yup, got the problem (error msg et al) again. Odd though, that COM2 isn't showing up with an IRQ... ??? ... It's active in BIOS and shows up in the boot-up messages. Maybe if you swap that card to another PCI slot, it would get a different interrupt and then stop behaving like that. For one test I had reserved the normally-assigned IRQ 10 for ISA (via BIOS), which forced the card to get IRQ 11, but the problem remained. As well in another test I recall moving this net card to the neighbouring slot and it still got IRQ 10 (i.e. mobo-based IRQ assignment algorithm). FWIW I had also removed all cards except the VGA and the D-Link and the problem persisted (and the VGA was, via a jumper on the card, told not to get an interrupt and indeed it was not ... but would when I changed the jumper setting ... I mention this only because my experience is that IRQ assignment for VGA cards is usually done via BIOS, but not the crappy Phoenix BIOS on my mobo ... instead it was done via the jumper on the VGA card itself - and via watching the POST screen I saw that the jumper on/off did what was expected in terms of assigning, or not, an interrupt). Did you disable the USB controller on the motherboard? You would gain an extra interrupt. Never enabled it at all, since I have no use for USB on the mobo. Here's my IRQ usage (all cards inserted): 3 - COM2 4 - COM1 5 - COM 3 (ISA modem, IRQ reserved for ISA in BIOS) 7 - LPT - mobo 9 - ETH0 (ISA, IRQ reserved for ISA in BIOS) 10 - ETH1 (PCI) 11 - ETH2 (PCI) 12 - available (since PS/2 mouse is disabled via mobo jumper) I do have a second LPT port (ISA card) in the machine but the jumper on it - IRQ5 or IRQ 7 or none (=unjumpered, and the /only/ officially recommended setting, per the doc'n for the card) seemed to have no effect from what I could tell in terms of running an old DOS util called IRQStat - also confirmed via checking /proc/interrupts with various jumper configs tested). The DMESG info from boot-up indicates that IRQ 7 is assigned for LPT1 but makes no mention of an IRQ for LPT2, though it recognizes both LPT's and does polling on both of them. I only have IRQ 7 assigned because the BIOS gives no choice of no-IRQ for the built-in LPT port. It (/net/via-rhine) not working sure confounded me, since I was pretty darned fastidious about my IRQ assignments, given how full my slots are. scott; canada Original Message- From: freeman groups [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 16, 2004 9:50 PM To: LEAF Subject: [leaf-user] uClibc 2.2.0_b4 - Caution using via-rhine - kernel BUG at slab.c:1130!/In interrupt handler - not syncing/Kernel panic My net card in question is a D-Link DFE-530TX Rev A1. I have been placing the modules into the modules package (/lib/modules folder) and backing up. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] uClibc 2.2.0_b4 - Caution using via-rhine - kernel BUG at slab.c:1130!/In interrupt handler - not syncing/Kernel panic
My net card in question is a D-Link DFE-530TX Rev A1. I have been
placing the modules into the modules package (/lib/modules folder) and
backing up.
From the file Bering-uClibc_2.2.0_modules_2.4.26.tar.gz I had pulled
the files:
/net/pci-scan.o (7412 bytes) and /net/via-rhine.o (16428 bytes).
so as to support this network card. After installing the files, backing
up then rebooting I would try pinging out on this card and would get the
following error (summarized):
kernel BUG at slab.c:1130!
invalid operand:
[...]
0Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
This would happen usually immediately but sometimes would take a few
'pings' before it would happen.
I was able to circumvent this issue by using the via-rhine.o driver from
/kernel/drives/net (and the required mii.o, of course) ... so keep in
mind using this alternate version of via-rhine if you have difficulties
with the one from the /net folder.
Further notes (re testing the /net/via-rhine.o version of the module):
- I set my BIOS to default settings
- I removed all cards except the video card and this D-Link card
- I had removed all other network drivers (not indicated in the
following 'output' but tested as well).
... but the problem wouldn't go away. I turned off power management,
etc, too.
I wonder if anyone has any thoughts on what happened to me? I was able
to work around it but curiosity still remains
Thanks for LEAF!
scott; canada
If anyone's further curious then here's the whole error 'message' (note
that 'pi' is just a script that does: ping 192.168.0.254):
[EMAIL PROTECTED] /root # pi
PING 192.168.0.2kernel BUG at slab.c:1130!
invalid operand:
CPU:0
EIP:0010:[c0179163]Not tainted
EFLAGS: 00010202
eax: 01f0 ebx: c105b5f0 ecx: 01f0 edx:
esi: c105b5f8 edi: c105b5f0 ebp: 01f0 esp: c1a27be4
ds: 0018 es: 0018 ss: 0018
Process ping (pid: 8818, stackpage=c1a27000)
Stack: c105b5f0 c105b5f8 0246 01f0 c2804020 c1dac800 c01794df
c105b5f0
01f0 c11d6000 c11d63c0 c1a27c44 c2850c74 0600
01f0
c1a27c8c c11d7170 c1dac800 c18e6f00 c1dac800
Call Trace:[c01794df] [c2850c74] [c01e3bd0] [c01ed70e]
[c01e3cbe]
[c01eb280] [c021515a] [c01e3bd0] [c02151a0] [c0214b6f]
[c01e86ca]
[c01e8d6d] [c01fabd3] [c01fab40] [c01eb280] [c01fab20]
[c01f96d7]
[c01fab40] [c01fab20] [c01fab2d] [c01eb280] [c01fa405]
[c01fab20]
[c02128eb] [c0212560] [c02198e9] [c01dd1d5] [c01ddfb0]
[c01603b0]
[c016ceb8] [c01de7eb] [c0157903]
Code: 0f 0b 6a 04 20 00 25 c0 c7 44 24 10 01 00 00 00 89 cd 81 e5
54 (192.168.0.250Kernel panic: Aiee, killing interrupt handler!
4): 56 data byteIn interrupt handler - not syncing
s
=-=-=-=-
This is my full boot-up output, including the error 'msg':
ISOLINUX 1.76 2002-08-27 Copyright (C) 1994-2002 H. Peter Anvin
Ü ÜÛÜ Ü
ÛÛÛ Bering-uClibc Firewall
Û ² Û (2.2.0b4 - June, 2004)
Û ² Û (uClibc 0.9.20
Bering-uClibc team)
Û ² Û Bering ÛÛÛ This image brought to you by:
Û ² Û
Û ² Û The LEAF project:
Û Û http://leaf.sourceforge.net
ÛÛÛ
Û ² Û The Shorewall project:
² ²Ûhttp://www.shorewall.net
²Û
ÛÛÛ ² Û
ÛÛ ² ÛÛ
ÛÛ
ßßÛßß
ß
Loading linux
Loading initrd.lrp.
Ready.
Linux version 2.4.26 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010315
(release)) #1 Sun Jun 6 11:44:34 CEST 2004
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000e - 0010 (reserved)
BIOS-e820: 0010 - 0200 (usable)
BIOS-e820: fec0 - fec01000 (reserved)
BIOS-e820: fee0 - fee01000 (reserved)
BIOS-e820: fffe - 0001 (reserved)
32MB LOWMEM available.
On node 0 totalpages: 8192
zone(0): 4096 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
DMI not present.
Kernel command line: console=ttyS0,57600 BOOT_IMAGE=linux
initrd=initrd.lrp init=/linuxrc rw root=/dev/ram0
LEAFCFG=/dev/fd0u1440:ms
dos
Initializing CPU#0
Detected 199.313 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 398.13 BogoMIPS
Memory: 30120k/32768k available (973k kernel code, 2260k reserved,
111k data, 64k init, 0k highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries:
