Stuart Henderson writes: > interesting; if my understanding of this and the RFC that the referenced > 'touch' draft was published as (rfc3884), at one end you can configure one > side in *transport* mode carrying ipip encapsulated packets - gif(4) with > net.inet.ipip.allow=1, afaict - and the other side in tunnel mode as usual. That's the idea, though the IKE daemon on the transport+IPIP side has to actually offer tunnel mode or the other end will typically reject the negotiation. > ...

interesting; if my understanding of this and the RFC that the referenced 'touch' draft was published as (rfc3884), at one end you can configure one side in *transport* mode carrying ipip encapsulated packets - gif(4) with net.inet.ipip.allow=1, afaict - and the other side in tunnel mode as usual. this could be useful for either running routing protocols over IPsec, or for redistributing IPsec "routes" into an IGP (the latter being something I've been wondering about how to handle in some way ...

This link would probably help ;) http://www.isi.edu/div7/presentation_files/dynamic_routing.pdf

Your situation is different from mine, I am new to OSPF, and my information may not help you any, but here it is: I have a set up with two external routers and two internal routers. Both external routers uplink to the same ISP unlike in your situation. They share a carp'd external/inet IP and the status of this carp interface (and other path/interface failures determines which external router is used as the main uplink. My main problem setting this up is somewhat similar to yours in terms of ...

I don't know if I'd go so far as to call it an entire migration. Nor a "linux shop". There are also freebsd, solaris, windoze <gasp>, and mac In this particular case we're just talking about one server for one portion of the website. It originally ran on solaris in the late 90s. It was moved to linux around '98 and the last major "upgrade" was 2001/2. This is a decentralized collaborative non-hierarchal group of volunteers around the world using whatever resources are at hand using ...

best guess right now is that it'll be fixed by a 4.1 upgrade based on this 4.0 -> 4.1 change: "Revert PAE pmap for now, stops freezes commonly seen on amd64 machines running in i386 mode."

No idea, can anything interesting be found in /var/log/*? --

I think this is different, because it's reporting "Connection Refused" Have you enabled pf on the machine running ntpd? From your configuration and logs it does seem that ntpd is configured and running correctly. Best guess is that you have "block return" for that port, or as the default. The easiest test would be to temporarily disable pf (pfctl -d) and try your telnet test again. If that works then it's your pf rules... -- Darrin Chandler | Phoenix BSD User Group | ...

Hi all, I was just trying to setup an ntpd server for my home network so it could sync with each other. So here's what I have in my /etc/ntpd.conf: # $OpenBSD: ntpd.conf,v 1.7 2004/07/20 17:38:35 henning Exp $ # sample ntpd configuration file, see ntpd.conf(5) # Addresses to listen on (ntpd does not listen by default) listen on 192.168.1.1 # sync to a single server #server ntp.example.org # use a random selection of 8 public stratum 2 servers # see ...

His problem was not about ntpd not syncing. At any rate, Reza, do you have any firewalls that could be blocking the port? If you switch "listen on 192.168.1.1" to "listen on *" does that change your situation?

Hi All, I have more than one interface I need to monitor with snort. I've read http://www.snort.org/docs/faq/1Q05/node35.html, To do that, I've created bridge0 and added both interfaces. Since I need to assign IP addresses to each interface, I could not just up the interfaces and add them to the bridge. Perhaps that's the reason, but I don't see alarms triggered with -i bridge0 (snort warns that no IP is assigned to bridge0 anyways). Do I need to do anything else? Using 0.0.0.0 or any as ...

What you are describing is almost certainly the i386-on-amd64 problem. Solution is to do one of the following (in my order of preference, your criteria may be different than mine, of course!) : * run OpenBSD/amd64 (where this problem doesn't exist) * wait for 4.1 (where it is fixed) * run -current (where it is fixed) "fixed" is probably not quite the right word, several people suspect the PAE support was PROVOKING a real problem elsewhere, but backing out the PAE support seems to ...

Yes, it is. Any server offering OpenBSD via CVSup should include xenocara. If a particular server doesn't, poke the admin. They probably forgot to add the collection. -- Christian "naddy" Weisgerber naddy@mips.inka.de