I've managed to get things working, but I've still got a question or two.
Here's what i'm working with
> internet firewal/nat box client firewall client lan.
>pub pub/10.30.1.110.30.1.20/10.20.21.1 10.20.21.x
>From Right to Left, each machine's default GW is
On Mon, Mar 12, 2001 at 11:14:10PM -0800, Alfred Perlstein wrote:
> * David Xu <[EMAIL PROTECTED]> [010312 21:39] wrote:
> > Hello Julian,
> >
> > Tuesday, March 13, 2001, 12:18:49 AM, you wrote:
> >
> > JE> Jonathan Lemon wrote:
> > >>
> > >> On Mon, Mar 12, 2001 at 02:12:56PM +0800, David Xu
Murray Taylor wrote:
>
> This lng email will hopefully allow the netgraph - network gurus to
> A: answer my remaining questions
> and
> B: grab this and make a tutorial 'worked example' (unless it is total blech
> of course)
>
> So to those who have already earned their stripes from one look
Alfred Perlstein wrote:
>
> >
> > sigh, does it mean FreeBSD get behind in some TCP/IP features?
> > I know Linux and OpenBSD support SACK, and possible NetBSD.
>
> We're terribly sorry we haven't been able to commit the code
> you sent in, can you please point out the PR you submitted to
> addr
Hi
Please see my comments below.
> > I am using FreeBSD 4.1. I followed Roger's suggestion about "autosrc 0"
> > message. But "autosrc" message is not available in ng_ether.
> > I have tried commenting
> > bcopy((IFP2AC(priv->ifp))->ac_enaddr, eh->ether_shost,
> > 6);
> > in ng_ether_rcv_lower i
I've got a problem with secondary DNS servers not being able to get
updates from my primary through it's firewall.
The firewall rules on the primary dns server (pertaining to dns) look like
this. I thought I had my bases covered...
# Allow DNS traffic from internet to query your DNS (for
On Tue, 13 Mar 2001, Peter Brezny wrote:
> I've got a problem with secondary DNS servers not being able to get
> updates from my primary through it's firewall.
>
> The firewall rules on the primary dns server (pertaining to dns) look
> like this. I thought I had my bases covered...
>
>
> #
Hi,
I'm looking for open-sourced Mobile IP implementation
on FreeBSD. Could anyone please give me some
information?
Many thanks,
Guangrui
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
To
We are computer hardware specialists. We work within the retail sector as well as
import/export.
Please let us know if you can supply the following:-
QUANTITYDESCRIPTION
100+COMPAQ SERVERS FINAL PRICE PLEASE
1000+ 128 MB PC100 SDRAM
Garrett Wollman <[EMAIL PROTECTED]> wrote:
>
>I think the common-sense interpretation when one speaks of the
>``maximum length'' of some string is that it is the maximum value
>strlen() might return, and doesn't include metainformation.
However it slightly uglifies idiomatic coding of things like
Hi,
I'm wondering if anyone has ever considered modifying the UDP behavior with
regard to selecting:
Currently, writing to a UDP socket either enqueues packets in the interface
queue (returning success), or drops them on the floor (returning ENOBUFS)
if the queue is full. Selecting-to-write on a
> Hi,
>
> I'm wondering if anyone has ever considered modifying the UDP behavior with
> regard to selecting:
>
> Currently, writing to a UDP socket either enqueues packets in the interface
> queue (returning success), or drops them on the floor (returning ENOBUFS)
> if the queue is full. Selecti
< said:
> I'm considering changing this, so that a select-to-write on a UDP socket
> will block until queue space becomes available.
Impossible. The only way to find out whether a packet (or set of
packets, or a fragment of a packet) would be successfully enqueued is
to try it. Even then there
On Tue, Mar 13, 2001 at 03:47:08PM -0600, Nick Rogness wrote:
> > # Allow DNS traffic from internet to query your DNS (for reverse
> > # lookups etc).
> > $fwcmd add allow tcp from any 53 to $ns1 53 setup
> > $fwcmd add allow udp from any to $ns1 53
> > $fwcmd
> Hi,
>
> I'm wondering if anyone has ever considered modifying the UDP behavior with
> regard to selecting:
>
> Currently, writing to a UDP socket either enqueues packets in the interface
> queue (returning success), or drops them on the floor (returning ENOBUFS)
> if the queue is full. Selecti
Peter,
> My question is, why didn't routed or something figure this out on its own?
What? These are just computers, remember? Computers have a nasty habit of
doing what we tell them to do, not what we want them to do!
;-)
Seriously though, You do need to tell the firewall/nat box about the
1
16 matches
Mail list logo