Re: openbgpds not talking each other since 8.2-STABLE upgrade
On Jan 3, 2012, at 4:29 PM, Ed Maste wrote:
> Thanks for the link Nikolay.
>
> Borja, I assume it's the PR submission form that gave you trouble -
> sorry for that. Based on your report it sounds to me like the bug is
> in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option
> though I'd assume it's due to a difference in our (FreeBSD's)
> implementation of the option. Did you look at the OpenBSD/FreeBSD
> differences in your investigation?
I looked at OpenBGPd. By the way, I was having the same issue on the different
FreeBSD 9 RC's I was trying.
Have a look at session.c, line 148, function setup_listeners()
opt = 1;
if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG,
&opt, sizeof(opt)) == -1) {
if (errno == ENOPROTOOPT) { /* system w/o md5sig */
log_warnx("md5sig not available, disabling");
sysdep.no_md5sig = 1;
} else
fatal("setsockopt TCP_MD5SIG");
}
Seems that the function is using the setsockopt to check the availability of
TCP_MD5.
But, even though I haven't had a look at it on OpenBSD, I can make an educated
guess:
Behavior on FreeBSD: The setsockopt(TCP_MD5SIG) *enables* TCP_MD5. According to
my packet captures, in case there's no properly set key with setkey(8) it will
use whatever key. Look at the captures mentioned here:
http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/ea347a919dbc165d/eeaa2965fc4f64c9?show_docid=eeaa2965fc4f64c9&pli=1
Behavior on OpenBSD: Maybe the TCP_MD5 isn't *really* working unless there's a
valid key associated to the socket, either using setkey(8) (I don't know if
they use it) or via the API for setting keys.
Whatever: Maybe FreeBSD should *ignore* that TCP_MD5SIG option for a socket
unless (or until) a key is associated, or OpenBGPd should be modified so that
it won't "probe" the availability of TCP_MD5SIG by actually setting it. Of
course, if setting it for a socket is the best way to detect it, you can always
create a temporary socket, you don't even need to bind() it, set TCP_MD5SIG, so
that you will know if it succeeds or returns an error, and destroy the socket.
The problem in this case is that OpenBGPd is *setting* TCP_MD5SIG on a socket
no matter if I have configured the BGP peer with or without TCP_MD5. Neither
Quagga nor Bird do it.
Borja.
___
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: pf not seeing inbound packets on netgraph interface
On Wed, Jan 4, 2012 at 5:29 AM, Ed Carrel wrote: > Hi freebsd-net, > > I originally sent this to -questions@, but was redirected here by that > list. My original question is below: > > I am running into a roadblock getting PF to filter traffic on a Netgraph > interface representing an L2TP/IPSec connection. I have done some narrowing > down of the problem, but was hoping to get some advice on figuring out > where to go digging next, or things to try. > > For context, here is what I have setup so far: I am running FreeBSD 8.2 > with IPSec support compiled into the kernel. Here's the details from uname: > > # uname -a > FreeBSD 8.2-RELEASE-p4 FreeBSD 8.2-RELEASE-p4 #2: Sun Nov 27 04:12:16 > PST 2011 i386 > > I am following what seems like a typical setup of racoon(8) and setkey(8), > and am having mpd5 handle construction of the L2TP nodes in netgraph. I can > provide the details on the configuration of each of these, if desired. When > I startup racoon in the foreground and ask mpd to construct an L2TP link, I > can see both the IPSec tunnel and the L2TP link establish without a > problem. I am able to ping the remote end, and, if I set up a routing rule, > can contact and ssh to hosts at the other end of the tunnel. > > Here's how netgraph sees the world when thing are established: > > # ngctl list > There are 13 total nodes: > Name:Type: ksocket ID: 01b3 Num hooks: 1 > Name:Type: l2tpID: 01b1 Num hooks: 3 > Name:Type: socket ID: 01b0 Num hooks: 1 > Name: ng0 Type: iface ID: 01b6 Num hooks: 1 > Name: ngctl26124 Type: socket ID: 01bd Num hooks: 0 > Name: ngctl19375 Type: socket ID: 00ba Num hooks: 0 > Name: mpd25875-stats Type: socket ID: 01b8 Num hooks: 0 > Name: mpd25875-WPLink-lt Type: tee ID: 01af Num hooks: 2 > Name: mpd25875-csoType: socket ID: 01ad Num hooks: 0 > Name: mpd25875-esoType: socket ID: 01ae Num hooks: 0 > Name: mpd25875-lsoType: socket ID: 01ac Num hooks: 1 > Name: mpd25875-WPBundle-1 Type: ppp ID: 01b7 Num hooks: > 3 > Name: ng0-tee Type: tee ID: 01b9 Num hooks: 2 > # > > The problem I have is that PF only sees traffic on the outbound side of the > netgraph interface. But, the rest of the network stack appears to see data > going both ways: > > # ifconfig ng0 > ng0: flags=88d1 metric 0 > mtu 1322 > inet 10.10.7.40 --> 10.10.0.2 netmask 0x > > # pfctl -vvs Interfaces -i ng0 > ng0 > Cleared: Sun Dec 25 21:14:44 2011 > References: [ States: 0 Rules: 9 ] > In4/Pass:[ Packets: 0 Bytes: 0 ] > In4/Block: [ Packets: 0 Bytes: 0 ] > Out4/Pass: [ Packets: Bytes: 446225 ] > Out4/Block: [ Packets: 622Bytes: 56336 ] > In6/Pass:[ Packets: 0 Bytes: 0 ] > In6/Block: [ Packets: 0 Bytes: 0 ] > Out6/Pass: [ Packets: 0 Bytes: 0 ] > Out6/Block: [ Packets: 0 Bytes: 0 ] > > # netstat -I ng0 -bn > NameMtu Network Address Ipkts Ierrs Idrop Ibytes > Opkts Oerrs Obytes Coll > ng01322 56 0 0 5069 > 98 0 6032 0 > ng01322 10.10.7.40/32 10.10.7.40 56 - - > 5069 > 54 - 3472 - > > I have stood up this interface several times, hence the differing numbers > between the PF and netstat. The cause for concern is the lack of packets > going through PF when inbound on ng0 -- no problem both seeing them and > applying rules going outbound. There isn't a peep about the inbound traffic > within pflog0, either. > > I can see traffic going both ways in tcpdump, and nothing looks peculiar > about the packets. > > # tcpdump -c 10 -i ng0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ng0, link-type NULL (BSD loopback), capture size 96 bytes > 22:06:37.201732 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [S], seq > 3442571726, win 65535, options [mss 1282,nop,wscale 3,sackOK,TS val > 694436002 ecr 0], length 0 > 22:06:37.263336 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [S.], seq > 1974232057, ack 3442571727, win 14480, options [mss 1282,sackOK,TS val > 370681934 ecr 694436002,nop,wscale 7], length 0 > 22:06:37.263577 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [.], ack 1, win > 8255, options [nop,nop,TS val 694436064 ecr 370681934], length 0 > 22:06:37.282835 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [P.], ack 1, win > 114, options [nop,nop,TS val 370681940 ecr 694436064], length 21 > 22:06:37.283931 IP 10.10.7.40.43113 > 10.10.4.
Re: Any recommendations for a 10G NIC from Broadcom
On 1/4/12 6:10 AM, Vijay Singh wrote: > Hi. I would like to try out a 10G NIC from Broadcom. The BCM5716 seems > promising. I am looking for features such as multi-queue, MSI-X, TSO > etc. Any recommendations would be greatly appreciated. > Now, I'm going to offer you an indirect response. Jack Vogel, who works at Intel, writes and maintains the code for most (all?) the Intel NICs on FreeBSD. If I had to make a choice between Broadcom and Intel, I'd go with Intel for this very reason. ___ 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: openbgpds not talking each other since 8.2-STABLE upgrade
On Wed, Jan 04, 2012 at 09:27:28AM +0100, Borja Marcos wrote:
>
> On Jan 3, 2012, at 4:29 PM, Ed Maste wrote:
>
> > Thanks for the link Nikolay.
> >
> > Borja, I assume it's the PR submission form that gave you trouble -
> > sorry for that. Based on your report it sounds to me like the bug is
> > in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option
> > though I'd assume it's due to a difference in our (FreeBSD's)
> > implementation of the option. Did you look at the OpenBSD/FreeBSD
> > differences in your investigation?
>
> I looked at OpenBGPd. By the way, I was having the same issue on the
> different FreeBSD 9 RC's I was trying.
>
> Have a look at session.c, line 148, function setup_listeners()
>
> opt = 1;
> if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG,
> &opt, sizeof(opt)) == -1) {
> if (errno == ENOPROTOOPT) { /* system w/o md5sig
> */
> log_warnx("md5sig not available, disabling");
> sysdep.no_md5sig = 1;
> } else
> fatal("setsockopt TCP_MD5SIG");
> }
>
> Seems that the function is using the setsockopt to check the
> availability of TCP_MD5.
>
> But, even though I haven't had a look at it on OpenBSD, I can make an
> educated guess:
>
> Behavior on FreeBSD: The setsockopt(TCP_MD5SIG) *enables* TCP_MD5.
> According to my packet captures, in case there's no properly set key
> with setkey(8) it will use whatever key. Look at the captures mentioned
> here:
>
> http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/ea347a919dbc165d/eeaa2965fc4f64c9?show_docid=eeaa2965fc4f64c9&pli=1
>
>
> Behavior on OpenBSD: Maybe the TCP_MD5 isn't *really* working unless
> there's a valid key associated to the socket, either using setkey(8) (I
> don't know if they use it) or via the API for setting keys.
>
>
> Whatever: Maybe FreeBSD should *ignore* that TCP_MD5SIG option for a
> socket unless (or until) a key is associated, or OpenBGPd should be
> modified so that it won't "probe" the availability of TCP_MD5SIG by
> actually setting it. Of course, if setting it for a socket is the best
> way to detect it, you can always create a temporary socket, you don't
> even need to bind() it, set TCP_MD5SIG, so that you will know if it
> succeeds or returns an error, and destroy the socket.
>
> The problem in this case is that OpenBGPd is *setting* TCP_MD5SIG on a
> socket no matter if I have configured the BGP peer with or without
> TCP_MD5. Neither Quagga nor Bird do it.
>
OpenBGPD sets the TCP_MD5SIG flag on the listening socket so that it can
be ensured that an accepted connection (SYN, SYN/ACK & first ACK) is also
protected by the TCP MD5 signature.
On startup OpenBGPD will install the necessary TCP MD5 SAs
and our network stack ensures that SAs are also matched for incomming
connections when the TCP_MD5SIG is set on the listening socket (in which
case the option is inherited to the accpeted socket).
If you can not set the TCP_MD5SIG option on listening sockets then you can
not protect and acctually accept incomming connections. A proper neighbor
would not accept the SYN/ACK sent back that does not have the MD5SIG.
How does FreeBSD avoid the chicken and egg problem of accepting
connections with MD5SIG?
--
:wq Claudio
___
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"
kernel: nd6_setmtu0: new link MTU on ng29 (1218) is too small for IPv6
Hi, I'm using a FreeBSD8.2-R-p5 in conjunction with MPD5.5 port for creating pptp/l2tp tunnels. I'm using MPPC (Compression & Encryption), my current onfiguration i use only IPv4. I keep getting in the logs the following: Jan 3 19:15:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng120 (1218) is too small for IPv6 Jan 3 20:00:40 mpd2 kernel: nd6_setmtu0: new link MTU on ng151 (1218) is too small for IPv6 Jan 3 20:09:27 mpd2 kernel: nd6_setmtu0: new link MTU on ng128 (1218) is too small for IPv6 Jan 3 20:30:13 mpd2 kernel: nd6_setmtu0: new link MTU on ng128 (1218) is too small for IPv6 Jan 3 20:34:33 mpd2 kernel: nd6_setmtu0: new link MTU on ng137 (1218) is too small for IPv6 Jan 3 21:06:46 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is too small for IPv6 Jan 3 21:42:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is too small for IPv6 Jan 3 22:12:49 mpd2 kernel: nd6_setmtu0: new link MTU on ng137 (1218) is too small for IPv6 Jan 3 23:21:50 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is too small for IPv6 Jan 4 00:00:36 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is too small for IPv6 Jan 4 00:34:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is too small for IPv6 Jan 4 07:47:37 mpd2 kernel: nd6_setmtu0: new link MTU on ng100 (1218) is too small for IPv6 Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) is too small for IPv6 Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) is too small for IPv6 Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is too small for IPv6 although the NG tunnels don't negotiate IPv6. a close look to the MPD log i see that this happens for connections that set MRU/MTU 1400. I talked to MPD developer (Alexander Motin) and this isn't a MPD problem, rather than a kernel issue as the logs say. why this problem happens when no IPv6 is in work? I don't want to disable ipv6 completely since i have plans in using it in the near future. Any help appreciated, Thanks in advance, -- Sami Halabi Information Systems Engineer NMS Projects Expert ___ 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: kernel: nd6_setmtu0: new link MTU on ng29 (1218) is too small for IPv6
Sami Halabi wrote in : so> Hi, so> I'm using a FreeBSD8.2-R-p5 in conjunction with MPD5.5 port for creating so> pptp/l2tp tunnels. so> so> I'm using MPPC (Compression & Encryption), my current onfiguration i use so> only IPv4. so> so> I keep getting in the logs the following: so> Jan 3 19:15:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng120 (1218) is so> too small for IPv6 so> Jan 3 20:00:40 mpd2 kernel: nd6_setmtu0: new link MTU on ng151 (1218) is so> too small for IPv6 so> Jan 3 20:09:27 mpd2 kernel: nd6_setmtu0: new link MTU on ng128 (1218) is so> too small for IPv6 so> Jan 3 20:30:13 mpd2 kernel: nd6_setmtu0: new link MTU on ng128 (1218) is so> too small for IPv6 so> Jan 3 20:34:33 mpd2 kernel: nd6_setmtu0: new link MTU on ng137 (1218) is so> too small for IPv6 so> Jan 3 21:06:46 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is so> too small for IPv6 so> Jan 3 21:42:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is so> too small for IPv6 so> Jan 3 22:12:49 mpd2 kernel: nd6_setmtu0: new link MTU on ng137 (1218) is so> too small for IPv6 so> Jan 3 23:21:50 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is so> too small for IPv6 so> Jan 4 00:00:36 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is so> too small for IPv6 so> Jan 4 00:34:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is so> too small for IPv6 so> Jan 4 07:47:37 mpd2 kernel: nd6_setmtu0: new link MTU on ng100 (1218) is so> too small for IPv6 so> Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) is so> too small for IPv6 so> Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) is so> too small for IPv6 so> Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is so> too small for IPv6 so> so> although the NG tunnels don't negotiate IPv6. so> so> a close look to the MPD log i see that this happens for connections that so> set MRU/MTU 1400. so> so> I talked to MPD developer (Alexander Motin) and this isn't a MPD problem, so> rather than a kernel issue as the logs say. so> so> why this problem happens when no IPv6 is in work? so> so> I don't want to disable ipv6 completely since i have plans in using it in so> the near future. It is because the end point of an L2TPv2 tunnel is implemented in MPD by using ng_iface(4), and it always has an inet6 hook when the kernel has IPv6 support (note that GENERIC kernel supports IPv6). This means an ngNNN interface is always IPv6-capable regardless of whether the tunnel supports IPv6 as the inner protocol (typically via IPV6CP in the case of L2TPv2) or not. IPv6 communication is denied when the tunnel does not support IPv6, but the interface ngNNN itself always supports IPv6. Thus, the warning you got is caused by a side-effect of IPv6 initialization of ngNNN. Since IPv6 specification requires the minimum MTU as 1280, an warning message will be displayed if you try to use a smaller MTU as the link MTU than that. You can ignore the messages safely, or increasing the MTU will suppress them. I am still wondering why the message appears when MTU is set to 1400, however. In the case of L2TPv2 over UDPv4, MTU reduction should be 46 because of encapsulation by IPv4, UDP, L2TP, and PPP. -- Hiroki pgpAkcx12UCX0.pgp Description: PGP signature
Re: kernel: nd6_setmtu0: new link MTU on ng29 (1218) is too small for IPv6
On Wed, Jan 04, 2012 at 12:59:18PM +0200, Sami Halabi wrote: S> I'm using a FreeBSD8.2-R-p5 in conjunction with MPD5.5 port for creating S> pptp/l2tp tunnels. S> S> I'm using MPPC (Compression & Encryption), my current onfiguration i use S> only IPv4. S> S> I keep getting in the logs the following: S> Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) is S> too small for IPv6 S> Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) is S> too small for IPv6 S> Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is S> too small for IPv6 S> S> although the NG tunnels don't negotiate IPv6. S> S> a close look to the MPD log i see that this happens for connections that S> set MRU/MTU 1400. S> S> I talked to MPD developer (Alexander Motin) and this isn't a MPD problem, S> rather than a kernel issue as the logs say. Message is logged by kernel, but MTU is set by userland. Can you check value of MTU with ifconfig, looking at an interface from most recent discussed message? Is it really 1218? -- Totus tuus, Glebius. ___ 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: kernel: nd6_setmtu0: new link MTU on ng29 (1218) is too small for IPv6
Hi, i just tested the last log: %tail /var/log/messages Jan 3 23:21:50 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is too small for IPv6 Jan 4 00:00:36 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is too small for IPv6 Jan 4 00:34:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is too small for IPv6 Jan 4 07:47:37 mpd2 kernel: nd6_setmtu0: new link MTU on ng100 (1218) is too small for IPv6 Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) is too small for IPv6 Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) is too small for IPv6 Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is too small for IPv6 Jan 4 14:17:34 mpd2 kernel: nd6_setmtu0: new link MTU on ng120 (1218) is too small for IPv6 %ifconfig ng120 ng120: flags=88d1 metric 0 mtu 1218 inet 188.64.96.5 --> 188.64.102.171 netmask 0x so MTU is indeed 1218 Sami 2012/1/4 Gleb Smirnoff > On Wed, Jan 04, 2012 at 12:59:18PM +0200, Sami Halabi wrote: > S> I'm using a FreeBSD8.2-R-p5 in conjunction with MPD5.5 port for creating > S> pptp/l2tp tunnels. > S> > S> I'm using MPPC (Compression & Encryption), my current onfiguration i use > S> only IPv4. > S> > S> I keep getting in the logs the following: > S> Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) > is > S> too small for IPv6 > S> Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) > is > S> too small for IPv6 > S> Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is > S> too small for IPv6 > S> > S> although the NG tunnels don't negotiate IPv6. > S> > S> a close look to the MPD log i see that this happens for connections that > S> set MRU/MTU 1400. > S> > S> I talked to MPD developer (Alexander Motin) and this isn't a MPD > problem, > S> rather than a kernel issue as the logs say. > > Message is logged by kernel, but MTU is set by userland. Can you check > value of MTU with ifconfig, looking at an interface from most recent > discussed message? Is it really 1218? > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert ___ 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: kernel: nd6_setmtu0: new link MTU on ng29 (1218) is too small for IPv6
On 4. Jan 2012, at 12:11 , Sami Halabi wrote: > Hi, > i just tested the last log: > %tail /var/log/messages > Jan 3 23:21:50 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is > too small for IPv6 > Jan 4 00:00:36 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is > too small for IPv6 > Jan 4 00:34:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is > too small for IPv6 > Jan 4 07:47:37 mpd2 kernel: nd6_setmtu0: new link MTU on ng100 (1218) is > too small for IPv6 > Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) is > too small for IPv6 > Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) is > too small for IPv6 > Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is > too small for IPv6 > Jan 4 14:17:34 mpd2 kernel: nd6_setmtu0: new link MTU on ng120 (1218) is > too small for IPv6 > %ifconfig ng120 > ng120: flags=88d1 metric 0 > mtu 1218 >inet 188.64.96.5 --> 188.64.102.171 netmask 0x > > so MTU is indeed 1218 But that MTU should be a result of ppp/LCP negotiations of individual sessions. It seems you have peers thinking they want a really small MTU and you allow it? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Transitioning if_addr_lock to an rwlock
On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote: > On 29. Dec 2011, at 20:27 , John Baldwin wrote: >> I've gone ahead with this approach. I have three separate patches that >> should >> implement Phase 1. All of them can be found at >> http://www.FreeBSD.org/~jhb/patches/ >> >> - if_addr_dev.patch This fixes a few new device drivers that were using >>the locking macros directly rather than the wrapper >>functions Robert added. I've already sent this >>directly to the relevant driver maintainers for their >>review. >> - if_addr_macros.patch This adds new locking macros to support read locks >> vs >>write locks. However, they all still map to mutex >>operations. > > The first two look good. I wondered why you didn't need the > r-wraper-functions > but obviously they had been named like that already:) > > > I'll look at the one below in more detail and get back to you. > >> - if_addr_uses.patch This changes callers of the existing macros to use >>either read or write locks. This is the patch that >>could use the most review. I went through this one as well. I skipped mld6.c, in6.c, igmp.c and in.c as they need to be regenerated. in nd6_rtr.c/prelist_update I think we are lacking an ifa_ref() dance currently but that's unrelated. The other conversions to R/W locking seemed ok. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Any recommendations for a 10G NIC from Broadcom
On Wednesday, January 04, 2012 4:31:00 am Damien Fleuriot wrote: > On 1/4/12 6:10 AM, Vijay Singh wrote: > > Hi. I would like to try out a 10G NIC from Broadcom. The BCM5716 seems > > promising. I am looking for features such as multi-queue, MSI-X, TSO > > etc. Any recommendations would be greatly appreciated. > > > > > Now, I'm going to offer you an indirect response. > > Jack Vogel, who works at Intel, writes and maintains the code for most > (all?) the Intel NICs on FreeBSD. > > If I had to make a choice between Broadcom and Intel, I'd go with Intel > for this very reason. OTOH, Broadcom also has a commiter on staff who helps to maintain FreeBSD drivers (David Christensen - davidch@). There is a bxe(4) driver in 9.0 and later (albeit missing a manpage) which supports some Broadcom 10G NICs: BCM57710, BCM57711, and BCM57711E. -- John Baldwin ___ 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: openbgpds not talking each other since 8.2-STABLE upgrade
> You are setting the keys with setkey for both directions of a single session, > right? > i.e.: > > add X.X.X.X Y.Y.Y.Y tcp 0x1000 -A tcp-md5 "SomePass"; > add Y.Y.Y.Y X.X.X.X tcp 0x1000 -A tcp-md5 "SomePass"; > > As before it was only needed to set the "outgoing" direction key, which > should not work anymore unless > net.inet.tcp.signature_verify_input is zero. Are you sure? I have net.inet.tcp.signature_verify_input = 1 and only one line in /etc/ipsec.conf for each BGP session using MD5 keys, on 8.2-STABLE. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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: Transitioning if_addr_lock to an rwlock
On 4. Jan 2012, at 12:45 , Bjoern A. Zeeb wrote: > > On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote: > >> On 29. Dec 2011, at 20:27 , John Baldwin wrote: >>> I've gone ahead with this approach. I have three separate patches that >>> should >>> implement Phase 1. All of them can be found at >>> http://www.FreeBSD.org/~jhb/patches/ >>> >>> - if_addr_dev.patch This fixes a few new device drivers that were using >>> the locking macros directly rather than the wrapper >>> functions Robert added. I've already sent this >>> directly to the relevant driver maintainers for their >>> review. >>> - if_addr_macros.patch This adds new locking macros to support read locks >>> vs >>> write locks. However, they all still map to mutex >>> operations. >> >> The first two look good. I wondered why you didn't need the >> r-wraper-functions >> but obviously they had been named like that already:) >> >> >> I'll look at the one below in more detail and get back to you. >> >>> - if_addr_uses.patch This changes callers of the existing macros to use >>> either read or write locks. This is the patch that >>> could use the most review. > > I went through this one as well. > > I skipped mld6.c, in6.c, igmp.c and in.c as they need to be regenerated. > in nd6_rtr.c/prelist_update I think we are lacking an ifa_ref() dance > currently but that's unrelated. The other conversions to R/W locking > seemed ok. The other 4 seem ok in the regen'ed version though I didn't fully check all RLOCKs into called functions in the two multicast ones. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Transitioning if_addr_lock to an rwlock
On Wednesday, January 04, 2012 7:45:26 am Bjoern A. Zeeb wrote: > > On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote: > > > On 29. Dec 2011, at 20:27 , John Baldwin wrote: > >> I've gone ahead with this approach. I have three separate patches that > >> should > >> implement Phase 1. All of them can be found at > >> http://www.FreeBSD.org/~jhb/patches/ > >> > >> - if_addr_dev.patch This fixes a few new device drivers that were > >> using > >>the locking macros directly rather than the wrapper > >>functions Robert added. I've already sent this > >>directly to the relevant driver maintainers for > >> their > >>review. > >> - if_addr_macros.patch This adds new locking macros to support read > >> locks vs > >>write locks. However, they all still map to mutex > >>operations. > > > > The first two look good. I wondered why you didn't need the > > r-wraper-functions > > but obviously they had been named like that already:) > > > > > > I'll look at the one below in more detail and get back to you. > > > >> - if_addr_uses.patch This changes callers of the existing macros to use > >>either read or write locks. This is the patch that > >>could use the most review. > > I went through this one as well. > > I skipped mld6.c, in6.c, igmp.c and in.c as they need to be regenerated. > in nd6_rtr.c/prelist_update I think we are lacking an ifa_ref() dance > currently but that's unrelated. The other conversions to R/W locking > seemed ok. if_addr_uses.patch is now updated. I think prelist_update is fine because i doesn't actually use the memory referenced by the one pointer it uses after dropping the IF_ADDR_LOCK. It merely checks it against NULL to see if it found anything useful. For that case no reference count is needed. -- John Baldwin ___ 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: Extending sys/dev/mii
I'm including -net here so we can try and pull in further feedback from network-cluey people. On 4 January 2012 08:03, Stefan Bethke wrote: > As discussed recently, ray@, adrian@ and myself are trying to get a framework > and utility into the tree that allows the use and configuration of ethernet > switch chips. The switch controllers we've looked at so far share a number > of features, in particular they use 802.3 MII, MDIO and PHYs to implement and > configure the ports they offer. In addition to being a switch, some of them > also offer one of the built-in PHYs to the ethernet controller as a classical > PHY. [snip] > I'd like to extend miibus in such a way that the one-to-one mapping between > MDIO and MII is broken up. For that, I propose to add a new bus driver > "mdiobus" (with appropriate resource management) that uses methods similar to > miibus_if.m readreg and writereg to access an ethernet controllers' MDIO > master. miibus then attaches to it as a child, claims one or more PHY > addresses and attaches PHYs to itself (as currently implemented). This sounds like a good idea. I wonder what's stopping us from doing that. :) > There's one issue that I don't have a proposal for yet: in one platform > (AR7241), we have PHY4 of the SoC talking via MII to arge0's MAC, while it is > being controlled via the switch controller's MDIO master, and the switch > controller being attached to arge1's MDIO. If we want to attach an miibus > for PHY4, we'd have to defer attachment of arge0 until arge1 has been probed > and can provide the MDIO attachment (and transitively the switch and it's > mdio). Note that we also have boards without a switch, but the two PHYs > still being attached to only a single MDIO. One possible way would be for > the MDIO driver to be separate from the ethernet driver, so that the normal > newbus dependency resolution can be used to ensure that mdio1 is attached > before arge0 is probed. For the time being, I've worked around this through > hackery in if_arge.c. juli@ proposed something quite similar a few weeks ago. Now that I'm a little more clued up on this whole area, I now understand why she suggested it. I'm happy with "hacky" being in if_arge for now (I mean, there already _is_ ..) but this work seems like the right path to take to bring sanity to this whole setup in the longer term. Thanks for tackling this! Adrian ___ 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: Any recommendations for a 10G NIC from Broadcom
On Tue, Jan 03, 2012 at 09:10:20PM -0800, Vijay Singh wrote: > Hi. I would like to try out a 10G NIC from Broadcom. The BCM5716 seems > promising. I am looking for features such as multi-queue, MSI-X, TSO > etc. Any recommendations would be greatly appreciated. > > -vijay > > PS: I'd be using FreeBSD 8.2 initially, and FreeBSD 9.x in a few months. AFAIK BCM5716 is a gigabit ethernet and bce(4) supports the controller. bce(4) lacks multi-queue support but all other hardware features are supported. Enabling multi-queue for both bce(4) and bge(4) is one of my TODO list but I couldn't find spare time to do that. As John said, bxe(4) supports Broadcom's 10G controllers, BCM5771x. The driver supports all hardware features you mentioned(including multi-queue through RSS/TSS). Unlike most other 10G controllers, these controllers support hardware based true LRO which would outperform software based implementation. bxe(4) is not available on 8.x yet. ___ 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"
