On Oct 31, 2014, at 20:23, Chris Inacio wrote:
>
> Hello all,
>
> I've tried to find this information in so many ways, but I just can't piece
> it together, maybe my Google fu is failing me.
>
> I have my router/gateway device running FreeBSD 10p11 - so its up to date.
> On my internal network
On Fri, 31 Oct 2014 18:28:28 -0700, Freddie Cash wrote:
> On Oct 31, 2014 12:12 PM, "John-Mark Gurney" wrote:
> >
> > Can any one think of a good reason not to enable IPDIVERT sockets in
> > the ipfw module?
Yes, two. Nowadays people are just as or perhaps more likely to use
in-kernel NAT,
> On Oct 31, 2014, at 11:43 PM, Tom Pusateri wrote:
>
>>
>> On Oct 31, 2014, at 11:23 PM, Chris Inacio wrote:
>>
>> My configs are really basic. dhcp6c.conf:
>>
>> interface re0 {
>>
>> send ia-pd 0;
>>
>> send ia-na 1;
>>
>> };
>>
>>
>> id-assoc na 1 {
>>
>> };
>>
>>
>>
> On Oct 31, 2014, at 11:23 PM, Chris Inacio wrote:
>
> Hello all,
>
> I've tried to find this information in so many ways, but I just can't piece
> it together, maybe my Google fu is failing me.
>
> I have my router/gateway device running FreeBSD 10p11 - so its up to date.
> On my internal ne
Hello all,
I've tried to find this information in so many ways, but I just can't piece
it together, maybe my Google fu is failing me.
I have my router/gateway device running FreeBSD 10p11 - so its up to date.
On my internal network interface, re1, I'm using dnsmasq to serve both IPv4
DHCP and cur
On Oct 31, 2014 12:12 PM, "John-Mark Gurney" wrote:
>
> Can any one think of a good reason not to enable IPDIVERT sockets in
> the ipfw module?
>
> And possibly enabling default to accept? That way you don't have to
> go to the console when you load the ipfw module because you forgot to
> auto a
John-Mark Gurney wrote this message on Fri, Oct 31, 2014 at 12:12 -0700:
> Can any one think of a good reason not to enable IPDIVERT sockets in
> the ipfw module?
sorry, ignore this... didn't realize ipdivert was loadable as a
separate module, ipdivert...
--
John-Mark Gurney
Can any one think of a good reason not to enable IPDIVERT sockets in
the ipfw module?
And possibly enabling default to accept? That way you don't have to
go to the console when you load the ipfw module because you forgot to
auto add the accept all rule? :)
something like:
//depot/projects/
el...@sentor.se wrote:
>
> No one have any thoughts about this?
>
> Its happening sporadically on several FreeBSD 10 machines of mine,
> while
> all of the FreeBSD 9-machines work just fine.
>
> If the problem isn't fixed, people won't be able to upgrade to and
> run
> snort on FreeBSD 10.
>
>
On Wed, Oct 15, 2014 at 11:41:33AM +0200, el...@sentor.se wrote:
>
> Hi!
>
> Today the problem reoccurred.
> I've now debugged the problem a little furter.
>
> I'm starting snort (as root).
>
> <<>>
> Oct 15 08:46:59 snort[22646]: Initializing daemon mode
> Oct 15 08:46:59 snort[22648]: Daemon
No one have any thoughts about this?
Its happening sporadically on several FreeBSD 10 machines of mine, while
all of the FreeBSD 9-machines work just fine.
If the problem isn't fixed, people won't be able to upgrade to and run
snort on FreeBSD 10.
log:
I'm starting snort (as root).
<<>>
Oct
For documentation:
I do not know why or how, but after trying to reproduce the same strange
behaviour, it did not happen. This was after restarting all the test
environment.
Weird.
Sorry for take your time with this strange mess.
Regards,
Raimundo Santos
On 29 October 2014 14:30, Raimundo Sant
On Fri, 31 Oct 2014 18:30:00 +0330, Hooman Fazaeli wrote:
> On 10/31/2014 5:30 PM, Mark Felder wrote:
> > I'm not sure if this is what you're looking for, but perhaps the
> > solution is in net/samplicator ?
> >
> > From the project's website:
> >
> > This simple program listens for UDP d
Hi,
If it's missing in 10 or later then please file a bug and I'll see
what it'll take to add another socket option to return the original
destination address+port.
Thanks,
-adrian
On 31 October 2014 08:00, Hooman Fazaeli wrote:
> On 10/31/2014 5:30 PM, Mark Felder wrote:
>>
>> I'm not sure i
On 10/31/2014 5:30 PM, Mark Felder wrote:
I'm not sure if this is what you're looking for, but perhaps the
solution is in net/samplicator ?
From the project's website:
This simple program listens for UDP datagrams on a network port, and
sends copies of these datagrams on to a set of destinatio
I'm not sure if this is what you're looking for, but perhaps the
solution is in net/samplicator ?
>From the project's website:
This simple program listens for UDP datagrams on a network port, and
sends copies of these datagrams on to a set of destinations. Optionally,
it can perform sampling, i.
El día Friday, October 31, 2014 a las 03:34:07PM +0330, Hooman Fazaeli escribió:
> > udp_input() doesn't overwrite destination address. Probably you have NAT
> > that does this.
> >
> There is no NAT stuff.
> I checked that on 8.4 source:
> http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c?v=
On 10/31/2014 3:38 PM, Andrey V. Elsukov wrote:
On 31.10.2014 15:04, Hooman Fazaeli wrote:
Hi,
udp_input() doesn't overwrite destination address. Probably you have NAT
that does this.
There is no NAT stuff.
I checked that on 8.4 source:
http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c?v=
Hi,
On 30/10/14 20:39, K. Macy wrote:
>> I also suspect there are further problems with buf_ring. A full wrap
>> around of the atomically swapped value is possible. I.e. the code thinks
>> it just atomically updated a head/tail index when in fact a full wrap
>> around occurred leading to undefi
On 31.10.2014 15:04, Hooman Fazaeli wrote:
>> Hi,
>>
>> udp_input() doesn't overwrite destination address. Probably you have NAT
>> that does this.
>>
> There is no NAT stuff.
> I checked that on 8.4 source:
> http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c?v=FREEBSD8#L461
The more recent Fr
On 10/31/2014 2:18 PM, Andrey V. Elsukov wrote:
On 31.10.2014 12:50, Hooman Fazaeli wrote:
Hi,
I my setup, I use a fwd rule to forward all udp traffic to my local proxy:
ipfw add 10 fwd localhost,7000 udp from any to any recv em1
The proxy needs to know the original destination address of for
On 31.10.2014 12:50, Hooman Fazaeli wrote:
> Hi,
>
> I my setup, I use a fwd rule to forward all udp traffic to my local proxy:
>
> ipfw add 10 fwd localhost,7000 udp from any to any recv em1
>
> The proxy needs to know the original destination address of forwarded
> datagrams, but
> there seems
Hi,
I my setup, I use a fwd rule to forward all udp traffic to my local proxy:
ipfw add 10 fwd localhost,7000 udp from any to any recv em1
The proxy needs to know the original destination address of forwarded
datagrams, but
there seems to be no way to obtain that address.
Using recvmsg with I
23 matches
Mail list logo
