Ah! Yep, that boot option exist in 10.1 as well. :-)
Now I have two approaches to test.
Thanks!
/Elof
On Wed, 9 Mar 2016, Jan Bramkamp wrote:
On 09/03/16 15:26, el...@sentor.se wrote:
Regarding the FIBs:
In FreeBSD 10.1 RELEASE, no extra FIBs can be added since that kernel is
compiled
Intrersting!
Unfortunetly I can't test right now. Will let you know.
If I understand correctly, the 'ipfw fwd approach' don't use any FIBs, so
it should be applicable to the *outgoing* traffic.
Regarding the FIBs:
In FreeBSD 10.1 RELEASE, no extra FIBs can be added since that kernel is
On Wed, 9 Mar 2016, Jan Bramkamp wrote:
On 09/03/16 11:29, el...@sentor.se wrote:
I've been searching the internet but can't find any good
documentation/examples on how to setup source routing in my FreeBSD.
What I want to do:
Let internet clients connect their OpenVPN to a FreeBSD box. The
Hi all!
I've been searching the internet but can't find any good
documentation/examples on how to setup source routing in my FreeBSD.
What I want to do:
Let internet clients connect their OpenVPN to a FreeBSD box. The client's
internet traffic should be routed to a separate firewall
On Tue, 1 Dec 2015, Mark Felder wrote:
On Tue, Dec 1, 2015, at 09:53, el...@sentor.se wrote:
On Tue, 1 Dec 2015, Matthew Seaman wrote:
On 2015/12/01 15:05, Mark Felder wrote:
Notice how almost all of them are port 123 on both sides, but a few of
them are not. Why? The RFC says that NTP
On Tue, 1 Dec 2015, Mark Felder wrote:
On Tue, Dec 1, 2015, at 10:50, el...@sentor.se wrote:
Not that this helps this thread to move on, but just to clarify:
In this case, the NAT that would introduce the randomized src port would
be *your* NAT, not a NAT at pool.ntp.org.
Deny UDP
On Tue, 1 Dec 2015, Matthew Seaman wrote:
On 2015/12/01 15:05, Mark Felder wrote:
Notice how almost all of them are port 123 on both sides, but a few of
them are not. Why? The RFC says that NTP is supposed to be using port
123 as both the source and destination port, but I clearly have
On Tue, 1 Dec 2015, Mark Felder wrote:
On Tue, Dec 1, 2015, at 02:02, wishmaster wrote:
Hi, Mark.
I'm hoping someone can explain what happened here and this isn't a bug,
but if it is a bug I'll gladly open a PR.
I noticed in my ipfw logs that I was getting a log of "DENY" entries for
an
No one has a theory?
/Elof
On Thu, 5 Nov 2015, el...@sentor.se wrote:
Hi all!
Why don't ngrep work on ix interfaces?
It shows nice values if I sniff on other interfaces, e.g. igb0 and
bridge0:
# ngrep -d igb0 "q" ip
I see some matching packets. Everything looks good.
# netstat -B
Pid
Hi Christian.
So... Any news regarding this?
Should I create a bugzilla so the ball don't get dropped?
/Elof
On Fri, 6 Nov 2015, Christian Peron wrote:
It needs to get fixed.. let me generate a patch for you and you can test it.
On Nov 5, 2015, at 8:51 AM, el...@sentor.se wrote:
On
Hi Christian.
Sorry, I was in a bit of a hurry when I wrote the below.
Here's more information:
FreeBSD 10.1 amd64 (on both boxes).
In rc.conf on the receiver I have:
ifconfig_ix0="up -arp -lro"
ifconfig_ix1="up -arp -lro"
cloned_interfaces="bridge0"
ifconfig_bridge0="up addm ix0 -discover
Hi all!
Why don't ngrep work on ix interfaces?
It shows nice values if I sniff on other interfaces, e.g. igb0 and
bridge0:
# ngrep -d igb0 "q" ip
I see some matching packets. Everything looks good.
# netstat -B
Pid Netif Flags Recv Drop Match Sblen Hblen Command
1800
Hi!
Question:
What do the Recv column in 'netstat -B' show?
I thought it was tha amount of packets received, but appaently not so.
I send 200 packets from a tcpreplay machine to a receiving machine.
I do it a few times.
On the receiver I see:
netstat -in
NameMtu Network Address
Isn't this a bug?
# sysctl net.bpf.maxbufsize=30
net.bpf.maxbufsize: 524288 -> -1294967296
No error message and exit status is 0.
Shouldn't net.bpf.maxbufsize be unsigned?
I would like sysctl to have a crude sanity control and return an error if
you set a positive value but the
It sounds like a promisc bug in the driver, just as you say, but just to
test it some more:
I see that you are running both in PPROMISC and PROMISC.
What happen if you remove the PPROMISC and only let tcpdump set it's own
PROMISC?
Running in monitor mode is the correct way to sniff
Hi!
q1)
I assume that libpcap has builtin support for checking if sysctl
net.bpf.zerocopy_enable is set to 1, and if so uses zerocopy.
Correct?
q2)
This should mean that all normal sniffing tools like tcpdump, tshark,
ngrep, argus, etc do NOT need any specific options in order to use
(Late response)
I don't have an IBM-server, but isn't it equipped with a dedicated
ILO/IPMI NIC?
If so, the solution is rather to use that dedicated NIC instead of letting
ILO/IPMI reuse the NIC for the OS.
/Elof
On Mon, 24 Nov 2014, Alexey V. Panfilov wrote:
21.11.2014 13:57, Alexey V.
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
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 snort[22648]: Daemon initialized, signaled parent pid:
22646
Oct 15
I guess this is a bug report for FreeBSD 10.0.
Sometimes I can't kill my snort process on FreeBSD 10.0.
It won't die, even with kill -9.
I'm not talking about a zombie process. Snort is a process that should
die normally.
I've run snort on over 100 nodes since FreeBSD v6.x and I've never
The following reply was made to PR kern/139268; it has been noted by GNATS.
From: el...@sentor.se
To: bug-follo...@freebsd.org, p...@cns.utoronto.ca
Cc:
Subject: Re: kern/139268: [if_bridge] [patch] allow if_bridge to forward just
VLAN-tagged (or untagged) packets
Date: Wed, 23 Feb 2011
Back in FreeBSD 6.3 and 6.4 there was a bpf-bug in if_bridge.c.
This bug was sometimes a nice feature though, since it normalised the
traffic sent to bpf, making it easier to sniff, analyse and debug the
mirrored traffic.
My request is for the possibility to have packet normalisation turned
The following reply was made to PR kern/154443; it has been noted by GNATS.
From: el...@sentor.se
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/154443: [bridge] Kernel module bridgestp.ko missing after
upgrade (if_bridge.ko depend on it)
Date: Fri, 4 Feb 2011 15:03:00 +0100 (CET)
Update
23 matches
Mail list logo
