On Sat, 8 May 2004, Eugene Grosbein wrote:
Hi,
> When an active IPv4 TCP connection between
> localIP:localport and remoteIP1:remoteport1 exists,
> it is not possible for local non-root user to create outgoing
> TCP connection from localIP:localport to remoteIP2:remoteport2.
>
> Why? It prevents
Hi!
When an active IPv4 TCP connection between
localIP:localport and remoteIP1:remoteport1 exists,
it is not possible for local non-root user to create outgoing
TCP connection from localIP:localport to remoteIP2:remoteport2.
Why? It prevents http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/65928
fr
John Baldwin wrote:
On Thursday 06 May 2004 04:47 pm, Scott Long wrote:
Søren Schmidt wrote:
Petri Helenius wrote:
I´m highly confident that this is a case of integrated "CSA" ethernet
with broken BIOS. I suspect you get an message about that when booting.
Nope. no messages to that effect, oh an
On Thursday 06 May 2004 04:47 pm, Scott Long wrote:
> Søren Schmidt wrote:
> > Petri Helenius wrote:
> >> I´m highly confident that this is a case of integrated "CSA" ethernet
> >> with broken BIOS. I suspect you get an message about that when booting.
> >
> > Nope. no messages to that effect, oh a
Hello,
I've already put this question in freebsd-questions, without any
response.
I have the following configuration:
#!/bin/sh
ipfw -f flush
ipfw add check-state
ipfw add allow all from me to any
ipfw add allow all from any to any via lo0
ipfw add deny all from 10.0.0.0/8 to any in via tun0
ip
Gleb Smirnoff wrote:
On Fri, May 07, 2004 at 04:31:08PM +0400, Dmitry Morozovsky wrote:
D> GS> FreeBSD has support for FR with help of nodes ng_frame_relay and ng_lmi. This
D> GS> support is hardware independent. And it works perfectly with cronyx adapters.
D> GS> What is a reason for merging hard
On Fri, 7 May 2004, Gleb Smirnoff wrote:
GS> From the point of FreeBSD cronyx driver appeared 1 month ago, and was not
GS> supported before.
This is simply not true; yes, driver in the tree has been obsolete from 3.x
era and mostly non-workable; however, cronyx hardware _is_ supported by
FreeBS
On Fri, May 07, 2004 at 05:07:53AM +0400, Maxim Konovalov wrote:
> I hope you are not going to turn off ip fragmentation/reassembling by
> default to make SO happy, aren't you?
I know you are being sarcastic, but: that wouldn't make the SO happy.
Cheers,
--
Jacques Vidrine / [EMAIL PROTECTED] / [
On Fri, May 07, 2004 at 09:51:00AM +0200, Martin Stiemerling wrote:
> Anyway, setting the default to reject packets is IMHO not
> a good idea,
After a night's sleep, I also agree. Emitting ICMP messages is
probably a bad, bad default.
Cheers,
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PRO
On Fri, May 07, 2004 at 04:31:08PM +0400, Dmitry Morozovsky wrote:
D> GS> FreeBSD has support for FR with help of nodes ng_frame_relay and ng_lmi. This
D> GS> support is hardware independent. And it works perfectly with cronyx adapters.
D> GS> What is a reason for merging hardware specific support
On Fri, 7 May 2004, Gleb Smirnoff wrote:
GS> D> we're using Cronyx adapters, some of them in FremaRelay mode, which has been
GS> D> supported by cronyx-made drivers available from vendor site for most of FreeBSD
GS> D> versions. FR support involves modifications to sppp kernel routines.
GS> D>
GS>
On Fri, May 07, 2004 at 04:08:52PM +0400, Dmitry Morozovsky wrote:
D> we're using Cronyx adapters, some of them in FremaRelay mode, which has been
D> supported by cronyx-made drivers available from vendor site for most of FreeBSD
D> versions. FR support involves modifications to sppp kernel routine
Dear colleagues,
we're using Cronyx adapters, some of them in FremaRelay mode, which has been
supported by cronyx-made drivers available from vendor site for most of FreeBSD
versions. FR support involves modifications to sppp kernel routines.
Main driver maintainer is now FreeBSD committer (rik@)
Julian Elischer <[EMAIL PROTECTED]> wrote:
>
>I use RR all the time.
>it allows you to record the reverse path, (up to the size limitation).
When I worked at an ISP that used BSD routers everywhere on which I had
root, I wrote an evil little script for that purpose...
http://dotat.at/prog/scripts
Andre Oppermann wrote:
> Julian Elischer wrote:
> > I use RR all the time.
> > it allows you to record the reverse path, (up to the size limitation).
>
> Which won't get you far these days... ;-)
I use it occasionally, on our highly asymmetric site. The length
restriction is not a problem there :
Julian Elischer <[EMAIL PROTECTED]> writes:
> [I suspect that the above may have failed.. doing
> 'ngctl list', 'ngctl show ath0:orphans' and 'ngctl show .:'
> would be constructive..]
This is with pppoed running:
jmmr# ngctl list
There are 5 total nodes:
Name: ngctl949Type: socket
Hi,
I vote for choice "Ignore IP options and pass packets unmodified." since
this is fail safe for the node receiving the packet and does not break end
to end traffic. Anyway, setting the default to reject packets is IMHO not
a good idea, since packets are probably dropped by your router somew
On Fri, May 07, 2004 at 11:39:06AM +0400, Andrew Riabtsev wrote:
A> JWW> Why the [ng_ether_rcvdata] won't check if packets should travel to
A> JWW> the [bdg_forward] when they are bridged packets?
A>
A> This is how it should work, you get entrance to low level network
A> (lower hook) and upper le
Hi Jian-Wei,
Thursday, May 6, 2004, 6:46:16 PM, you wrote:
JWW> Hi, I spent times to figure out the packet flow with ng_ether, like this:
JWW> upper layer
JWW> |
JWW> ^
JWW> [ether_demux]
JWW> ^
JW
19 matches
Mail list logo
