Re: IPSEC Tunnel
> Is it not possible to have the internal ip addresses of the tunnel > machines talk with other internal addresses on the other side of the tunnel? > Example Set Up: > Packets from say 192.168.0.2 to 192.168.1.1 and back > (192.168.0.0/24 Lan)-(192.168.0.1 Internal)->(200.0.0.1 > Interface)===IPSEC TUNNEL===(200.0.0.2 Inteface)<-(192.168.1.1 > Internal)-(192.168.0.1/24 Lan) > > I can see the packets from 192.168.0.2->192.168.1.1 under tcpdump of > 200.0.0.2 as a (ipip) Packet from 200.0.0.1->200.0.0.2 having > 192.168.0.2->192.168.1.1 listed but the packet just seems to disappear > after that. It does not show up under lo0 or the internal interface. because the network behind the gateway 200.0.0.2 is 192.168.0.1/24 as you descirbed. any packet to 192.168.1.1 can not be routed by 200.0.0.2. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mbuf external buffer reference counters
On Fri, 12 Jul 2002, Bosko Milekic wrote: > On Fri, Jul 12, 2002 at 04:26:53AM -0700, Jon Mini wrote: > > I'm probably speaking out of turn here (I have no idea what structure > > you all are talking about), but a monodirectional ring can be safely > > modified with a compare-and-exchange atomic operation. > > The jist of the problem is that when you want to say, remove yourself > from the list, you have to: > > 1) your "next"'s back pointer to your "back" pointer > 2) your "Prev"'s next pointer to your "next" pointer > > So that's two operations but for all you know your "next" or your > "back" may be doing the same thing to you at the same time. As far as > I know, you can't (intuitively) figure out a way to do both of these > atomically. i.e., maybe you'll set your next's back pointer to whatever > you have in `back' but then your `back' guy will set your back pointer > to whatever he has in `back' and then your next guy's back pointer will > be invalid, for example. You threw out a logic problem The following came to mind, though I've not quite been able to fully think through all possibilities, yet (C psuedo-code, because I am not up-to-date on my assembly. Comments assume a list A<->B<->C<-^, B being deleted): r1=prev; // If prev!=r1, A was deleted during the race. prev=0 iff prev==r1; // atomic test-and-set. r2=next; // If next!=r2, C was deleted during the race. next=0 iff next==r2; // If r2->prev!=self, then the C is in delete. r2->prev=r1 iff r2->prev==self; // At this point, if C attempted a delete, the delete code would // notice that C->prev->next != C (it is still B). // If r1->next!=self, then the A is in delete. r1->next=r2 iff r1->next==self; Storing the 0's locks against deletes from the neighbors. The failure cases for the first three exchanges (X=Y iff X==Z) are pretty straightforward, and I think can be safely unwound. The fourth failure case is interesting, though, because I _think_ that if you correctly code the failure cases, you can try to run 'r1->next=r2 iff r1->next==0;' to salvage it. It's possible that there's a way of coding things which would always allow one of two conflicting threads to proceed, so that spinning on failure is sensible. I can't quite see it, though. I have no idea what the performance implications of this are. AFAICT, you would require 3 locks to accomplish this correctly (self, next, prev *), which implies 6 total exchanges. Also, I haven't considered the insert case, though I'm not sure why it wouldn't simply invert the ordering of the delete. (*) Hmm. I thought you could do two (Lock self, lock next, prev->next=next, next->prev=prev, unlock next, delete self), but then realized that there was a race between finding next and applying the lock. So you need all three. Later, scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: increasing throughput
On Tue, 2 Jul 2002, Brian wrote: > On Tue, July 2, 2002, "Scott Hess" <[EMAIL PROTECTED]> wrote: > > I'm very interested in this type of product (meaning "Really small box > > that's essentially a complete PC, without having to build an > > enclosure"). Here's a unit which I'm looking at (but, unfortunately, > > have yet to receive info on): > > > > http://www.advantech.com/products/Model_Detail.asp?model_id=1-8089T&bu= > > > > In case that doesn't work, select Network Computing/Network Appliances > > from the products popup, then Firewall Platforms. > > Now that is pretty slick. If you find out how much it costs let us all > know. Finally got info back: $500 FWA-200 (barebones box) $ 64 Celeron 566 $ 36 128MB SODIMM $ 54 64MB Compact Flash Card $ 35 Wiring kit (not certain what this means, since there isn't anything to wire) $ 80 Installation, test, burn-in $769 Ouch! That's about $300 above where I'm willing to consider it. Maybe you could save $60 buying the commodity components yourself, and another $80 by doing your own burn-in, but since most of the money is in the box, that doesn't get you far... they did say that orders of 10 or more can get a 5% discount. [I can throw out a recommendation for the company, though. A number of years back I bought a POS system from them for use as a router. it was pretty small for the time, while still allowing me to stuff in a standard hard drive and two or three standard PCI or ISA cards. It's long since bit the dust, though, I'm sure some would say _because_ I used a standard hard drive and the like :-).] Later, scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: increasing throughput
Scott Hess wrote: > Finally got info back: > > $500 FWA-200 (barebones box) > $ 64 Celeron 566 > $ 36 128MB SODIMM > $ 54 64MB Compact Flash Card > $ 35 Wiring kit (not certain what this means, since there isn't anything > to wire) > $ 80 Installation, test, burn-in > > $769 Ouch! > > That's about $300 above where I'm willing to consider it. Soren's boxes (http://www.soekris.com/) are half that price and work great for our purposes. (Although the current models are also a bit less powerful than the one above.) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
