Re: ipfw not allowing udp?

At Thu, 25 Jan 2001, [EMAIL PROTECTED] wrote: >I have a line in my firewall config like this: > >ipfw add allow udp from any 53 to my.ns.ip.here 53 > >and was dissappointed to find that when i configured a secondary name server >to use the primary behind the firewall, it was unable to make the zo

Re: What for messages?

On Fri, 26 Jan 2001, Bill Vermillion wrote: > On Fri, Jan 26, 2001 at 11:26:17AM +0500, -Digger thus spoke: > > hi all, > > > what for messages and what daemon or process can make it? > > > > file /var/log/messages: > > > > ---cut--- > > host /kernel: Connection attempt to TCP 127.0.0.1:199 fr

Re: What for messages?

On Fri, Jan 26, 2001 at 11:26:17AM +0500, -Digger thus spoke: > hi all, > what for messages and what daemon or process can make it? > > file /var/log/messages: > > ---cut--- > host /kernel: Connection attempt to TCP 127.0.0.1:199 from 127.0.0.1035 > host /kernel: Connection attempt to TCP 127.0

What for messages?

hi all, what for messages and what daemon or process can make it? file /var/log/messages: ---cut--- host /kernel: Connection attempt to TCP 127.0.0.1:199 from 127.0.0.1035 host /kernel: Connection attempt to TCP 127.0.0.1:199 from 127.0.0.1036 host /kernel: Connection attempt to TCP 127.0.0.1:1

Re: ipfw not allowing udp?

On Thu, 25 Jan 2001, Peter Brezny wrote: > I have a line in my firewall config like this: > > ipfw add allow udp from any 53 to my.ns.ip.here 53 > > and was dissappointed to find that when i configured a secondary name server > to use the primary behind the firewall, it was unable to make the z

Re: ipfw not allowing udp?

On Thu, 25 Jan 2001, Peter Brezny wrote: > have i missed something big and zone transfers require more than just port > 53? Zone transfers (and any DNS transaction that requires packet sizes larger than 512 bytes) use TCP port 53. ~Dan D. -- ++ Unix is the worst operating system, except for all

Re: ipfw not allowing udp?

> I have a line in my firewall config like this: > > ipfw add allow udp from any 53 to my.ns.ip.here 53 > > and was dissappointed to find that when i configured a secondary name server > to use the primary behind the firewall, it was unable to make the zone > transfers... > > have i missed some

ipfw not allowing udp?

I have a line in my firewall config like this: ipfw add allow udp from any 53 to my.ns.ip.here 53 and was dissappointed to find that when i configured a secondary name server to use the primary behind the firewall, it was unable to make the zone transfers... have i missed something big and zone

Re: I have delayed ACK problems

On Thu, 25 Jan 2001, Garrett Wollman wrote: > < >said: > > The important part was the > if (callout_pending(tp->tt_delack)) { > ... > tp->t_flags |= TF_ACKNOW; > } > > bit. This causes us to ack immediately where previously we would just > delay an alread

sf driver problem?

Has anyone had any luck in figuring out why the Adaptec ANA four-port Ethernet cards dramatically slow down the machine when all four ports are in use? http://www.freebsd.org/cgi/query-pr.cgi?pr=22624 (nevermind the video interrupt conflict theory, that doesn't seem to have anything to do wi

Re: I have delayed ACK problems

< said: > Whatever happened to TF_DELACK anyway? It was removed since it is no longer necessary. The same information can be gleaned from callout_pending(tp->tt_delack). > SW5kZXg6IHRjcF9pbnB1dC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09 > PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp

Re: I have delayed ACK problems

< said: > I'm not sure this is required. Expanding the context of the area in > question: The important part was the if (callout_pending(tp->tt_delack)) { ... tp->t_flags |= TF_ACKNOW; } bit. This causes us to ack immediately where previously we

Re: I have delayed ACK problems

On Thu, 25 Jan 2001, Garrett Wollman wrote: > < said: > > > could you test this patch and compare the results. > > By generating an ACK for every segment with the TH_PSH flag set > > I found a significant increase in throughput. > > I don't think this is right. I don't think it is either -- tryi

Re: I have delayed ACK problems

In article [EMAIL PROTECTED]> you write: >< said: > >> could you test this patch and compare the results. >> By generating an ACK for every segment with the TH_PSH flag set >> I found a significant increase in throughput. > >I don't think this is right. > >I think what we want to do is: > >

Re: sysctl: unknown oid 'net.link.ether.bridge'

did you have "options BRIDGE" in your kernel config ? cheers luigi > Hi > trying to setup bridging on a 4.2-RELEASE box > I get this error message ... > > sysctl -w net.link.ether.bridge=1 > sysctl: unknown oid 'net.link.ether.bridge' > > > I've rebuild the kernel with followi

Re: I have delayed ACK problems

< said: > could you test this patch and compare the results. > By generating an ACK for every segment with the TH_PSH flag set > I found a significant increase in throughput. I don't think this is right. I think what we want to do is: if (callout_pending(tp->tt_delack)) {

sysctl: unknown oid 'net.link.ether.bridge'

Hi trying to setup bridging on a 4.2-RELEASE box I get this error message ... sysctl -w net.link.ether.bridge=1 sysctl: unknown oid 'net.link.ether.bridge' I've rebuild the kernel with following the http://www.freebsd.org/handbook/bridging.html instructions ... Any help welcome TIA -- Frank Bo

Re: Pseudo ethernet interface

On Thu, 25 Jan 2001, Satyajeet Seth wrote: > Hi, > > Is it possible to provide pseudo ethernet interfaces? > Can we associate an IP and MAC address with a psuedo ethernet interface > to facilitate data packet transmission & reception through that? > If so, how does it work? > Pointers to

Re: problems compiling raw socket program

On Thu, 25 Jan 2001, John wrote: > Hi > > I tried that as you had advised, but the error remains > the same. Rearrange your includes like this: #include #include #include #include #include #include #include #include #include #include #include #include and it'll compile, but the lin

Pseudo ethernet interface

Hi, Is it possible to provide pseudo ethernet interfaces? Can we associate an IP and MAC address with a psuedo ethernet interface to facilitate data packet transmission & reception through that? If so, how does it work? Pointers to any documentation in this regard will be appreciated. Th

Re: problems compiling raw socket program

Hi I tried that as you had advised, but the error remains the same. bash-2.03$ gcc -o rawsocket rawsocket.c In file included from rawsocket.c:7: /usr/include/netinet/ip.h:152: parse error before `n_long' /usr/include/netinet/ip.h:152: warning: no semicolon at end of struct or union /usr/include

Re: problems compiling raw socket program

> Can anyone enlighten me on why I can't compile? It tells you some types are missing so you need to add one or more headers. This will probably do it: #include Wilbert To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message

Re: I have delayed ACK problems

Bruce, could you test this patch and compare the results. By generating an ACK for every segment with the TH_PSH flag set I found a significant increase in throughput. Index: tcp_input.c === RCS file: /home/ncvs/src/sys/netinet/tcp_i

problems compiling raw socket program

Hi Can anyone enlighten me on why I can't compile? I use gcc -o rawsocket rawsocket.c and I get: bash-2.03$ gcc -o rawsocket rawsocket.c In file included from rawsocket.c:7: /usr/include/netinet/ip.h:152: parse error before `n_long' /usr/include/netinet/ip.h:152: warning: no semicolon at end