natd bug with pptp, hack fix, question
With natd+ipfw, I was setting up a front-end firewall for
a client. The firewall has several real IP addresses
(we'll call them 10.0.0.1 and 10.0.0.2) and two
MS PPTP servers behind it.
10.0.0.1
10.0.0.2
World- | firewall | - PPTP-1 192.168.1.1
\ PPTP-2 192.168.1.2
I setup the natd.conf file in the way one would expect:
redirect_proto gre 192.168.1.1 10.0.0.1
redirect_port tcp 192.168.1.1:1723 10.0.0.1:1723
redirect_proto gre 192.168.1.2 10.0.0.2
redirect_port tcp 192.168.1.2:1723 10.0.0.2:1723
[With or without the redirect_proto gre; with the
-current libalias, I would expect to perhaps not need it]
Anyway, to make a long story short, it doesn't work. The
first PPTP server is reachable and happy, but the virtual
PPTP server on 10.0.0.2 is unreachable. When natd sees
the first GRE packet, it calls
FindPptpIn(), which then checks:
link = FindLinkIn(dst_addr, alias_addr,
NO_DEST_PORT, call_id,
LINK_PPTP, 1);
This check fails, and it falls back to a call to
FindOriginalAddress(alias_addr);
Two questions:
a) I'm not sure about the location of the call to
AddLink for for this connection in the PPTP aliasing
code, so I couldn't determine the right way to set
things up.
b) Shouldn't this also check to see if there's a default
GRE relay host for this alias address?
One issue:
I hacked my client's natd program in the interim to
AddLink inside FindPptpIn if it doesn't get a returned
link, and it works like a charm. However, it's definitely
the wrong thing to do and only a temporary solution.
The fact that it works, however, suggests that this
should be something relatively straightforward for someone
with a clue about how libalias works to fix.
Anyone? I'm happy to fix it (though my client might
not like that. :-), but I'd love a bit of a hint about
the right way to address this within the libalias framework
before I blunder through making changes that won't be
accepted.
Thanks!
This is using the 4-stable natd and the libalias from -current.
-Dave
{I'm not on -hackers at the moment, so if you could CC: me on
a response, I'd appreciate it}.
--
work: [EMAIL PROTECTED] me: [EMAIL PROTECTED]
MIT Laboratory for Computer Science http://www.angio.net/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: putting FreeBSD in an extended partition
I am wondering whether there is a good reason for not putting FreeBSD in a DOS extended partition. >>> >>> Good luck booting it. >> >> Do you mean as long as I can boot it, the kernel itself has no problem >> with being putting into a DOS extended partition? > > Loader(8) can't grok it and the kernel can't mount it as root. Actually, that's not entirely true. The problem with booting is that you cannot mark an extended partition entry as 'active' (without some nasty, nonstandard hacks). If that were possible, it would be trivial to improve the loader to deal with that case. The kernel most certainly can mount an extended partition as root, however. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: putting FreeBSD in an extended partition
On Tue, 26 Sep 2000, Zhiui Zhang wrote: > On Mon, 25 Sep 2000, Doug White wrote: > > > On Sat, 23 Sep 2000, Zhiui Zhang wrote: > > > > > > > > I am wondering whether there is a good reason for not putting FreeBSD in a > > > DOS extended partition. > > > > Good luck booting it. > > Do you mean as long as I can boot it, the kernel itself has no problem > with being putting into a DOS extended partition? Loader(8) can't grok it and the kernel can't mount it as root. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
subscribe
= jay roughan network super-hero __ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What's the difference between the ncr0 and sym0 drivers?
On Mon, 25 Sep 2000, Joe McGuckin wrote: > Is one preferable? Here's the history: BSD ncr -> Linux ncr53c8xx -> Linux sym53c8xx -> FreeBSD sym The ncr is minimally maintained mainly against O/S changes since the latest real improvement that has been the support of 875/895/896 Ultra chips: - Ultra, Ultra 2 - On-chip RAM These changes came from the Linux ncr53c8xx driver, as I am using both Linux and FreeBSD since 1995. Note that Linux ncr53c8xx is now also minimally maintained. Only `sym53c8xx' and `sym' support phase mismatch handling from SCRIPTS, Ultra3 chips (SYM53C1010), residual calculation, completion queue (rather than walking CCB lists), etc ... (would be too long :) ). Speaking about Linux + FreeBSD + FreeEtc..., my main project at the moment is `sym' for all. Btw, this is not an original strategy. :-) It seems that a new driver is developped from scratch in the NetBSD project. That's a courageous effort. Just the `from scratch' approach has been a bad idea, in my opinion. About the `sym' driver, I try to maintain it up-to-date regarding both O/S features and chips features. It seems extremally stable in practice and is both very fast and scale perfectly with the number of simulatenous IOs, at least in theory :). Just a number: I have measured a bit more that 16000 small IOs per second (512 bytes READs) using a single old SYM53C895 chip, which let me think that theory should match practice here. :) Gérard. PS: LSILogic supports actively sym53c8xx and sym drivers development by providing me with controllers, documentations and hardware upgrades. > Thanks, > > Joe > > > > -- > > Joe McGuckin > > ViaNet Communications > 994 San Antonio Road > Palo Alto, CA 94303 > > Phone: 650-969-2203 > Cell: 650-207-0372 > Fax: 650-969-2124 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Alpha testers wanted; SHELLINIT/DIRLIST
This is a request for alpha testers for SHELLINIT/DIRLIST. SHELLINIT is a shell initialization package intended for use with any shell; DIRLIST is a component of SHELLINIT which implements directory lists. Brief explanations are included below. All inputs are welcome, but for this initial alpha release hackers experienced with one or more shells will most likely be able to cope (which is why I'm asking in this list). In the interest of brevity, you can delete now if you are not interested. If you aren't sure, the descriptions below may help. The preface and introductions to the documentation (http://androcles.com/dist/shellinit/using/) are slightly more forthcoming. The documentation is "complete" but very much a draft. It is included in the distribution tarfile (in postscript and HTML) and is also available separately at the address below. The alpha distribution may be downloaded at http://androcles.com/dist/shellinit/ Description of SHELLINIT: === Shellinit is a framework for convenient and extensive customization of your *nix shell and working environment. It supports most common Bourne-style shells which offer function and alias support. Some support is available for csh/tcsh, but this is less well-developed due to the lack of function support in those shells (and the fact that the author has not used those shells for several years). The distribution includes 'basic' initialization files which define the framework and are intended to remain static, and a set of 'private' initialization files which may be customized by each user. The framework provides a means to initialize shell functions, aliases, variables and options, and a simple interface for 'maintaining' or modifying them. It is normally used in conjunction with the DIRLIST function set, although this is not required. The basic framework, once established, allows a user to conveniently: + edit basic or private shell initialization files + define and select shell prompts + establish tty parameters + monitor the current state of the shell (options) + replace the shell with a different shell + manipulate X terminals (size, location, color, etc.) when a shell is found to be running in one. + maintain directory lists (if DIRLIST is installed) The installed framework will _replace_ and enhance your existing shell initialization files (although you may easily include your existing intiializations through the framework). The framework does not attempt, however, to establish or mandate a specific user environment (aside from the framework itself); its primary purpose is in fact to provide a simple, consistent means for users to establish a private, custom working environment. === Description of DIRLIST: Directory Lists differ from stacks (e.g. as maintained by csh's pushd/popd) in the following ways: 1. paths are maintained in a fixed order and position in the list, and can thus be referenced by number. 2. entries are unique; a pathname is not added to the list if it is already in the list. 3. multiple, named lists may be maintained. 4. lists may be maintained across logins. 5. directories in the list may be named as shell positional parameters (e.g. cp thisfile $4) 6. lists may be read-only and shared Lists are maintained interactively as shell variables. A simple program, "dirlist" is used via shell functions or aliases to manipulate the lists. The 'cd' command is (by default) aliased to 'dl_chdir' so that any directory change will maintain the current list. You may unalias 'cd', if you like, and alias 'dl_chdir' to something else, using a simple editor interface to the dirlist initialization files. Lists are maintained across logins in files named by the list name. When a list is selected, the list is read from the file into a shell variable. Changes to the list occur as changes to the variable (not the file). By default, interactive changes to a list are saved to the storage file only on command. An 'autosave' directive will turn on automatic saving of all changes to the list (provided that the list is not read-only). Commands are also provided to delete entries from the list, and to edit the list interactively. Of course, there are commands to create lists, and to select the list to use. Lists may be shared, but (ordinarily) updated only by the list owner (interactive changes may be made, but may not be saved, although they may be written to a private list). An alternate "system" list set may be created, which will be read-only to all users. The current distribution supports directory lists in all of the common Bourne-style functions shells (using shell functions). A degenerate form of directory lists is suppported for 'csh' and 'tcsh'
Announcement: Two new FreeBSD-related mailing-lists
Apologies in advance for the cross-posting. (Hopefully you have a
mail system with duplicate suppression.)
I've created two new FreeBSD-related mailing-lists which people may
wish to subscribe to. FreeBSD's postmaster did not think there would
be sufficient interest in these lists to justify their creation on
FreeBSD.org, so they will instead live on my machine. (This means
that there will be no public archives of the discussion, unless
someone else volunteers to create one.)
The two lists are <[EMAIL PROTECTED]> and
<[EMAIL PROTECTED]>; subscribe in the usual manner.
Here are the info files for both lists:
The freebsd-print mailing-list is intended for the discussion of
print systems and software in the FreeBSD environment. Germane
topics would include:
- The standard FreeBSD print spooler system, lpr(1)/lpd(8).
- Other print spooler systems, such as `rlpr' and `LPRng'.
- Related document-management and translation software such as
`a2ps', `psutils', and `ghostscript'.
- Document-formatting systems such as groff(1) and TeX.
- Standards relevant to printing, such as IPP.
- Support for foreign printing protocols in FreeBSD using
tools like `CAP' and `samba'.
This list is maintained and retroactively moderated by Garrett
Wollman, wollman@{{FreeBSD,bostonradio,decalcomania}.org,lcs.mit.edu}
The purpose of the freebsd-standards list is to discuss the impact of
various formal and informal standards on the FreeBSD operating
system. Discussion will include the new POSIX 1003.1-200x / Single
UNIX Specification v3 standards (currently in process), as well as
other existing and future standards. This mailing-list specifically
excludes discussion of standards for network protocol and APIs; these
should take place exclusively on the <[EMAIL PROTECTED]> list
instead.
This list is maintained and retroactively moderated by Garrett
Wollman, wollman@{{FreeBSD,bostonradio,decalcomania}.org,lcs.mit.edu}
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: What's the difference between the ncr0 and sym0 drivers?
On Mon, Sep 25, 2000 at 07:16:55PM -0700, Joe McGuckin wrote: > > Is one preferable? sym. Gerard did an excellent job in this driver. Sym is the most activily maintained driver as well. ncr always worked fine for me as well, don't misunderstand, but the future belongs to sym ;-) -- Wilko Bulte [EMAIL PROTECTED] Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
AW: Frustration with SCSI system
> -Ursprungliche Nachricht- > Von: Keith Kemp [mailto:[EMAIL PROTECTED]] > Gesendet: Freitag, 22. September 2000 00:29 > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Betreff: RE: Frustration with SCSI system > > > On the topic of Vinum, what do you guys do about the / > partion since it > appears that a vinum partion can not be the boot partion. We have a system here with two SCSI disks using vinum RAID1 to mirror them. To ensure that we can boot the system even of a / failure on the first disk. There is copy of the root partition on the second disk, so we can boot the system even if the first hd fails completely. As we don't want to copy the contents of the / partition on the first disk to the second disk on every change we do on it, we also mirror /etc. So there is nothing left on the root partition which changes regulary. Mirroring the /etc partition is a bit tricky, because you need some files at startup. On a 3.3-Stable system the only files you really need until /etc is remounted as a mirrored drive are: defaults/rc.conf rc.conf fstab gettytab login.conf rc ttys This shouldn't have changed until know. As you also want to be able to change these files when you remounted /etc I have hardlinks to these files in an /ETC directory. On the remounted /etc directory softlinks then point to the files in /ETC. In my opinion this is the smartest solution you get with vinum. You only have to copy the contents of the / partition of the first disk to the second disk if you change any of the files listed above or if you install a new kernel/new release of FreeBSD. Sorry for my bad english. Alexander Maret To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: diskless workstation
[..] Sorry, can please anyone explain to me how the setup for etherboot is ? Have I to boot the kernel or the loader ? I have botting an kernel now but it asks nicely for the rootdevice; I've setup dhcpd like explained before in this thread. TIA Holm -- FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development Systemhaus für Daten- und Netzwerktechnik phone +49 3731 781279 Unternehmensgruppe Liebscher & Partnerfax +49 3731 781377 D-09599 Freiberg * Am St. Niclas Schacht 13http://www.freibergnet.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SIGCHLD and sigwait
all -
I am attempting to use sigwait to wait for SIGCHLD from
children of my process
The following does not work (assumint that testchild just
sleeps and then exits)
I never get the signal.
on solaris 2.7 to make this work, i have to call
signal( SIGCHLD, sigHndlr ).
The sigHndlr never gets called cause the sigprocmask
blocks it
What am I doing wrong?
thanks
jack
-- begin testparent.c
#include
#include
#include
#include
#include
#include
int main( int argc, char ** argv )
{
sigset_t newmask, oldmask;
int signo;
sigemptyset( &newmask );
if( sigaddset( &newmask, SIGCHLD ) )
perror( "sigaddset" );
if( sigprocmask( SIG_BLOCK, &newmask, NULL ) )
perror( "pthread_sigmask() error" );
char * argp[1];
argp[0] = NULL;
pid_t pid = fork( );
if( pid == 0 ) {
if( execv("./testchild", argp ) ) {
perror( "execv" );
}
}
cout << "before sigwait" << endl;
if( sigwait( &newmask, &signo ) )
perror( "sigwait error" );
if( signo == SIGCHLD )
cout << "testparent SIGCHLD" << endl;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: putting FreeBSD in an extended partition
I guess what Doug meant was (at least as far as I've seen in other postings) the current FreeBSD boot loader does not support booting from extended partitions. G'luck, Peter -- This sentence was in the past tense. On Tue, Sep 26, 2000 at 11:25:35AM -0400, Zhiui Zhang wrote: > On Mon, 25 Sep 2000, Doug White wrote: > > > On Sat, 23 Sep 2000, Zhiui Zhang wrote: > > > > > > > > I am wondering whether there is a good reason for not putting FreeBSD in a > > > DOS extended partition. > > > > Good luck booting it. > > Do you mean as long as I can boot it, the kernel itself has no problem > with being putting into a DOS extended partition? First of all, it seems > to me that there is no way to put FreeBSD in an extended partition without > modifying /stand/sysintall. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: putting FreeBSD in an extended partition
On Mon, 25 Sep 2000, Doug White wrote: > On Sat, 23 Sep 2000, Zhiui Zhang wrote: > > > > > I am wondering whether there is a good reason for not putting FreeBSD in a > > DOS extended partition. > > Good luck booting it. Do you mean as long as I can boot it, the kernel itself has no problem with being putting into a DOS extended partition? First of all, it seems to me that there is no way to put FreeBSD in an extended partition without modifying /stand/sysintall. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: virtual console 'snapshot'?
Hi, In article <[EMAIL PROTECTED]> you wrote: > Is there anything like Linux's /dev/vcs* in FreeBSD? That is, some way > to obtain the complete view of a virtual console - characters, attributes, > everything? I've written a module which implements something like this - for every console, there's a device where you can read that console's content or scrollback buffer (selectable per #define). It's still very crude, though. For example the output routine may need work. (Right now it renders similar to man(1), i.e. "more /dev/ttyvbuf0" shows kernel messages in bold.) Also, it doesn't take a "snapshot" which means that reading a buffer while there's output on that console may give a garbled view. You can find it here: http://www.uni-karlsruhe.de/~un1i/freebsd/misc/ttyvbuf.tgz I've written this on FreeBSD-current but I think it'll also work on 4.x. Maybe it is of some use to you. Bye, Philipp -- http://www.uni-karlsruhe.de/~un1i/ (,.) \\\00 ) \= ) cc_|\_,^ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
