[Bug 204437] 10.2 STABLE Crashing with IPSec Support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204437 --- Comment #13 from emeric.pou...@stormshield.eu --- Created attachment 163350 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163350&action=edit Fix race in in_pcbrele_wlocked We are now sure there is a race in in_pcbrele_wlocked: the returned inp may have been freed (problem spotted on a test machine) Please try the attached patch. Additionally, we would need to check every caller to make sure they check the inp once they unlock/relock the inp -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
Broken gif configuration compatibity
Hi!
I've just upgraded my 9.3-STABLE system to 10.2-STABLE and found that
my gif-interfaces no longer have "inet" IP addresses after boot.
"tunnel" addresses are still assigned.
I've digged this and found small bug in the commint
https://svnweb.freebsd.org/base?view=revision&revision=253924
that broken this. It overrides ifconfig_${ifn} with tunnel settings
instead of adding them to this variable.
One-line trivial fix restores compatibility:
--- src/network.subr.orig 2015-11-19 16:53:25.50944 +0700
+++ src/network.subr2015-11-20 18:47:36.914275000 +0700
@@ -1330,7 +1330,7 @@
_list="$_list $ifn"
fi
tmpargs=$(get_if_var $ifn gifconfig_IF)
- eval ifconfig_${ifn}=\"tunnel \$tmpargs\"
+ eval ifconfig_${ifn}=\"\$ifconfig_${ifn} tunnel \$tmpargs\"
done
if [ -n "${_list# }" ]; then
echo "Created clone interfaces: ${_list# }."
I've just filled PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204700
Please consider fixing this.
Eugene Grosbein
___
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"
porting of dladm
Hi FreeBSD networker, for some years now, I'm using FreeBSD coming from OpenSolaris and later OmniOS. The one thing I'm missing after all this time is the network handling. VIMAGE was a big step forward around 2010/2011, but it is still not at the point where crossbow on Illumos already is. Also ifconfig was deprecated shortly before the closing of opensolaris. Yes, the stuff left behind was broken, but I think the idea behind splitting up ifconfig into separate tools was a very good idea. After all that time waiting for things to get better in FreeBSD, I want to help make things better. For that, the first step I want to do is to port dladm and ipadm to FreeBSD. These tools split the hardware configuration from the protocol configuration, where dladm configures all kind of network devices and ipadm concentrates on ip configuration. For people who have never seen dladm, I can recommend the man page http://illumos.org/man/1M/dladm dladm is implemented as a client/server program, where the server runs in the background and handles the network interface configuration. The command line client sends messages to the server on what the user wants it to do. As I am not that good to decide if that is a good approach or not, I will start porting it to freebsd and on the way figure out, what might be good to change to make it work in a better way. In the long term, I want to use dladm as a platform to get other features into FreeBSD like the virtual switch or wifi configuration wihtout the need to install additional tools (maybe we can have something without wpa_supplicant?). Is there interest in this project at all or does anyone know if someone else is working on a similar project? Thank you, Gibheer ___ 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"
Outgoing packets being sent via wrong interface
Hi. (Please keep me in CC as I'm not subscribed to freebsd-net@.) A router running recent 10-stable configured like this... re0: flags=8843 metric 0 mtu 1500 options=8209b ether 90:2b:34:bb:b2:e7 inet 82.x.y.50 netmask 0xfff0 broadcast 82.x.y.255 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active re1: flags=8843 metric 0 mtu 1500 options=8209b ether b8:a3:86:7b:e9:9c inet 192.168.2.8 netmask 0xff00 broadcast 192.168.2.255 inet 192.168.2.5 netmask 0xff00 broadcast 192.168.2.255 inet 192.168.2.15 netmask 0xff00 broadcast 192.168.2.255 inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active ... exhibits a very weird behaviour. When rebooted, it runs (= routes traffic) with no problem. After some time (or maybe after some event, see below), it starts to think that some hosts from 192.168.2.x subnet are "outside" and sends _some_ packets destined to 192.168.2.x via re0 interface. The most absurd is the case when a jail @ 192.168.2.5 makes a tcp connection to jail @ 192.168.2.15, and the system tries to push this via re0. There is pf nat rule on re0 that updates the sender address, and packets are then dropped by firewall rules that prohibit sending packets to private subnets via public interface. This is a capture from pflog... 00:00:00.151624 rule 53..16777216/0(match): block out on re0: 82.x.y.50.59615 > 192.168.2.15.3306: Flags [.], ack 3421441707, win 1275, options [nop,nop,TS val 250304266 ecr 1531964207], length 0 00:00:00.000226 rule 53..16777216/0(match): block out on re0: 82.x.y.50.55539 > 192.168.2.15.3306: Flags [.], ack 3421441707, win 1275, options [nop,nop,TS val 250304266 ecr 1531964207], length 0 00:00:00.000143 rule 53..16777216/0(match): block out on re0: 82.x.y.50.50682 > 192.168.2.15.3306: Flags [P.], seq 2828804971:2828805095, ack 3421441707, win 1275, options [nop,nop,TS val 250304266 ecr 1531964207], length 124 ... and this is the case when jail @ 192.168.2.15 makes request to DNS server running @ 192.168.2.1... 00:00:01.784024 rule 53..16777216/0(match): block out on re0: 82.x.y.50.57878 > 192.168.2.15.12269: UDP, length 104 00:00:00.001487 rule 53..16777216/0(match): block out on re0: 82.x.y.50.65204 > 192.168.2.15.12269: UDP, length 178 00:00:00.002425 rule 53..16777216/0(match): block out on re0: 82.x.y.50.59323 > 192.168.2.15.12269: UDP, length 229 00:00:00.026260 rule 53..16777216/0(match): block out on re0: 82.x.y.50.55382 > 192.168.2.15.12269: UDP, length 120 In both cases, response packets, originally from 192.168.2.5 and 192.168.2.1, are natted to sender 82.x.y.50 and pushed out via re0. Weird is also ping result for affected address... PING 192.168.2.15 (192.168.2.15): 56 data bytes ping: sendto: Operation not permitted ping: sendto: Operation not permitted 64 bytes from 192.168.2.15: icmp_seq=2 ttl=64 time=0.027 ms ping: sendto: Operation not permitted 64 bytes from 192.168.2.15: icmp_seq=4 ttl=64 time=0.102 ms It seems like some packets go the right way, some go wrong (and are dropped by pf -> "not permitted"). Routing and ARP table entries are correct... 82.x.y.0/24link#2 U re0 82.x.y.50 link#2 UHS lo0 192.168.2.0/24 link#3 U re1 192.168.2.1link#3 UHS lo0 192.168.2.5link#3 UHS lo0 192.168.2.8link#3 UHS lo0 192.168.2.15 link#3 UHS lo0 ? (192.168.2.15) at b8:a3:86:7b:e9:9c on re1 permanent [ethernet] ? (192.168.2.5) at b8:a3:86:7b:e9:9c on re1 permanent [ethernet] ? (82.x.y.50) at 90:2b:34:bb:b2:e7 on re0 permanent [ethernet] Refreshing ARP entries (by removing them) and/or manually adding specific host routes does not help. Only reboot cures the problem. May be related: the host has a cron task that changes default route based on a connectivity check. On another host (identical software- and hardware-wise), that serves the same purpose in another locality, just without default route mangling, we've never observed this weird behaviour. Note: the host was previously running 9-stable, same configuration, including the cron task to update default route. But problems described above started just after upgrading it to 10-stable. Has anybody observed such behaviour on any 10.x system? Any hints on how to debug and/or solve the problem, when it happens? Thanks for your attention. -- Dan ___ 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: Outgoing packets being sent via wrong interface
> On 20 Nov 2015, at 15:55, Daniel Bilik wrote: > Any hints on how to debug and/or solve the problem, when it happens? Can you post your pf rules too? Thanks, Kristof ___ 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: porting of dladm
As I am not that good to decide if that is a good approach or not, I > will start porting it to freebsd and on the way figure out, what might > be good to change to make it work in a better way. > > http://illumos.org/man/1M/dladm > > dladm is implemented as a client/server program, where the server runs > in the background and handles the network interface configuration. The > command line client sends messages to the server on what the user wants > it to do. > It is a good approach. From multiple reasons such as : -ability to separate privileges (for ex keep config file parser in a separate process, parsers are notoriously troublesome components. - ability to run clients in capabilities modes. -possibility to delegate administration to other users (requires additional fine grained permission mechanism in FreeBSD) -server presents a central IPC point which can be called by multiple components. Solaris uses a synchronous fast IPC mechanism called doors in many of their administrative daemons, at the present time FreEBSD doesn't have a similar one, but you can use unix domain just OK It is my opinion that you would be well served by: 1. abstract FreeBSD specific code libraries (not for portability reasons. But to enable others to reuse those very important entry points easily) 2. use a transactional database model for the files where you will keep your settings 3. look at capabilities mode in FreeBSD capsicum to implement the protection model in clients and co-processes. 4. look at nvlist library which will apear in FreEBSD 11 to help you design your IPC entry points 5. design with the possibility for delegated administration in mind, although most likely you would have to add it later. 6. think to other candiates which can be assimilated in same control daemon (or in separate, but similar ones ) most obvious candidates: dhcp, rtsol .. in adition to ifconfig and wpa this is the way of the future in enterprise OSes. Efforts like this are part, or will be soon, of the plans in many operating systems today. Solaris has wonderful Enterprise features. It will not be easy to design this to fit cleanly with FreeBSD as it is now, but it is possible. It is a great project, in my opinion. ___ 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: Outgoing packets being sent via wrong interface
On Fri, 20 Nov 2015 16:18:10 +0100
Kristof Provost wrote:
> Can you post your pf rules too?
Sure, pf.conf attached.
--
Dan
int_if="re1"
ext_if="re0"
vpn_if="tap0"
ext_addr="82.x.y.50"
int_net="192.168.2.0/24"
vpn_net="{ 192.168.1.0/24, 192.168.4.0/24, 192.168.123.0/24 }"
priv_net="{ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.1, 224.0.0.2,
224.0.0.4, 224.0.0.5, 224.0.0.6, 224.0.0.9, 224.0.0.13, 224.0.0.15 }"
webmail="192.168.2.5"
mailserver="192.168.2.15"
dnsserver="{ 192.168.2.0/28, 192.168.1.0/28 }"
switchboard="192.168.2.16"
camera="192.168.2.221"
set skip on { lo0, $vpn_if }
scrub in on $ext_if all fragment reassemble
scrub out on $ext_if random-id
# traffic control
altq on $ext_if bandwidth 8Mb cbq queue { ssh, vpn, mail, web, default }
queue vpn bandwidth 2Mb priority 5 cbq(borrow)
queue ssh bandwidth 1Mb priority 4 cbq(borrow)
queue web bandwidth 1Mb priority 3 cbq(borrow)
queue mail bandwidth 1Mb priority 2 cbq(borrow)
queue default bandwidth 2Mb priority 1 cbq(default, borrow)
# nat
# note: do not change source port for this specific sip communication
nat on $ext_if proto udp from $switchboard to 188.x.y.0/24 -> $ext_addr
static-port
nat on $ext_if from $int_net to any -> $ext_addr
rdr on $ext_if proto tcp from any to $ext_addr port { 25, 465, 587, 995 } ->
$mailserver
rdr on $ext_if proto tcp from any to $ext_addr port { 443, 777, 5145 } ->
$webmail
rdr on $ext_if proto tcp from any to $ext_addr port { 554, 6036 } -> $camera
rdr on $ext_if proto tcp from any to $ext_addr port 6543 -> $switchboard
rdr on $ext_if proto tcp from any to $ext_addr port 6992 -> $switchboard
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr pass on $int_if proto tcp from $int_net to any port 21 -> 127.0.0.1 port
8021
# firewall
block in log all
pass in quick on $int_if inet proto carp
pass in quick on $int_if inet proto tcp from any to $mailserver port { 25, 465,
587, 10024 } keep state
block in log quick on $int_if inet proto tcp from any to any port { 25, 465,
587 }
pass in quick on $int_if inet proto { tcp, udp } from any to $dnsserver port 53
keep state
pass in quick on $int_if inet proto { tcp, udp } from $dnsserver to any port 53
keep state
block in log quick on $int_if inet proto { tcp, udp } from any to any port 53
pass in quick on $int_if inet from $int_net to any keep state
pass in quick on $int_if inet from $vpn_net to $int_net keep state
pass in quick on $int_if proto gre from $int_net to 82.x.y.22 keep state
block in log quick on $ext_if from $priv_net to any
pass in quick on $ext_if inet proto icmp from any to $ext_addr
pass in quick on $ext_if inet proto udp from 82.x.y.62 to $ext_addr port 1194
keep state queue vpn
pass in quick on $ext_if inet proto tcp from any to $ext_addr port 22 keep
state queue ssh
pass in quick on $ext_if inet proto tcp from any to $mailserver port { 25, 465,
587, 995 } keep state (source-track rule, max-src-conn 50) queue mail
pass in quick on $ext_if inet proto tcp from any to $webmail port { 443, 777,
5145 } keep state (source-track rule, max-src-conn 50) queue web
pass in quick on $ext_if inet proto tcp from any to $camera port { 554, 6036 }
keep state
pass in quick on $ext_if inet proto tcp from any to $switchboard port { 6543,
6992 } keep state
block out log all
block out log quick on $ext_if from any to $priv_net
block out log quick on $ext_if inet proto { tcp, udp } from any to any port
137:139
anchor "ftp-proxy/*"
pass out quick on $ext_if inet proto tcp from $mailserver to any keep state
queue mail
pass out quick on $ext_if inet proto udp from $ext_addr to 82.x.y.62 port 1194
keep state queue vpn
pass out quick on { $ext_if, $int_if } inet from any to any keep state
___
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"
[Bug 204437] 10.2 STABLE Crashing with IPSec Support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204437 --- Comment #14 from Cassiano Peixoto --- (In reply to emeric.poupon from comment #13) Hi emeric, Did you check my debug? are you sure we are talking about the same issue? Should i test this patch? Have i just recompile kernel or buidworld too? Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 204437] 10.2 STABLE Crashing with IPSec Support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204437 --- Comment #15 from emeric.pou...@stormshield.eu --- Hi, Yes I am talking about the same issue. Just rebuild the kernel with this patch, and please let me know the results. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 204453] panic: vnic0: Received packet fragment with NULL mbuf from ThunderX VNIC driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204453 Ed Maste changed: What|Removed |Added Assignee|freebsd-net@FreeBSD.org |z...@freebsd.org --- Comment #1 from Ed Maste --- Workaround in review at https://reviews.freebsd.org/D4234 -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
