Re: Source routing howto

[elof2]

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 without support for it. :-(
I'm hesitant to break binary compability (I use freebsd-update).

Will release 10.3 or 11.0 have "options ROUTETABLES=2" in their GENERIC
kernel conf? Anyone knows?


I don't remember how FreeBSD 10.1 did it, but in FreeBSD 10.2 the number of 
routing tables (e.g. net.fibs=2) is a boottime loader tunable and can be 
changed in /boot/loader.conf without rebuilding the kernel. Moving from 10.1 
to 10.2 is a painless way to gain this feature if it isn't available in 10.1 
already.

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Source routing howto

[elof2]

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 
compiled without support for it. :-(

I'm hesitant to break binary compability (I use freebsd-update).

Will release 10.3 or 11.0 have "options ROUTETABLES=2" in their GENERIC 
kernel conf? Anyone knows?


/Elof


On Wed, 9 Mar 2016, Vladimir Terziev wrote:


Hi,

would this rule to the trick for what you need ?

ipfw add fwd Routed_B_IP ip from 10.10.10.0/24 to not 10.0.0.0/8


Regards,

Vladimir


On Mar 9, 2016, at 3:40 PM, 
wrote:



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
client's internet traffic should be routed to a separate firewall
dedicated for all client networks (VPN and physical), where all clients
then leave the network.
The FreeBSD box has its own normal default gateway to speak with the
internet.
This route is needed in order to be able to keep the OpenVPN-traffic
flowing.
How do I source route the tunneled traffic, coming from e.g. 10.10.10.x
to the "client firewall"?
Are there any good examples out there?
Do I have to compile a custom kernel?
(the responses back from that firewall use a normal static route,
pointing 10.10.10.0/24 to the FreeBSD box)


Do I understand you correctly that you have a FreeBSD box acting as

* OpenVPN endpoint
* router
* and firewall


The FreeBSD box is an OpenVPN server.
Naturally it is also a router (forwarding enabled).
It has local firewall rules (using pf), but when I talk about a firewall I mean 
a separate box (Juniper/Checkpoint/something).


all in one system and you want use the OpenVPN tunnel as default route for your 
*other* hosts?


Heh, my description was pretty bad.

New try:
100 clients around the world connect to an OpenVPN server called "SRV".
SRV has a default route, so incoming and outgoing VPN packets use internet 
connection A (router A).

So far everything is as normal it can be. A server, a default route and an 
internet connection.

Next, all the vpn clients' traffic is sucked into their VPN tunnels (no split 
tunneling allowed).
The clients can reach internal servers. Good.
But when the clients surf the web, their traffic originates from SRV, using its 
default route towards the internet.

This works but is no longer what I want.

I now want the client traffic, aimed for the internet, to be routed elsewhere. In my 
case, "elsewhere" is a firewall with its own internet connection (B). The 
firewall is equipped with extra functions/blades to inspect client traffic and have all 
the rules for client traffic.

So basically I want the remote VPN users' surf traffic to pass through firewall 
B.

(
In my example, the VPN clients will get IPs in the 10.10.10.0/24 range.

Firewall B only need to route 10.10.10.0/24 to SRV in order to forward the 
response surf traffic back to the VPN clients.
)


So on SRV I need:
* traffic from SRV itself (openvpn responses, freebsd-update, mail, dns and 
other stuff) to 'any' should be routed to router A. Currently my default route.
* traffic with src net 10.10.10.0/24 to 'any' should be routed to B.

So two destinations for 'any'. Hence the need for source routing.

PS: traffic with src net 10.10.10.0/24 to internal nets, like 10.20.30.0/24, 
should still be routed normally and not be thrown onto router B.

Hope that description is better.



In that case what you need is some kind of *policy* based routing.
One way to go about it with more than one FIB (aka kernel routing table). The 
problem is that you have to decide on the routing table to use before 
performing the route lookup. For packets forwarded through your FreeBSD router 
you have to select a non default FIB during input filtering e.g.
  # simple case
  ipfw add setfib 1 all from any to any in via $lan_if
  # complex case for multiple interfaces
  # ipfw table  add  
  ipfw table 1 add $lan_if1 1
  ipfw table 1 add $lan_if2 2
  ipfw table 1 add $lan_if3 2
  ipfw table 1 add $lan_if3 2
  # ...
  # lookup routing table number in a table
  ipfw add setfib tablearg all from any to any via table(1)
For traffic generated by your FreeBSD router you can't use the firewall to set 
the routing table because locally generated traffic only passes through output 
filtering by which time the routing decision has already happend. Instead you 
can set a processes default routing table with the setfib(1) utility or use a 
setsockopt(2) with SO_SETFIB for each socket. Jails can also set default 
routing table for sockets created inside the jail.


Heh. Do you mind giving another example now with the 

Re: Source routing howto

[elof2]

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
client's internet traffic should be routed to a separate firewall
dedicated for all client networks (VPN and physical), where all clients
then leave the network.

The FreeBSD box has its own normal default gateway to speak with the
internet.
This route is needed in order to be able to keep the OpenVPN-traffic
flowing.

How do I source route the tunneled traffic, coming from e.g. 10.10.10.x
to the "client firewall"?

Are there any good examples out there?
Do I have to compile a custom kernel?

(the responses back from that firewall use a normal static route,
pointing 10.10.10.0/24 to the FreeBSD box)


Do I understand you correctly that you have a FreeBSD box acting as

* OpenVPN endpoint
* router
* and firewall


The FreeBSD box is an OpenVPN server.
Naturally it is also a router (forwarding enabled).
It has local firewall rules (using pf), but when I talk about a firewall I 
mean a separate box (Juniper/Checkpoint/something).


all in one system and you want use the OpenVPN tunnel as default route for 
your *other* hosts?


Heh, my description was pretty bad.

New try:
100 clients around the world connect to an OpenVPN server called "SRV".
SRV has a default route, so incoming and outgoing VPN packets use 
internet connection A (router A).


So far everything is as normal it can be. A server, a default route and an 
internet connection.


Next, all the vpn clients' traffic is sucked into their VPN tunnels (no 
split tunneling allowed).

The clients can reach internal servers. Good.
But when the clients surf the web, their traffic originates from SRV, 
using its default route towards the internet.


This works but is no longer what I want.

I now want the client traffic, aimed for the internet, to be routed 
elsewhere. 
In my case, "elsewhere" is a firewall with its own internet connection 
(B). The firewall is equipped with extra functions/blades to inspect 
client traffic and have all the rules for client traffic.


So basically I want the remote VPN users' surf traffic to pass through 
firewall B.


(
In my example, the VPN clients will get IPs in the 10.10.10.0/24 range.

Firewall B only need to route 10.10.10.0/24 to SRV in order to 
forward the response surf traffic back to the VPN clients.

)


So on SRV I need:
* traffic from SRV itself (openvpn responses, freebsd-update, mail, dns 
and other stuff) to 'any' should be routed to router A. Currently my 
default route.

* traffic with src net 10.10.10.0/24 to 'any' should be routed to B.

So two destinations for 'any'. Hence the need for source routing.

PS: traffic with src net 10.10.10.0/24 to internal nets, like 
10.20.30.0/24, should still be routed normally and not be thrown onto 
router B.


Hope that description is better.


In that case what you need is some kind of *policy* based 
routing.
One way to go about it with more than one FIB (aka kernel routing table). The 
problem is that you have to decide on the routing table to use before 
performing the route lookup. For packets forwarded through your FreeBSD 
router you have to select a non default FIB during input filtering e.g.

   # simple case
   ipfw add setfib 1 all from any to any in via $lan_if
   # complex case for multiple interfaces
   # ipfw table  add  
   ipfw table 1 add $lan_if1 1
   ipfw table 1 add $lan_if2 2
   ipfw table 1 add $lan_if3 2
   ipfw table 1 add $lan_if3 2
   # ...
   # lookup routing table number in a table
   ipfw add setfib tablearg all from any to any via table(1)
For traffic generated by your FreeBSD router you can't use the firewall to 
set the routing table because locally generated traffic only passes through 
output filtering by which time the routing decision has already happend. 
Instead you can set a processes default routing table with the setfib(1) 
utility or use a setsockopt(2) with SO_SETFIB for each socket. Jails can also 
set default routing table for sockets created inside the jail.


Heh. Do you mind giving another example now with the above description of 
the setup?

PS: i already use pf, not ipfw, on SRV.


Remember that your DNS resolver can leak a lot of information as well if it 
uses the default routing table.


Thanks for the heads-up. No, it uses an internal DNS.


I would avoid policies based on IP addresses and prefer to define policies 
based on (pseudo-) interfaces e.g. route (and nat?) traffic from vlan123 
through the VPN tunnel.


The only two things I have to play with here is:
* ip range 10.10.10.x
or
* tun0

Using 'tun0' might not be possible if it has to exist when ipfw/pf load 
at boot, 'cause tun0 is not created until the openvpn service has started.


/Elof
___

Source routing howto

[elof2]

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 dedicated for all 
client networks (VPN and physical), where all clients then leave the 
network.


The FreeBSD box has its own normal default gateway to speak with the 
internet.
This route is needed in order to be able to keep the OpenVPN-traffic 
flowing.


How do I source route the tunneled traffic, coming from e.g. 10.10.10.x to 
the "client firewall"?


Are there any good examples out there?
Do I have to compile a custom kernel?

(the responses back from that firewall use a normal static route, pointing 
10.10.10.0/24 to the FreeBSD box)


/Elof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPFW blocked my IPv6 NTP traffic

[elof2]

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 is supposed to be using port
123 as both the source and destination port, but I clearly have
something happening on port 16205. Is something screwy with ntpd in
CURRENT?


NTP not using port 123 as the source port usually indicates that it is
behind a NAT gateway at the other end.  It's harmless and fairly common.


...or simply that it is a ntp *client* like ntpdate, and not a daemon.
Clients often use a random source port, while ntpd use source port 123.



I wouldn't expect something in pool.ntp.org to be behind NAT and this
wasn't an ntp client like ntpdate, but those are both interesting
scenarios. Perhaps I'm just naive and they have a good reason for using
NAT in front of that NTP server.


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 [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via 
gif0

The blocked response came from port 123 just as expected.

If the client truly sent out a query from src port 123, then it must have 
been your NAT that picked a free random port to use for its outgoing 
connection, i.e. port 58285.
The server then respond back to your NAT-IP 2001:470:1f11:1e8::2 at port 
58285.

Your NAT should receive the packet, match it against its NAT table, find
that it has indeed an ongoing UDP connection for that particular flow, so 
it rewrites the dst IP and dst port to your original internal IP address 
and original port (123) and send it back to the client.


/Elof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPFW blocked my IPv6 NTP traffic

[elof2]

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 [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in
via gif0

The blocked response came from port 123 just as expected.

If the client truly sent out a query from src port 123, then it must have
been your NAT that picked a free random port to use for its outgoing
connection, i.e. port 58285.
The server then respond back to your NAT-IP 2001:470:1f11:1e8::2 at port
58285.
Your NAT should receive the packet, match it against its NAT table, find
that it has indeed an ongoing UDP connection for that particular flow, so
it rewrites the dst IP and dst port to your original internal IP address
and original port (123) and send it back to the client.

/Elof



There's no NAT involved with my IPv6.


Good. :-)

As I was saying, this was just a sidetrack to clarify that the portNAT 
would not be located at the ntp-server side.


/Elof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPFW blocked my IPv6 NTP traffic

[elof2]

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
something happening on port 16205. Is something screwy with ntpd in
CURRENT?


NTP not using port 123 as the source port usually indicates that it is
behind a NAT gateway at the other end.  It's harmless and fairly common.


...or simply that it is a ntp *client* like ntpdate, and not a daemon.
Clients often use a random source port, while ntpd use source port 123.

/Elof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPFW blocked my IPv6 NTP traffic

[elof2]

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 NTP server

Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP
[2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0


Three long-shots:

1)
I see that you use a gif interface. That makes me wonder:
Do the 'keep-state' function in 'ipfw' work as bad as it does in 'pf'?

In pf, 'keep state" doesn't keep state between software network 
interfaces and real network interfaces. So if I allow something in via 
tun0 (a software OpenVPN NIC), with keep state, the response is *not* 
automatically (via the state table) allowed back in on the ethernet NIC it 
was sent out. So for all my VPN-rules, I have to make two of them like 
this:


Pf example:
pass in  quick on tun0 inet proto tcp from  to  port 22 
keep state label "VpnIN - SSH"
pass out quick on em1  inet proto tcp from  to  port 22 
keep state label "DmzOUT - SSH"



2)
Is this hapening over and over, or was it just a one time thing?
If the latter, could it be that you flushed your firewall state table 
just after a cron job ran 'ntpdate 2604:a880:800:10::bc:c004', so the 
query got out but immediately after the state table was emptied and 
hence the response got blocked?




3)
If 2001:470:1f11:1e8::2 is not the ipfw node itself, but some node behind 
it, could the ntp query to 2604:a880:800:10::bc:c004 have taken a 
different path? I.e. the ipfw node doesn't see the query, but the response 
packet is routed to it, so it gets blocked.


/Elof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ngrep/ixgbe bpf bug

[elof2]

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  Netif   Flags  Recv  Drop Match Sblen Hblen Command
1800   igb0 p--s---   135 0   129   380 0 ngrep
The BPF stats show Recv and Match values. Good.


# ngrep -d bridge0 "q" ip
 I see some matching packets. Good.

# netstat -B
 Pid  Netif  FlagsRecv Drop Match  Sblen Hblen Command
1901  bridge0  p--s---  6618970659170 425606 0 ngrep
Again, the BPF stats show Recv and Match values. Good.



However, if I sniff on an ix interface:

# ngrep -d ix1 "q" ip
I get no matching packets!

# netstat -B
 Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
1816ix1 p--s--- 45340 0 0 0 0 ngrep
   ^^^
...and the BPF stats always show zero Matches.


Bug in the ixgbe driver or in ngrep?

/Elof


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: netstat -B "Recv"

[elof2]

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 Thu, 5 Nov 2015, Alexander V. Chernikov wrote:




04.11.2015, 19:55, "el...@sentor.se" :

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
Name Mtu Network Address Ipkts Ierrs Idrop Opkts
Oerrs Coll
ix0 1500  0c:c4:7a:58:e2:3c 0 0 0 0
0 0
ix1 1500  0c:c4:7a:58:e2:3d 600 0 0 0
0 0

and then
netstat -in
Name Mtu Network Address Ipkts Ierrs Idrop Opkts
Oerrs Coll
ix0 1500  0c:c4:7a:58:e2:3c 0 0 0 0
0 0
ix1 1500  0c:c4:7a:58:e2:3d 800 0 0 0
0 0

So 600 has increased to 800. Good.

However, 'netstat -B' show:
   Pid Netif Flags Recv Drop Match Sblen Hblen Command
25553 mon0 p--s--- 1996862 0 200 0 0 tcpdump

How can the "Recv" be *lower* than "Match"?
1996862 < 200.

For every new run (fast and slow) I get the same results, slightly less
than 200 Recv.

What am I missing?

Well, "Recv" is read from d->bd_rcount which is not per-cpu counter and is 
incrementing unlocked.
On the other hand, "Match" increases when filter returned match condition and 
we (w)locked bpf descriptor, so this one is accurate.


Ah. Thanks.


Will you make a bugzilla out of this? Or should I? Or is it not interesting 
enough to fix?

/Elof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: netstat -B "Recv"

[elof2]

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 ix0 -learn ix0 private ix0 \
 addm ix1 -discover ix1 -learn ix1 private ix1 \
  maxaddr 1 -arp monitor name mon0"

So 'mon0' is a monitor interface consisting of ix0 and ix1.
During my test, ix0 has no carrier, only ix1 is in use.

On the sending box I run tcpreplay to send 200 packets for each run.

Naturally I run the netstat commands on the receiving machine after the 
tcpreplay on the other machine has finished, not during. :-)




I reboot to start over from scratch.

I start a sniffer:
# tcpdump -nli mon0 -w /dev/null

# netstat -in
NameMtu Network   Address  Ipkts Ierrs IdropOpkts 
Oerrs  Coll
ix01500   0c:c4:7a:58:e2:3c0 0 00 
0 0
ix11500   0c:c4:7a:58:e2:3d0 0 00 
0 0
mon0   1500   02:74:e9:56:9c:000 0 00 
0 0


# netstat -B
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
 1422   mon0 p--s--- 0 0 0 0 0 tcpdump

I send 200 packets.

The receiver now show:
# netstat -in
NameMtu Network   Address  Ipkts Ierrs IdropOpkts 
Oerrs  Coll
ix01500   0c:c4:7a:58:e2:3c0 0 00 
0 0
ix11500   0c:c4:7a:58:e2:3d  200 0 00 
0 0
mon0   1500   02:74:e9:56:9c:00  200 0 00 
0 0


# netstat -B
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
 1422   mon0 p--s---   1999851 0   200 0 0 tcpdump

I press ctrl-c in tcpdump and it says:
200 packets captured
1999851 packets received by filter
0 packets dropped by kernel


So the BPF stats from both netstat and tcpdump look quite strange. :-)



I start a new tcpdump and send 200 new packets.

I now run 'netstat -B' a few times during the transfer, and one can see 
that the diffing packets are evenly distributed over time:

  Pid  Netif   Flags  Recv  Drop Match   Sblen Hblen Command
 1557   mon0 p--s--- 0 0 0   0 0 tcpdump
 1557   mon0 p--s---383905 0383923 1993540 0 tcpdump
 1557   mon0 p--s---651010 0651038 1112814 0 tcpdump
 1557   mon0 p--s---944090 0944128 2883633 0 tcpdump
 1557   mon0 p--s---   1125245 0   1125292 2034033 0 tcpdump
 1557   mon0 p--s---   1319456 0   1319514 467992  0 tcpdump
 1557   mon0 p--s---   1516545 0   1516618 4183543 0 tcpdump
 1557   mon0 p--s---   1760527 0   1760608 1365257 0 tcpdump
 1557   mon0 p--s---   108 0   200 2870940 0 tcpdump
 1557   mon0 p--s---   108 0   200   0 0 tcpdump
 1557   mon0 p--s---   108 0   200   0 0 tcpdump

ctrl-c on tcpdump says:
200 packets captured
108 packets received by filter
0 packets dropped by kernel



I run a tcpdump directly on ix1, instead of the bridge, and try again.
Same thing, so the bridge has nothing to do with it:
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
 1819ix1 p--s---   104 0   200 0 0 tcpdump

^C
200 packets captured
104 packets received by filter
0 packets dropped by kernel


I rebooted it again, started tcpdump on ix1 and received 200 packets.

By accident I forgot to kill other processes that might have an impact on 
my tests. Maybe that was a good thing, because 'netstat -B' now show:


  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  921   mon0 p--s---   200 76390   200 0 0 suricata
 1358ix1 p--s---   1999897 0   200 0 0 tcpdump

So the BPF stats for suricata is showing 200 received and 200 
matched (and a few drops) as it should.



Just to see if there would be any difference, I tried running tcpdump 
linebuffered but throwing away the output:

# tcpdump -nli ix1 > /dev/null

# netstat -B
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  921   mon0 p--s---   397214356   400 0 0 suricata
 1521ix1 p--s---   1999875 46200   200 0 0 tcpdump

^C
1953800 packets captured
1999875 packets received by filter
46200 packets dropped by kernel

Nope, same-same. (I don't know what I was expecting)

Since tcpdump is the one showing odd values I test with tshark 
(dumpcap) instead:

  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
  921   mon0 p--s---   596473528   600 0 0 suricata
 1624ix1 p--s---   

ngrep/ixgbe bpf bug

[elof2]

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   igb0 p--s---   135 0   129   380 0 ngrep
The BPF stats show Recv and Match values. Good.


# ngrep -d bridge0 "q" ip
  I see some matching packets. Good.

# netstat -B
  Pid  Netif  FlagsRecv Drop Match  Sblen Hblen Command
 1901  bridge0  p--s---  6618970659170 425606 0 ngrep
Again, the BPF stats show Recv and Match values. Good.



However, if I sniff on an ix interface:

# ngrep -d ix1 "q" ip
I get no matching packets!

# netstat -B
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
 1816ix1 p--s--- 45340 0 0 0 0 ngrep
^^^
...and the BPF stats always show zero Matches.


Bug in the ixgbe driver or in ngrep?

/Elof


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

netstat -B "Recv"

[elof2]

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  Ipkts Ierrs IdropOpkts 
Oerrs  Coll
ix01500   0c:c4:7a:58:e2:3c0 0 00 
0 0
ix11500   0c:c4:7a:58:e2:3d  600 0 00 
0 0


and then
netstat -in
NameMtu Network   Address  Ipkts Ierrs IdropOpkts 
Oerrs  Coll
ix01500   0c:c4:7a:58:e2:3c0 0 00 
0 0
ix11500   0c:c4:7a:58:e2:3d  800 0 00 
0 0


So 600 has increased to 800. Good.


However, 'netstat -B' show:
  Pid  Netif   Flags  Recv  Drop Match Sblen Hblen Command
25553   mon0 p--s---   1996862 0   200 0 0 tcpdump

How can the "Recv" be *lower* than "Match"?
1996862 < 200.


For every new run (fast and slow) I get the same results, slightly less 
than 200 Recv.


What am I missing?

/Elof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

sysctl and signed net.bpf.maxbufsize variable

[elof2]

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 result becomes negative.



...and also have some specific sanity control to test if you try to set a 
value wy out of bounds (like setting net.bpf.maxbufsize to a value greater 
than the maximum RAM).


/Elof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: oce(4) promiscous mode bug(?)

[elof2]

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 traffic. But just to 
rule out errors in the oce driver, what happen if you do not run in 
monitor mode?



Do 'netstat -in' show the same input errors as your sysctl counter?

(I assume you're running tcpdump with no bpf filter at all)

What do a couple of 'netstat -B' say while tcpdump is running?

/Elof



On Wed, 17 Jun 2015, Sergey Akhmatov wrote:


Tried disabling all offloadings available, doesn't help.


Sorry, in that case I don't know what it might be.

Have you tried disabling adapter intelligence? rxcsum, txcsum, lro, etc?


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Zerocopy bpf

[elof2]

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 
zerocopy.

Correct?

q3)
How do I see if zerocopy is used or not? 'netstat -B' don't tell me 
much, and the tool 'bpfstat' don't seem to exist any more.


q4)
When activating zerocopy, should I immediately see a performance boost on 
the machine? (like less drops on a heavily loaded sniffer NIC (running in 
monitor mode))


/Elof
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPMI stops respond if boot in single user mode

[elof2]

(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. Panfilov wrote:

Hi,

My IBM System x3250 M5 has IPMI. It shares onboard NIC Broadcom BCM5719.
I'm setup it and IPMI works perfectly.
But when server boots in single user mode IPMI's IP becomes unreachable.
It occures when bge0 init.

Any hints?

Thanks.


Details are:

FreeBSD 10.1-STABLE (r274690) amd64

/boot/loader.conf
hw.bge.allow_asf=1


bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev.
0x5719001 mem
0x82a5-0x82a5,0x82a4-0x82a4,0x82a3-0x82a3 irq 16
at device 0.0 on pci6
bge0: APE FW version: NCSI v1.2.33.0
bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E
miibus0: MII bus on bge0
brgphy0: BCM5719C 1000BASE-T media interface PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bge0: Using defaults for TSO: 65518/35/2048
bge0: Ethernet address: 6c:ae:8b:5b:74:98


bge0@pci0:6:0:0:class=0x02 card=0x04911014 chip=0x165714e4
rev=0x01 hdr=0x00
vendor = 'Broadcom Corporation'
device = 'NetXtreme BCM5719 Gigabit Ethernet PCIe'
class  = network
subclass   = ethernet
bar   [10] = type Prefetchable Memory, range 64, base 0x82a5,
size 65536, enabled
bar   [18] = type Prefetchable Memory, range 64, base 0x82a4,
size 65536, enabled
bar   [20] = type Prefetchable Memory, range 64, base 0x82a3,
size 65536, enabled
cap 01[48] = powerspec 3  supports D0 D3  current D0
cap 03[50] = VPD
cap 05[58] = MSI supports 8 messages, 64 bit enabled with 1 message
cap 11[a0] = MSI-X supports 17 messages
 Table in map 0x20[0x0], PBA in map 0x20[0x1000]
cap 10[ac] = PCI-Express 2 endpoint max data 128(256) FLR link x2(x4)
 speed 5.0(5.0) ASPM disabled(L0s/L1)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0003[13c] = Serial 1 6cae8b5b7498
ecap 0004[150] = Power Budgeting 1
ecap 0002[160] = VC 1 max VC0




When it boots in single-user mode and manually run:

#ifconfig bge0 up

then ipmi become accessable.

How it can be fixed automatically after system is boot in single-user mode?


--
With best regards,
Alexey V. Panfilov

phone: (495)678-8007 ext 6000
mail: le...@starnet.ru
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Unable to kill a non-zombie process with -9

[elof2]

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 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 08:46:59 snort[22648]: Reload thread starting...
Oct 15 08:46:59 snort[22648]: Reload thread started, thread 0x8146e8800 (22648)
End of log.

Error! Nothing more happens with the snort process!
Normally it should continue and log the following lines as well:


snort[nnn]: Decoding Ethernet
snort[nnn]: Checking PID path...
snort[nnn]: PID path stat checked out ok, PID path set to /var/run/
snort[nnn]: Writing PID 7627 to file /var/run//snort_mon0.pid
snort[nnn]: Chroot directory = /usr/foobar/log
snort[nnn]: Set gid to 100
snort[nnn]: Set uid to 100
snort[nnn]:
snort[nnn]: --== Initialization Complete ==--
snort[nnn]: Commencing packet processing (pid=nnn)





When looking at this half-started snort process with 'ps', it looks like 
this:


ps faxulwwj 22648
USER   PID %CPU %MEMVSZRSS TT  STAT STARTED TIME COMMAND 
UID PPID CPU PRI NI MWCHAN  PGID   SID JOBC
root 22648 51.8  1.1 488552 179344  -  Rs8:46AM 53:06.52 /usr/local/bin/s  
01   0  88  0 -  22648 226480


The process is still owned by root, so just as the missing log lines are 
saying, it has not yet performed any change of uid/gid.





So there seem to be two questions.

Q1)
What happens between Reload thread started, thread 0x8146e8800 (22648) and 
Decoding Ethernet?

Apparently something goes wrong here on FreeBSD 10.0.
(this problem does not always occur, sometimes snort start just fine)

Q2)
When the process has frozen in this half-started state, it can't be killed 
even with a -9. Why?





John-Mark asked me for some debugging info. Here it is:

I now run 'kill 22648' on the above semi-started process:

   USER   PID %CPU %MEMVSZRSS TT  STAT STARTED TIME COMMAND UID 
PPID CPU PRI NI MWCHAN  PGID   SID JOBC
old root 22648 51.8  1.1 488552 179344  -  Rs8:46AM 53:06.52 
/usr/local/bin/s   01   0  88  0 -  22648 226480
new root 22648 52.3  1.1 488552 179344  -  Rs8:46AM 53:36.48 
/usr/local/bin/s   01   0  52  0 -  22648 226480


No change.



kill -9 22648

   USER   PID %CPU %MEMVSZRSS TT  STAT STARTED TIME COMMAND UID 
PPID CPU PRI NI MWCHAN  PGID   SID JOBC
old root 22648 51.8  1.1 488552 179344  -  Rs8:46AM 53:06.52 
/usr/local/bin/s   01   0  88  0 -  22648 226480
new root 22648 37.7  1.1 488552 179344  -  Ts8:46AM 53:50.87 
/usr/local/bin/s   01   0  52  0 -  22648 226480


Less CPU-usage and STAT changed to Ts.




kill -CONT 22648

   USER   PID %CPU %MEMVSZRSS TT  STAT STARTED TIME COMMAND UID 
PPID CPU PRI NI MWCHAN  PGID   SID JOBC
old root 22648 51.8  1.1 488552 179344  -  Rs8:46AM 53:06.52 
/usr/local/bin/s   01   0  88  0 -  22648 226480
new root 22648  0.0  1.1 488552 179344  -  Ts8:46AM 53:50.88 
/usr/local/bin/s   01   0  52  0 -  22648 226480


No change except cpu is down to 0.


I now start 'kgdb'
info threads
I found two threads for snort, doing a bt for both of them:
 372 Thread 100602 (PID=22648: snort)  sched_switch (td=0xf802c061f490, 
newtd=value optimized out, flags=value optimized out) at 
/usr/src/sys/kern/sched_ule.c:1962
 371 Thread 100598 (PID=22648: snort)  sched_switch (td=0xf80221857000, 
newtd=value optimized out, flags=value optimized out) at 
/usr/src/sys/kern/sched_ule.c:1962

thread 372
[Switching to thread 372 (Thread 100602)]#0  sched_switch 
(td=0xf802c061f490, newtd=value optimized out, flags=value optimized 
out) at /usr/src/sys/kern/sched_ule.c:1962

1962in /usr/src/sys/kern/sched_ule.c
bt
#0  sched_switch (td=0xf802c061f490, newtd=value optimized out, 
flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1962
#1  0x808b8c1e in mi_switch (flags=266, newtd=0x0) at 
/usr/src/sys/kern/kern_synch.c:494
#2  0x808c04b0 in thread_suspend_switch (td=0xf802c061f490) at 
/usr/src/sys/kern/kern_thread.c:883
#3  0x808c0276 in thread_single (mode=1) at 
/usr/src/sys/kern/kern_thread.c:713
#4  0x8087c1bb in exit1 (td=0xf802c061f490, rv=9) at 
/usr/src/sys/kern/kern_exit.c:180
#5  0x808b2faf in sigexit (td=value optimized out, sig=value 
optimized out) at /usr/src/sys/kern/kern_sig.c:2935
#6  0x808b3669 in postsig (sig=value optimized out) at 
/usr/src/sys/kern/kern_sig.c:2822
#7  0x808f6f57 in ast (framep=value optimized out) at 
/usr/src/sys/kern/subr_trap.c:271
#8  0x80c75870 in Xfast_syscall () at 
/usr/src/sys/amd64/amd64/exception.S:416

#9  0x000801d6f19a in ?? ()
Previous 

Re: Unable to kill a non-zombie process with -9

[elof2]

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 08:46:59 snort[22648]: Reload thread starting...
Oct 15 08:46:59 snort[22648]: Reload thread started, thread 0x8146e8800 
(22648)

End of log.

Error! Nothing more happens with the snort process!
Normally it should continue and log these lines as well:


snort[nnn]: Decoding Ethernet
snort[nnn]: Checking PID path...
snort[nnn]: PID path stat checked out ok, PID path set to /var/run/
snort[nnn]: Writing PID 7627 to file /var/run//snort_mon0.pid
snort[nnn]: Chroot directory = /usr/foobar/log
snort[nnn]: Set gid to 100
snort[nnn]: Set uid to 100
snort[nnn]:
snort[nnn]: --== Initialization Complete ==--
snort[nnn]: Commencing packet processing (pid=nnn)





When looking at this half-started snort process with 'ps', it looks like 
this:


ps faxulwwj 22648
USER   PID %CPU %MEMVSZRSS TT  STAT STARTED TIME COMMAND 
UID PPID CPU PRI NI MWCHAN  PGID   SID JOBC
root 22648 51.8  1.1 488552 179344  -  Rs8:46AM 53:06.52 
/usr/local/bin/s   01   0  88  0 -  22648 226480



The process is still owned by root, so just as the missing log lines are 
saying, it has not yet performed any change of uid/gid.





So there seem to be two questions.

Q1)
What happens between Reload thread started, thread 0x8146e8800 (22648) 
and Decoding Ethernet?

Apparently something goes wrong here on FreeBSD 10.0.
(this problem does not always occur, sometimes snort start just fine)

Q2)
When the process has frozen in this half-started state, it can't be killed 
even with a -9. Why?





John-Mark asked me for some debugging info. Here it is:

I now run 'kill 22648' on the above semi-started process:

USER   PID %CPU %MEMVSZRSS TT  STAT STARTED TIME COMMAND 
UID PPID CPU PRI NI MWCHAN  PGID   SID JOBC
old root 22648 51.8  1.1 488552 179344  -  Rs8:46AM 53:06.52 
/usr/local/bin/s   01   0  88  0 -  22648 226480
new root 22648 52.3  1.1 488552 179344  -  Rs8:46AM 53:36.48 
/usr/local/bin/s   01   0  52  0 -  22648 226480


No change.



kill -9 22648

USER   PID %CPU %MEMVSZRSS TT  STAT STARTED TIME COMMAND 
UID PPID CPU PRI NI MWCHAN  PGID   SID JOBC
old root 22648 51.8  1.1 488552 179344  -  Rs8:46AM 53:06.52 
/usr/local/bin/s   01   0  88  0 -  22648 226480
new root 22648 37.7  1.1 488552 179344  -  Ts8:46AM 53:50.87 
/usr/local/bin/s   01   0  52  0 -  22648 226480


Less CPU-usage and STAT changed to Ts.




kill -CONT 22648

USER   PID %CPU %MEMVSZRSS TT  STAT STARTED TIME COMMAND 
UID PPID CPU PRI NI MWCHAN  PGID   SID JOBC
old root 22648 51.8  1.1 488552 179344  -  Rs8:46AM 53:06.52 
/usr/local/bin/s   01   0  88  0 -  22648 226480
new root 22648  0.0  1.1 488552 179344  -  Ts8:46AM 53:50.88 
/usr/local/bin/s   01   0  52  0 -  22648 226480


No change except cpu is down to 0.


I now start 'kgdb'
info threads
I found two threads for snort, doing a bt for both of them:
  372 Thread 100602 (PID=22648: snort)  sched_switch 
(td=0xf802c061f490, newtd=value optimized out, flags=value 
optimized out) at /usr/src/sys/kern/sched_ule.c:1962
  371 Thread 100598 (PID=22648: snort)  sched_switch 
(td=0xf80221857000, newtd=value optimized out, flags=value 
optimized out) at /usr/src/sys/kern/sched_ule.c:1962

thread 372
[Switching to thread 372 (Thread 100602)]#0  sched_switch 
(td=0xf802c061f490, newtd=value optimized out, flags=value 
optimized out) at /usr/src/sys/kern/sched_ule.c:1962

1962in /usr/src/sys/kern/sched_ule.c
bt
#0  sched_switch (td=0xf802c061f490, newtd=value optimized out, 
flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1962
#1  0x808b8c1e in mi_switch (flags=266, newtd=0x0) at 
/usr/src/sys/kern/kern_synch.c:494
#2  0x808c04b0 in thread_suspend_switch (td=0xf802c061f490) at 
/usr/src/sys/kern/kern_thread.c:883
#3  0x808c0276 in thread_single (mode=1) at 
/usr/src/sys/kern/kern_thread.c:713
#4  0x8087c1bb in exit1 (td=0xf802c061f490, rv=9) at 
/usr/src/sys/kern/kern_exit.c:180
#5  0x808b2faf in sigexit (td=value optimized out, sig=value 
optimized out) at /usr/src/sys/kern/kern_sig.c:2935
#6  0x808b3669 in postsig (sig=value optimized out) at 
/usr/src/sys/kern/kern_sig.c:2822
#7  0x808f6f57 in ast (framep=value optimized out) at 
/usr/src/sys/kern/subr_trap.c:271
#8  0x80c75870 in Xfast_syscall () at 
/usr/src/sys/amd64/amd64/exception.S:416

#9  0x000801d6f19a in ?? ()
Previous frame inner to this frame (corrupt stack?)


thread 371
[Switching to thread 371 (Thread 100598)]#0  sched_switch 
(td=0xf80221857000, newtd=value optimized out, flags=value 

Unable to kill a non-zombie process with -9

[elof2]

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 seen 
this behavior until now in FreeBSD 10.0.



Example:

#ps faxuw
USER  PID  %CPU %MEMVSZRSS TT  STAT STARTEDTIME 
COMMAND
root49222  53.4  2.2 492648 183012  -  Rs   11:46AM 7:05.59 
/usr/local/bin/snort -q -D -c snort.conf
root47937   0.0  2.2 488552 182864  -  Ts   10:56AM29:35.98 
/usr/local/bin/snort -q -D -c snort.conf


The pid 47937 has been killed (repeatedly) with -9.
Its status is Ts meaning it is Stopped.
But it won't actually die and disappear. The only way to get rid of it 
seem to be to reboot the machine. :-(


(pid 49222 is the new process that was started after 47937 was killed)


The problem doesn't happen all the time and I haven't found any patterns 
as to when it does. :-(
If I restart snort once every day, it fails to die approximately 2-4 times 
per month.
Even though the problem doesn't happen on every kill, it is a definately a 
recurring event.


I began to see it on a heavily loaded 10GE sensor, so I thought it could 
have something to do with the ix driver, or the heavy load.
But now another FreeBSD 10.0-sensor had the exact same problem, and this 
sensor don't have any 10GE NICs. In fact, this sensor has been running 
just fine with both FreeBSD 9.1 and 9.3 for the past years. Snort has 
always terminated correctly! After I reinstalled this machine with FreeBSD 
10.0 last friday, snort has then terminated correctly every day until 
today, when it failed with the above pid 47937. (this sensor use the 'em' 
driver, not 'ixgbe')


I'm running snort with the same configuration, settings, version, daq, 
libs, etc on 10.0 as I do on 9.3.
None of the 9.3 sensors have this problem, so it has to be something new 
in FreeBSD 10.0.




Q1:
Has anyone seen anything simillar, or have any clues as to what is going 
on and why?



Q2:
Is there any other way to kill and purge the stopped process? I don't want 
it laying around.

('kill -HUP 1' didn't help)




(
The closest thing I've come across myself is last year, when I 
tested enabling zerocopy-bpf in FreeBSD 9.1. Then I couldn't kill snort 
if the sniffer-interface was completely silent.
The above problem is not like this though. I haven't enabled zerocopy and 
there are lots of mirrored traffic on the sniffer interface.

)

/Elof

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: kern/139268: [if_bridge] [patch] allow if_bridge to forward just VLAN-tagged (or untagged) packets

[elof2]

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 14:57:46 +0100 (CET)

 I'm attaching my semi-related feature request to P Kern's request from 
 2009.
 
 Allow if_bridge to normalise frames before sending them to bpf, to 
 simplify (and sometimes correctify) traffic sniffing and network 
 debugging.
 
 
 
 Question:
 How do I get in touch with a developer that can make this feature find 
 its way into FreeBSD base? What would it cost me and how soon could it be 
 added?
 
 
 
 
 Scenario:
 I create a bridge0 interface using (one or) multiple parent NICs. Then I
 sniff the traffic on this cloned NIC, 'tcpdump -nli bridge0 port 80'.
 
 Benefit:
 Multiple NICs are bonded together and can easily be sniffed on ONE
 interface with ONE sniffer process.
 
 Drawback:
 If the sniffer use a bpf filter like port 80, and the incoming mirrored 
 traffic consist of a mix of untagged and vlan tagged (802.1q) packets, 
 only the untagged packets will match. To see if there are any www-traffic 
 in the mirrored vlans, one need to change the filter to vlan and port 
 80, but then you loose the untagged lan.   ...a catch 22. :-(
 
 
 
 The file sys/net/if_bridge.c prior to revision 186365 
 (http://svn.freebsd.org/viewvc/base?view=revisionrevision=186365) used 
 the function call BPF_MTAP to send a copy of a packet to bpf. Since this 
 gave a stripped packet to the sniffer rather than the full and correct frame, 
 this bug was corrected in revision 186365 using ETHER_BPF_MTAP.
 
 My request is simply to have the possibility to override the defaults 
 and do it the buggy way again, since this proved to be a great feature 
 rather than a bug. :-)
 
 
 
 Having a function that simply strips off any vlan tag from tagged packets
 is wonderful when it comes to sniffing. Especially since switches from all
 brands behave differently when it comes to SPAN and vlan tags (a SYN 
 packet could be mirrorred untagged while the corresponding SYN+ACK is 
 mirrored with a vlan tag set). It is also quite common that net admins 
 configure uplink ports with multiple vlans AND an untagged lan. When you 
 SPAN this uplink you get both tagged and untagged traffic in a mix, making 
 it hard to work with one bpf filter on the full scope of the received 
 traffic.
 
 By normalising the mirrored traffic sent to bpf, a network technician can
 more easily perform his network debugging. Also, there are less risk of
 human mistakes due to the lack of insight that he need to use the
 'vlan' keyword in his tcpdump/tshark/ngrep/whatever to match the traffic. 
 Also state-keeping tools like snort and argus benefit from normalised 
 traffic since they fail to build a correct state table if the SYN and 
 SYN+ACK belong to two different vlans.
 
 
 My request is that if a sysctl variable (like
 net.link.bridge.bpf.strip_header) is true, then if_bridge will pass
 stripped packets to bpf. By default it should naturally pass
 the full frame.
 
 
 
 PS. There are only four places in if_bridge.c that need to be updated to
 something like this, so the actual work to do is pretty simple:
if (net.link.bridge.bpf.strip_header == 1)
  BPF_MTAP(bifp, m);
else
  ETHER_BPF_MTAP(bifp, m);
 
 /Elof
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Request to developers of if_bridge.ko - ETHER_BPF_MTAP vs BPF_MTAP

[elof2]

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 on 
based on a sysctl flag.




Scenario:
I create a bridge0 interface using one or multiple parent NICs. Then I 
sniff traffic on this cloned NIC (tcpdump -nli bridge0 port 80).


Benefit:
Multiple NICs are bonded together and can easily be sniffed on ONE 
interface with ONE sniffer process.


Drawback:
The problem is that if the sniffer use a bpf filter like port 80, and 
the mirrored traffic consist of a mix of untagged and vlan tagged 
(802.1q) packets, only the untagged packets will match. To see if there 
are any www-traffic in the mirrored vlans, one need to change the filter 
to vlan and port 80, but then you loose the untagged lan. ...catch 22.



The bug (feature) in sys/net/if_bridge.c prior to revision 186365
(http://svn.freebsd.org/viewvc/base?view=revisionrevision=186365) was 
that if_bridge sent a copy of a packet to bpf using BPF_MTAP instead of 
using ETHER_BPF_MTAP.
The result was that the sniffer got a copy of packets that had their vlan 
header (tag) stripped off.


In the patched version, the full frame is mirrored to bpf. While this is 
correct, I'd like the possibility to override and see stripped packets 
instead.




Having a function that simply strips off any vlan tags from tagged packets 
is wonderful when it comes to sniffing. Especially since switches from all 
brands behave differently when it comes to SPAN and vlan tags (a SYN 
could be mirrorred untagged while the corresponding SYN+ACK is mirrored 
with a vlan tag set). It is also quite common that net admins configure 
uplink ports with multiple vlans AND an untagged lan. When you SPAN this 
uplink you get both tagged and untagged traffic in a mix.


By normalising the mirrored traffic sent to bpf, a network technician can 
more easily perform his network debugging. Also, there are less risk of 
human mistakes due to the lack of insight that he need to use the 
'vlan' keyword in his tcpdump/tshark/ngrep/whatever to see the full scope 
of the traffic. Also state-keeping tools like snort and argus benefit from 
normalised traffic since they cann't build a correct state table if the 
SYN and SYN+ACK belong to two different vlans.



My request is that if a sysctl variable (like 
net.link.bridge.bpf.strip_header) equals true, then if_bridge.ko will pass 
stripped (BPF_MTAP) packets to bpf. By default it should naturally pass 
the entire frame (ETHER_BPF_MTAP).



I know that passing stripped packets to bpf could be seen as ugly and 
bad, but compared to some of the problems a mixed environment can cause, I 
think that the possibility to manually override the default would be very
useful. (in fact I know it, since I relied on the bug during the FreeBSD 
6.3-6.4 period)



There are only four places in if_bridge.c that need to be updated to 
something like this:

if (net.link.bridge.bpf.strip_header == 1)
  BPF_MTAP(bifp, m);
else
  ETHER_BPF_MTAP(bifp, m);


The question is if other people besides myself see the benefits?
Could we have this feature added to FreeBSD base?
What are your thoughts?

/Elof
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: kern/154443: [bridge] Kernel module bridgestp.ko missing after upgrade (if_bridge.ko depend on it)

[elof2]

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 to the bug report:
 
 It is not only the bridgestp.ko file that is missing.
 
 I've looked at /boot/kernel/*.ko on a system that was binary upgraded 
 from 6.4-RELEASE to 7.3-RELEASE (i386) and compared it with a 7.3-RELEASE
 (i386) system installed from CD.
 
 The upgraded system has a total of 470 kernel modules.
 ls /boot/kernel/*.ko | wc -l
 470
 
 The CD-installed box has 572 kernel modules.
 ls /boot/kernel/*.ko | wc -l
 572
 
 
 Apart from bridgestp.ko, there are 101 other missing modules after the 
 upgrade. :-/
 
 The command 'freebsd-update IDS' does not complain about any of these 
 missing files!
 
 
 
 When diffing the 470 vs 572 files, no modules on the upgraded system are 
 missing on the CD-installed system. All differences (102 in total) are 
 files that exist on the CD-installed system but not on the upgraded one.
 
 Here's a list of all missing kernel modules after upgrade:
 
 /boot/kernel/acpi_aiboost.ko
 /boot/kernel/alias_cuseeme.ko
 /boot/kernel/alias_dummy.ko
 /boot/kernel/alias_ftp.ko
 /boot/kernel/alias_irc.ko
 /boot/kernel/alias_nbt.ko
 /boot/kernel/alias_pptp.ko
 /boot/kernel/alias_skinny.ko
 /boot/kernel/alias_smedia.ko
 /boot/kernel/amdsbwd.ko
 /boot/kernel/amdtemp.ko
 /boot/kernel/bridgestp.ko
 /boot/kernel/cmx.ko
 /boot/kernel/cpuctl.ko
 /boot/kernel/cxgb_t3fw.ko
 /boot/kernel/cyclic.ko
 /boot/kernel/dpms.ko
 /boot/kernel/dtmalloc.ko
 /boot/kernel/dtrace.ko
 /boot/kernel/dtrace_test.ko
 /boot/kernel/dtraceall.ko
 /boot/kernel/fbt.ko
 /boot/kernel/geom_cache.ko
 /boot/kernel/geom_journal.ko
 /boot/kernel/geom_linux_lvm.ko
 /boot/kernel/geom_multipath.ko
 /boot/kernel/geom_part_apm.ko
 /boot/kernel/geom_part_bsd.ko
 /boot/kernel/geom_part_ebr.ko
 /boot/kernel/geom_part_gpt.ko
 /boot/kernel/geom_part_mbr.ko
 /boot/kernel/geom_part_pc98.ko
 /boot/kernel/geom_part_vtoc8.ko
 /boot/kernel/geom_virstor.ko
 /boot/kernel/glxsb.ko
 /boot/kernel/hptiop.ko
 /boot/kernel/if_ae.ko
 /boot/kernel/if_age.ko
 /boot/kernel/if_alc.ko
 /boot/kernel/if_ale.ko
 /boot/kernel/if_cas.ko
 /boot/kernel/if_et.ko
 /boot/kernel/if_igb.ko
 /boot/kernel/if_lmc.ko
 /boot/kernel/if_malo.ko
 /boot/kernel/if_nfe.ko
 /boot/kernel/if_nxge.ko
 /boot/kernel/if_rum.ko
 /boot/kernel/if_wpi.ko
 /boot/kernel/if_zyd.ko
 /boot/kernel/ipfw_nat.ko
 /boot/kernel/ipw_bss.ko
 /boot/kernel/ipw_ibss.ko
 /boot/kernel/ipw_monitor.ko
 /boot/kernel/iscsi_initiator.ko
 /boot/kernel/isp_1040.ko
 /boot/kernel/isp_1040_it.ko
 /boot/kernel/isp_1080.ko
 /boot/kernel/isp_1080_it.ko
 /boot/kernel/isp_12160.ko
 /boot/kernel/isp_12160_it.ko
 /boot/kernel/isp_2100.ko
 /boot/kernel/isp_2200.ko
 /boot/kernel/isp_2300.ko
 /boot/kernel/isp_2322.ko
 /boot/kernel/isp_2400.ko
 /boot/kernel/iw_cxgb.ko
 /boot/kernel/iwi_bss.ko
 /boot/kernel/iwi_ibss.ko
 /boot/kernel/ipw_monitor.ko
 /boot/kernel/iscsi_initiator.ko
 /boot/kernel/isp_1040.ko
 /boot/kernel/isp_1040_it.ko
 /boot/kernel/isp_1080.ko
 /boot/kernel/isp_1080_it.ko
 /boot/kernel/isp_12160.ko
 /boot/kernel/isp_12160_it.ko
 /boot/kernel/isp_2100.ko
 /boot/kernel/isp_2200.ko
 /boot/kernel/isp_2300.ko
 /boot/kernel/isp_2322.ko
 /boot/kernel/isp_2400.ko
 /boot/kernel/iw_cxgb.ko
 /boot/kernel/iwi_bss.ko
 /boot/kernel/iwi_ibss.ko
 /boot/kernel/iwi_monitor.ko
 /boot/kernel/krping.ko
 /boot/kernel/lindev.ko
 /boot/kernel/mmc.ko
 /boot/kernel/mmcsd.ko
 /boot/kernel/mqueuefs.ko
 /boot/kernel/ng_car.ko
 /boot/kernel/ohci.ko
 /boot/kernel/opensolaris.ko
 /boot/kernel/profile.ko
 /boot/kernel/prototype.ko
 /boot/kernel/rdma_addr.ko
 /boot/kernel/rdma_cma.ko
 /boot/kernel/rdma_core.ko
 /boot/kernel/rdma_iwcm.ko
 /boot/kernel/scc.ko
 /boot/kernel/sdhci.ko
 /boot/kernel/sdt.ko
 /boot/kernel/sem.ko
 /boot/kernel/snd_emu10kx.ko
 /boot/kernel/systrace.ko
 /boot/kernel/tmpfs.ko
 /boot/kernel/toecore.ko
 /boot/kernel/tom.ko
 /boot/kernel/u3g.ko
 /boot/kernel/ufoma.ko
 /boot/kernel/uhci.ko
 /boot/kernel/uslcom.ko
 /boot/kernel/wlan_scan_ap.ko
 /boot/kernel/wlan_scan_sta.ko
 /boot/kernel/wpifw.ko
 /boot/kernel/xfs.ko
 /boot/kernel/zfs.ko
 
 /Elof
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org