Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/162558 net[dummynet] [panic] seldom dummynet panics o kern/162509 net[re] [panic] Kernel panic may be related to if_re.c (r o kern/162352 net[patch] Enhancement: add SO_PROTO to socket.h o kern/162201 net[ip] [patch] multicast forwarding cache hash always al o kern/162153 net[em] intel em driver 7.2.4 don't compile o kern/162110 net[igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net[ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161908 net[netgraph] [patch] ng_vlan update for QinQ support o kern/161899 net[route] ntpd(8): Repeating RTM_MISS packets causing hi o kern/161381 net[re] RTL8169SC - re0: PHY write failed o kern/161277 net[em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net[igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 netIntel PRO/1000 connection breaks under load until rebo o kern/160693 net[gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net[msk] phy write timeout on HP 5310m o kern/160293 net[ieee80211] ppanic] kernel panic during network setup o kern/160206 net[gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net[udp] write UDPv4: No buffer space available (code=55) o kern/159795 net[tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net[ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net[tcp] [panic] panic: soabort: so_count o kern/159603 net[netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net[netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net[em] em watchdog timeouts o kern/159203 net[wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net[bpf] BPF element leak in ifp-bpf_if-bif_dlist o kern/158726 net[ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net[ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net[ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net[em] TSO breaks BPF packet captures with em driver f kern/157802 net[dummynet] [panic] kernel panic in dummynet o kern/157785 netamd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net[re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net[em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net[ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net[re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net[ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net[network.subr] [patch] stf(4) can not communicate betw o kern/157182 net[lagg] lagg interface not working together with epair o kern/156877 net[dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net[em] em0 fails to init on CURRENT after March 17 o kern/156408 net[vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net[icmp]: host can ping other subnet but no have IP from o kern/156317 net[ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net[ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net[if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net[lagg]: failover does not announce the failover to swi o kern/156030 net[ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 netifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net[multicast] problems with multicast s kern/155642 net[request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net[flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net[panic] Kernel panics with sbdrop message o kern/155420 net[vlan] adding vlan break existent vlan o kern/155177 net[route] [panic] Panic when inject routes in kernel o kern/155030 net[igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net[msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net[bce] [panic] kernel panic in bce0 driver o kern/154943 net[gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net[request]: Port brcm80211 driver from Linux to FreeBSD o
Re: FreeBSD 9 and ARP multicast source address error messages
Alexander, On Thu, Nov 10, 2011 at 12:42:15PM -0500, Alexander Wittig wrote: A Can you try attached patch. It reduces severity level of all ARP A messages, that can be triggered by packet on network, with expection to A using my IP address. A A With default syslog.conf, now ARP errors won't get to console. A A Also, the multicast message lacked \n newline character, that's why, A I suppose, syslogd failed to coalesce a number of messages into a single A entry last message repeated X times. A A Thank you very much for the patch, and for making this particular message a bit more helpful by including the MAC address. A I tried it and indeed it stops the messages from going to the console. But the default syslog.conf still logs each one in /var/log/messages and they also show up in dmsg output. These happen quite frequently, so even on a not so busy network they will drown out almost everything else going on in dmsg or /var/log/messages. Unfortunately, having two (or more) different machines use these will prevent syslogd from combining messages into last message repeated X times: A A /var/log/messages: A [...] A Nov 10 12:23:44 bt kernel: in_arp: 03:bf:23:09:44:e4 is multicast A Nov 10 12:23:44 bt kernel: in_arp: 03:bf:23:09:44:87 is multicast A Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:e4 is multicast A Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:87 is multicast A [...] Okay, I will apply patch. A I'm not an expert on networking, but is this condition of ignoring such an ARP packet really a noteworthy event? I.e. is this something that should not occur in normal operation according to the ARP specifications? If this is mostly for kernel developers, maybe it should only be enabled in debug kernel builds? Nope, this isn't for kernel developers only but for sysadmins. Some bad traffic is present in your network, and it should be noticed by sysadmin, that's why LOG_NOTICE severity left. However, I understand how annoying it is when you are in a bad network, you don't admin it, you can't fix it and your logging system is too chatty. I am thinking of some generic way of supperssing or ratelimiting all logged events that can be triggered by host on LAN or even by remote host. -- 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
Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration
(Sent to freebsd-bugs as well, copied here for discussion, if needed)
Sorry for the brief report and the scarce details. The fing form insists on
rejecting the captcha after one hour writing a report.
So, in short:
If TCP_MD5 is available on the system,
options IPSEC
options TCP_SIGNATURE #include support for RFC 2385
devicecrypto
Turns out openbgpd can't receive BGP connections.
The error is in the session.c file, line 148, function setup_listeners(u_int
*la_cnt).
Code snippet:
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);
}
This is wrong. Regardless of the configuration, this code activates TCP_MD5 for
the socket and leaves it enabled. This is what happens:
14:04:33.009212 IP 10.0.0.2.36610 10.0.0.1.179: Flags [S], seq 1941690122,
win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 115224 ecr 0], length 0
14:04:33.009267 IP 10.0.0.1.179 10.0.0.2.36610: Flags [S.], seq 2935503211,
ack 1941690123, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val
4192648161 ecr 115224,nop,nop,md5shared secret not supplied with -M, can't
check - a360f2c9a9f96a582ccbabe79418105c], length 0
The daemon receiving the connection is replying with TCP_MD5, even though
there's no TCP_MD5 option set in the bgpd.conf file.
Removing this code (or placing it outside of the loop, creating a temporary
socket just to enable TCP_MD5 on it and using it to detect the availability of
TCP_MD5) works:
14:04:35.395447 IP 10.0.0.1.45119 10.0.0.2.179: Flags [S], seq 366635408, win
65535, options [mss 1460,nop,wscale 6,sackOK,TS val 220116 ecr 0], length 0
14:04:35.395490 IP 10.0.0.2.179 10.0.0.1.45119: Flags [S.], seq 1226417253,
ack 366635409, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val
511187362 ecr 220116], length 0
14:04:35.395584 IP 10.0.0.1.45119 10.0.0.2.179: Flags [.], ack 1, win 1040,
options [nop,nop,TS val 220116 ecr 511187362], length 0
14:04:35.396072 IP 10.0.0.1.45119 10.0.0.2.179: Flags [P.], seq 1:46, ack 1,
win 1040, options [nop,nop,TS val 220116 ecr 511187362], length 45: BGP,
length: 45
14:04:35.397031 IP 10.0.0.2.179 10.0.0.1.45119: Flags [P.], seq 1:50, ack 46,
win 1040, options [nop,nop,TS val 511187362 ecr 220116], length 49: BGP,
length: 49
14:04:35.397381 IP 10.0.0.1.45119 10.0.0.2.179: Flags [P.], seq 46:65, ack
50, win 1040, options [nop,nop,TS val 220116 ecr 511187362], length 19: BGP,
length: 19
Sorry for the terse report. It was very detailed, but lost.
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
[PATCH] ndis: safe fpu on amd64
Hi,
This patch should fix panic on amd64 when using ndis with drivers
which make use of fpu registers.
diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c
index 5572988..1a93b54 100644
--- a/sys/compat/ndis/kern_windrv.c
+++ b/sys/compat/ndis/kern_windrv.c
@@ -55,6 +55,9 @@ __FBSDID($FreeBSD$);
#ifdef __i386__
#include machine/segments.h
#endif
+#ifdef __amd64__
+#include machine/fpu.h
+#endif
#include dev/usb/usb.h
@@ -613,6 +616,86 @@ windrv_wrap(func, wrap, argcnt, ftype)
return (0);
}
+
+uint64_t
+_x86_64_call1(void *fn, uint64_t a)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call1(fn, a);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
+
+uint64_t
+_x86_64_call2(void *fn, uint64_t a, uint64_t b)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call2(fn, a, b);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
+
+uint64_t
+_x86_64_call3(void *fn, uint64_t a, uint64_t b, uint64_t c)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call3(fn, a, b, c);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
+
+uint64_t
+_x86_64_call4(void *fn, uint64_t a, uint64_t b, uint64_t c, uint64_t d)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call4(fn, a, b, c, d);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
+
+uint64_t
+_x86_64_call5(void *fn, uint64_t a, uint64_t b, uint64_t c, uint64_t d,
+uint64_t e)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call5(fn, a, b, c, d, e);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
+
+uint64_t
+_x86_64_call6(void *fn, uint64_t a, uint64_t b, uint64_t c, uint64_t d,
+uint64_t e, uint64_t f)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call6(fn, a, b, c, d, e, f);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
#endif /* __amd64__ */
diff --git a/sys/compat/ndis/pe_var.h b/sys/compat/ndis/pe_var.h
index 84e0162..276ad1c 100644
--- a/sys/compat/ndis/pe_var.h
+++ b/sys/compat/ndis/pe_var.h
@@ -460,22 +460,29 @@ extern uint64_t x86_64_call5(void *, uint64_t, uint64_t, uint64_t, uint64_t,
extern uint64_t x86_64_call6(void *, uint64_t, uint64_t, uint64_t, uint64_t,
uint64_t, uint64_t);
-
-#define MSCALL1(fn, a) \
- x86_64_call1((fn), (uint64_t)(a))
-#define MSCALL2(fn, a, b) \
- x86_64_call2((fn), (uint64_t)(a), (uint64_t)(b))
-#define MSCALL3(fn, a, b, c) \
- x86_64_call3((fn), (uint64_t)(a), (uint64_t)(b), \
- (uint64_t)(c))
-#define MSCALL4(fn, a, b, c, d) \
- x86_64_call4((fn), (uint64_t)(a), (uint64_t)(b), \
+uint64_t _x86_64_call1(void *, uint64_t);
+uint64_t _x86_64_call2(void *, uint64_t, uint64_t);
+uint64_t _x86_64_call3(void *, uint64_t, uint64_t, uint64_t);
+uint64_t _x86_64_call4(void *, uint64_t, uint64_t, uint64_t, uint64_t);
+uint64_t _x86_64_call5(void *, uint64_t, uint64_t, uint64_t, uint64_t,
+uint64_t);
+uint64_t _x86_64_call6(void *, uint64_t, uint64_t, uint64_t, uint64_t,
+uint64_t, uint64_t);
+
+#define MSCALL1(fn, a) \
+ _x86_64_call1((fn), (uint64_t)(a))
+#define MSCALL2(fn, a, b) \
+ _x86_64_call2((fn), (uint64_t)(a), (uint64_t)(b))
+#define MSCALL3(fn, a, b, c) \
+ _x86_64_call3((fn), (uint64_t)(a), (uint64_t)(b), (uint64_t)(c))
+#define MSCALL4(fn, a, b, c, d) \
+ _x86_64_call4((fn), (uint64_t)(a), (uint64_t)(b), \
(uint64_t)(c), (uint64_t)(d))
-#define MSCALL5(fn, a, b, c, d, e)\
- x86_64_call5((fn), (uint64_t)(a), (uint64_t)(b), \
+#define MSCALL5(fn, a, b, c, d, e) \
+ _x86_64_call5((fn), (uint64_t)(a), (uint64_t)(b), \
(uint64_t)(c), (uint64_t)(d), (uint64_t)(e))
-#define MSCALL6(fn, a, b, c, d, e, f)\
- x86_64_call6((fn), (uint64_t)(a), (uint64_t)(b), \
+#define MSCALL6(fn, a, b, c, d, e, f) \
+ _x86_64_call6((fn), (uint64_t)(a), (uint64_t)(b), \
(uint64_t)(c), (uint64_t)(d), (uint64_t)(e), (uint64_t)(f))
#endif /* __amd64__ */
___
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
Restarting Network Services Without Rebooting
(Apologies for the incorrect post to mailing.freebsd.questions newsgroup :( ) Hello, Occasionally I'm disconnected from my cable ISP (Virginmedia) which is making me wonder whether or not it's my fault most of the time or just occasional 'glitches' with the cable connection. I have a FreeBSD 8.2 firewall/router box (a Pentium 4 2.8GHz PC clone) which has two NICs installed. PF is running on this box. I've recently added the following two rules to my /etc/pf.conf in order to help with DHCP allocations. pass in quick log (all) on $ext_if inet proto tcp from any port 67:68 to any port 67:68 keep state flags S/SA pass in quick log (all) on $ext_if inet proto udp from any port 67:68 to any port 67:68 keep state I have to say that 90% of the time this firewall/router box runs flawlessly. The above DHCP 'additions' to the /etc/pf.conf have only been made today so time will tell whether there's any noticeable difference. Today I had another outage (before the firewall DHCP additions were made) and I got to thinking about how I could restart the network services on my firewall/router box without rebooting the machine itself. After some searching I found the following commands which didn't produce any errors, but I was left with no IP address assigned to my Internet- facing NIC ($ext_if, which is actually 'sis0'). /etc/rc.d/netif restart /etc/rc.d/routing restart If I reboot this machine it *always* configures the network correctly, providing that there's no problem with the ISP's connection. Does anyone know what I'm doing wrong here ? Are there more or fewer commands needed to simulate the effect a reboot of a FreeBSD 8.2 box would have on general networking ? Should I have included /etc/rc.d/dhclient in the above command line as well ? Thanks for your time. Regards, Pete. smime.p7s Description: S/MIME cryptographic signature
