[leaf-devel] DNAT of pptp don't work on kernel 2.4.20
I have a bering v 1.1 floppy, and use it to implement a firewall gateway on an old Pentium 400 PC. The shorewall verson is 1.3.11a. There are 2 NIC on the PC. One for net One for loc. The gateway implement NAT for LAN to WAN traffic and do DNAT of PPTP for WAN to a PC on my LAN network. I used to connect from my MS XP PC in office to a MS XP PC in my home network via PPTP. Everything is OK. Recently, I try to build the bering floppy by my own. I build the kernel accoring to the steps described in the file : cvs: leaf/src/bering-uclibc/configs/kernel/2.4.20/kernel.txt and used the following kernel config file : cvs: leaf/src/bering-uclibc/configs/kernel/2.4.20/Bering-2.4.20.config Finally, the floppy is done. Everyting seems OK until I find the PPTP incoming (from WAN to LAN) traffic is fail. I capture the packet traces and find 1. pptp traffic is DNAT (port forward) correctly. 2. but the PPP LC Configuration Request (a GRE packet) can't be forwarded. I have added the following rules in /etc/shorewall/rules DNAT net loc:MS server address tcp 1723 DNAT net loc:MS server address 47 I guess I have lost some important kernel patches or have a incorrect kernel config. But all I have done is accoding to the kernel.txt file. if there is a bug in the patch file helpers-2.4.20.patch.gz ? Would anyone may kindly help me ? Thanks a lot ! --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] What I don't like about Bering uClibc
Hans Ulrich Niedermann wrote: snip 3. (lrcfg aka config) Every time I have modified a config file of package XYZ in lrcfg, I have to a) run /etc/init.d/XYZ restart from another shell b) make the changes permanent doing this: - go up two levels in the menu - enter the backup menu - read through the list to find XYZ' number (different from XYZ' number in the Packages configuration menu) NOTE: You can use the package name instead of the number. I haven't typed a package number in ages (they're too hard to locate when you've got a lot of packages loaded). - type b to back up - wait for some time - manually compare two numbers without given units, where one shows Bytes (new file size) and the other Kilobytes (free space) - if enough space is available, I have to manually confirm I'd like to have to menu entries in the package configuration: i) restart service ii) make changes permanent This should check for the amount of free space by itself. Both are good ideas. Checking for free space is harder than you'd think, especially at the limits (when the backup media is almost full), as you have to compare available space with file size taking into account sector sizes that might be different between the /tmp ramdisk and the backup media. The lack of du amd some other tools on earlier versions of LRP/LEAF when the backup scripts were written also contributes to the current behavior. 4. (lrcfg, buildtool, ???) Every time I have an updated package and install it, I have to manually save my config files and somehow merge them into the new package. Keeping the config, or having diff/edit, or even 3-way merge would be very nice. Try using partial backups, which backup just the configuration files. As long as you don't update to a new version with incompatable config files, you should be OK. I upgrade my systems by just inserting a new CD (with updated packages) and rebooting...the configuration data is all on a floppy (as partial backups) and is seamlessly used by the newly updated package(s) from the CD. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] What I don't like about Bering uClibc
Hans Ulrich Niedermann wrote: 2. (buildtool?) There is no build-hdd-image-for-my-board which copies all the necessary lrp files, sets up leaf.cfg with all the lrp names, possibly installs grub on the image, and so on. I'm surprised that LEAF to this day does not automate the process of reading in all of the *.lrp files. This was suggested many, many years ago and implemented in Oxygen. This way you don't have to list all of the LRP names. 3. (lrcfg aka config) Have you looked at acfg and apkg? They are shell scripts that are packaged as *.lrp and can be used instead of lrcfg. They use a menu interface using dialog and ncurses. I might add that apkg does check for space constraints (if desired) and will verify that there is enough space prior to saving the package. Charles mentioned that du was limited or unavailable previously; the Oxygen build of busybox is quite substantial compared to other systems, so this could be a problem - but you never know... --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Canonical source for 6wall and lrcfg source code?
Eric de Thouars [EMAIL PROTECTED] writes: Martin Hejl wrote: Hans Ulrich Niedermann wrote: where is the canonical place to get source code for 6wall and lrcfg from? Not sure about 6wall - but I would guess the latest lrp from CVS at http://cvs.sourceforge.net/viewcvs.py/leaf/bin/bering-uclibc/packages/ Yes, that's the place for 6wall Is there any reason against a) having 6wall in the buildtool b) having a source repository of the 6wall source files in CVS/SVN/Arch somewhere except that no one has bothered so far? :) IMHO, 6wall could use ulogd support, and this would be most easily ported from shorewall if the 6wall source files were available somewhere. Or do you want me to just send you patches, Eric? Gru, Uli pgp6Wh352wjvl.pgp Description: PGP signature
Re: [leaf-devel] Package for C++ libraries
Hans Ulrich Niedermann [EMAIL PROTECTED] writes: I have found neither libstdc++ nor libgcc_s in any standard package. Is that correct? It is correct, as I have just verified by building from CVS. Therefore, I present the attached patch to the root package to fix that. It creates a libcxx.lrp package containing libstdc++ and libgcc_s. Apply in src/bering-uclibc. Gru, Uli Index: root/buildtool.cfg === RCS file: /cvsroot/leaf/src/bering-uclibc/apps/root/buildtool.cfg,v retrieving revision 1.14 diff -u -3 -p -r1.14 buildtool.cfg --- root/buildtool.cfg 18 Oct 2004 20:00:42 - 1.14 +++ root/buildtool.cfg 21 Jan 2005 01:36:05 - @@ -502,5 +502,51 @@ /Contents /root + libcxx + Help EOF + libcxx - C++ runtime libraries + Requires: root.lrp + LEAF package + + This just contains the C++ runtime corresponding to the + root.lrp package. + EOF + + Permissions + Files = 644 + Directories = 755 + /Permissions + Owner + Files = root:root + Directories = root:root + /Owner + Contents + File +Filename = lib/libgcc_s.so.0.9.9 +Source = lib/libgcc_s.so.0.9.9 +Type = binary +Permissions = 755 + /File + File +# We use the wildcard to work around a bug +# around buildpacket.pl:752 +Filename = lib/ +Source = lib/libstdc*.so.5.0.5 +Type = binary +Permissions = 755 + /File + File +Filename = lib/libstdc++.so.5 +Target = lib/libstdc++.so.5.0.5 +Type = link +Permissions = 755 + /File + File +Filename = var/lib/lrpkg/libcxx.version +Target = var/lib/lrpkg/root.version +Type = link +Permissions = 755 + /File + /Contents + /libcxx /Package - pgpfp1VmUx42U.pgp Description: PGP signature
