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
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 to be
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
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 FreeBSD
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 undefined
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:
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:
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,
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
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 hoomanfaza...@gmail.com wrote:
On 10/31/2014 5:30 PM, Mark Felder
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 datagrams on
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
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).
lots of
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).
lots of startup logs for pid 22646
Oct 15 08:46:59 snort[22646]: Initializing daemon mode
Oct 15 08:46:59
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.
log:
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:
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
On Oct 31, 2014 12:12 PM, John-Mark Gurney j...@funkthat.com 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
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
On Oct 31, 2014, at 11:23 PM, Chris Inacio nacho...@gmail.com 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
20 matches
Mail list logo