Re: Kernel panic on FreeBSD 9.0-beta2
On Fri, Sep 30, 2011 at 9:41 PM, Robert Watson wrote: > > On Wed, 28 Sep 2011, Mikolaj Golub wrote: > >> On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: >> >> KM> Sorry, didn't look at the images (limited bw), I've seen something KM> >> like this before in timewait. This "can't happen" with UDP so will be KM> >> interested in learning more about the bug. >> >> The panic can be easily triggered by this: > > Hi: > > Just catching up on this thread. I think the analysis here is generally > right: in 9.0, you're much more likely to see an inpcb with its in_socket > pointer cleared in the hash list than in prior releases, and > in_pcbbind_setup() trips over this. > > However, at least on first glance (and from the perspective of invariants > here), I think the bug is actualy that in_pcbbind_setup() is asking > in_pcblookup_local() for an inpcb and then access the returned inpcb's > in_socket pointer without acquiring a lock on the inpcb. Structurally, it > can't acquire this lock for lock order reasons -- it already holds the lock > on its own inpcb. Therefore, we should only access fields that are safe to > follow in an inpcb when you hold a reference via the hash lock and not a > lock on the inpcb itself, which appears generally OK (+/-) for all the > fields in that clause but the t->inp_socket->so_options dereference. > > A preferred fix would cache the SO_REUSEPORT flag in an inpcb-layer field, > such as inp_flags2, giving us access to its value without having to walk > into the attached (or not) socket. > > This raises another structural question, which is whether we need a new > inp_foo flags field that is protected explicitly by the hash lock, and not > by the inpcb lock, which could hold fields relevant to address binding. I > don't think we need to solve that problem in this context, as a slightly > race on SO_REUSEPORT is likely acceptable. > > The suggested fix does perform the desired function of explicitly detaching > the inpcb from the hash list before the socket is disconnected from the > inpcb. However, it's incomplete in that the invariant that's being broken is > also relied on for other protocols (such as raw sockets). The correct > invariant is that inp_socket is safe to follow unconditionally if an inpcb > is locked and INP_DROPPED isn't set -- the bug is in "locked" not in > "INP_DROPPED", which is why I think this is the wrong fix, even though it > prevents a panic :-). Hello Robert, Thank you for taking your valuable time to find out the problem. Since I don't have idea about network internals, would you have a patch about this? I'd be glad to test it, thanks again. > Robert Best regards, Dave. ___ 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: ipfw - accessing DMZ from LAN
On Fri, Sep 30, 2011 at 7:57 AM, Marek Salwerowicz wrote: > W dniu 2011-09-29 23:07, Marek Salwerowicz pisze: > > So eg. the rules specifying traffic between DMZ Host and LAN could be the >> first, and then rules for "generic" DMZ host traffic (allowing DMZ access to >> the Internet)? >> So far I made like this (first DMZ-LAN, then DMZ), but I have some >> problem: >> >> ipfw add 200 divert $DMZHOST1PORT ip from $DMZHOST1 to any in recv $DMZIF >> ipfw add 205 allow ip from $DMZHOST1 to any in recv $DMZIF >> >> ipfw add 210 divert $DMZHOST1PORT ip from $DMZHOST1 to any out xmit >> $PUBLICIF >> ipfw add 215 allow ip from $DMZHOST1PUB to any out xmit $PUBLICIF >> >> ipfw add 220 divert $DMZHOST1PORT ip from any to $DMZHOST1PUB in recv >> $PUBLICIF >> ipfw add 225 allow ip from any to $DMZHOST1 in recv $PUBLICIF >> >> ipfw add 230 divert $DMZHOST1PORT ip from any to $DMZHOST1 out xmit $DMZIF >> ipfw add 235 allow ip from any to $DMZHOST1 out xmit $DMZIF >> >> The DMZ host has access to Internet (and is visible as public IP dedicated >> for that host, so it's what I wanted), but when I connect from the Internet >> to DMZ host (eg. ssh), I see that the connection comes from itself (DMZ host >> public IP), instead of real public IP address. >> I think that I've overNATed something. >> >> I've answered myself: > > > ipfw add 205 allow ip from $DMZHOST1 to any in recv $DMZIF > > ipfw add 210 divert $DMZHOST1PORT ip from $DMZHOST1 to any out xmit > $PUBLICIF > ipfw add 215 allow ip from $DMZHOST1PUB to any out xmit $PUBLICIF > > ipfw add 220 divert $DMZHOST1PORT ip from any to $DMZHOST1PUB in recv > $PUBLICIF > ipfw add 225 allow ip from any to $DMZHOST1 in recv $PUBLICIF > > > > ipfw add 235 allow ip from any to $DMZHOST1 out xmit $DMZIF > > So I just removed rules responsible for NAT at $DMZIF and left only NAT at > $PUBLICIF. > > But now there is next problem - when I try to ping /ssh from router to > $DMZPUBLICIP, I connect to myself, instead of DMZ host.. > > I'm guessing the router is the FreeBSD box running IPFW? If so, then that's the correct behaviour, as the public IPs are physically assigned to the interfaces on the router. Thus, connecting to the public IPs from the router ... will connect to the router. You need to ping the private IPs from the router, since the router is directly connected to the private networks. -- Freddie Cash fjwc...@gmail.com ___ 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: ipfw - accessing DMZ from LAN
W dniu 2011-09-29 23:07, Marek Salwerowicz pisze: So eg. the rules specifying traffic between DMZ Host and LAN could be the first, and then rules for "generic" DMZ host traffic (allowing DMZ access to the Internet)? So far I made like this (first DMZ-LAN, then DMZ), but I have some problem: ipfw add 200 divert $DMZHOST1PORT ip from $DMZHOST1 to any in recv $DMZIF ipfw add 205 allow ip from $DMZHOST1 to any in recv $DMZIF ipfw add 210 divert $DMZHOST1PORT ip from $DMZHOST1 to any out xmit $PUBLICIF ipfw add 215 allow ip from $DMZHOST1PUB to any out xmit $PUBLICIF ipfw add 220 divert $DMZHOST1PORT ip from any to $DMZHOST1PUB in recv $PUBLICIF ipfw add 225 allow ip from any to $DMZHOST1 in recv $PUBLICIF ipfw add 230 divert $DMZHOST1PORT ip from any to $DMZHOST1 out xmit $DMZIF ipfw add 235 allow ip from any to $DMZHOST1 out xmit $DMZIF The DMZ host has access to Internet (and is visible as public IP dedicated for that host, so it's what I wanted), but when I connect from the Internet to DMZ host (eg. ssh), I see that the connection comes from itself (DMZ host public IP), instead of real public IP address. I think that I've overNATed something. I've answered myself: ipfw add 205 allow ip from $DMZHOST1 to any in recv $DMZIF ipfw add 210 divert $DMZHOST1PORT ip from $DMZHOST1 to any out xmit $PUBLICIF ipfw add 215 allow ip from $DMZHOST1PUB to any out xmit $PUBLICIF ipfw add 220 divert $DMZHOST1PORT ip from any to $DMZHOST1PUB in recv $PUBLICIF ipfw add 225 allow ip from any to $DMZHOST1 in recv $PUBLICIF ipfw add 235 allow ip from any to $DMZHOST1 out xmit $DMZIF So I just removed rules responsible for NAT at $DMZIF and left only NAT at $PUBLICIF. But now there is next problem - when I try to ping /ssh from router to $DMZPUBLICIP, I connect to myself, instead of DMZ host.. ___ 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 panic on FreeBSD 9.0-beta2
On Wed, 28 Sep 2011, Mikolaj Golub wrote: On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: KM> Sorry, didn't look at the images (limited bw), I've seen something KM> like this before in timewait. This "can't happen" with UDP so will be KM> interested in learning more about the bug. The panic can be easily triggered by this: Hi: Just catching up on this thread. I think the analysis here is generally right: in 9.0, you're much more likely to see an inpcb with its in_socket pointer cleared in the hash list than in prior releases, and in_pcbbind_setup() trips over this. However, at least on first glance (and from the perspective of invariants here), I think the bug is actualy that in_pcbbind_setup() is asking in_pcblookup_local() for an inpcb and then access the returned inpcb's in_socket pointer without acquiring a lock on the inpcb. Structurally, it can't acquire this lock for lock order reasons -- it already holds the lock on its own inpcb. Therefore, we should only access fields that are safe to follow in an inpcb when you hold a reference via the hash lock and not a lock on the inpcb itself, which appears generally OK (+/-) for all the fields in that clause but the t->inp_socket->so_options dereference. A preferred fix would cache the SO_REUSEPORT flag in an inpcb-layer field, such as inp_flags2, giving us access to its value without having to walk into the attached (or not) socket. This raises another structural question, which is whether we need a new inp_foo flags field that is protected explicitly by the hash lock, and not by the inpcb lock, which could hold fields relevant to address binding. I don't think we need to solve that problem in this context, as a slightly race on SO_REUSEPORT is likely acceptable. The suggested fix does perform the desired function of explicitly detaching the inpcb from the hash list before the socket is disconnected from the inpcb. However, it's incomplete in that the invariant that's being broken is also relied on for other protocols (such as raw sockets). The correct invariant is that inp_socket is safe to follow unconditionally if an inpcb is locked and INP_DROPPED isn't set -- the bug is in "locked" not in "INP_DROPPED", which is why I think this is the wrong fix, even though it prevents a panic :-). Robert ___ 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: when enable options SCTP_DEBUG in kernel configure file , where to get the message of debug?
On Sep 30, 2011, at 11:48 AM, jyl wrote: > My Os is FreeBSD 9.0 Beta2. > In kernel configure file, I enable the option of SCTP_DEBUG and rebuild the > kernel. Then I use sctp to send or recv data from another computer ,after > that I check the result from var/log/message or var/log/dmesg , both of the > two files show any message about sctp debug. > > can anyone help me, why it does not work? There is a sysctl variable net.inet.sctp.debug which is a 32-bit bitmask to enable/disable the debug output. To enable all debug output you need to do sudo sysctl -w net.inet.sctp.debug=0x Best regards Michael > > Regards. > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/when-enable-options-SCTP-DEBUG-in-kernel-configure-file-where-to-get-the-message-of-debug-tp4856441p4856441.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: when enable options SCTP_DEBUG in kernel configure file , where to get the message of debug?
On 30 September 2011 13:48, jyl wrote: > My Os is FreeBSD 9.0 Beta2. > In kernel configure file, I enable the option of SCTP_DEBUG and rebuild the > kernel. Then I use sctp to send or recv data from another computer ,after > that I check the result from var/log/message or var/log/dmesg , both of the > two files show any message about sctp debug. > > can anyone help me, why it does not work? > Hi, you probably also need to actually enable it. Try this: sysctl net.inet.sctp.debug = 1 -- wbr, pluknet ___ 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"
when enable options SCTP_DEBUG in kernel configure file , where to get the message of debug?
My Os is FreeBSD 9.0 Beta2. In kernel configure file, I enable the option of SCTP_DEBUG and rebuild the kernel. Then I use sctp to send or recv data from another computer ,after that I check the result from var/log/message or var/log/dmesg , both of the two files show any message about sctp debug. can anyone help me, why it does not work? Regards. -- View this message in context: http://freebsd.1045724.n5.nabble.com/when-enable-options-SCTP-DEBUG-in-kernel-configure-file-where-to-get-the-message-of-debug-tp4856441p4856441.html Sent from the freebsd-net mailing list archive at Nabble.com. ___ 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: IPv6 multicast listener discovery
> Could you show us more specifics about your configuration and packet > dump in question? Yes! It's the FreeBSD 8.2 release. The only thing which is activated in the rc.conf is ipv6. I've included the ifconfig output and a wireshark capture. The capture is taken during the startup of the FreeBSD system. I would like to know where the address ff02::2:2d75:f2b8 comes from. --- ifconfig -mL plip0: flags=8810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 options=3 capabilities=3 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 nd6 options=3 rl0: flags=8843 metric 0 mtu 1500 options=3808 capabilities=3808 ether 00:50:fc:b8:54:43 inet6 fe80::250:fcff:feb8:5443%rl0 prefixlen 64 scopeid 0x3 inet 192.168.10.75 netmask 0xff00 broadcast 192.168.10.255 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active supported media: media autoselect media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP media 100baseTX mediaopt hw-loopback --- wireshark capture No. Time Source Destination Protocol Info 1 0.00 :: ff02::16 ICMPv6 Multicast Listener Report Message v2 Frame 1: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) Arrival Time: Sep 29, 2011 09:11:06.785821000 UTC Epoch Time: 1317287466.785821000 seconds [Time delta from previous captured frame: 0.0 seconds] [Time delta from previous displayed frame: 0.0 seconds] [Time since reference or first frame: 0.0 seconds] Frame Number: 1 Frame Length: 90 bytes (720 bits) Capture Length: 90 bytes (720 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ipv6:icmpv6] [Coloring Rule Name: ICMP] [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43), Dst: IPv6mcast_00:00:00:16 (33:33:00:00:00:16) Destination: IPv6mcast_00:00:00:16 (33:33:00:00:00:16) Address: IPv6mcast_00:00:00:16 (33:33:00:00:00:16) ...1 = IG bit: Group address (multicast/broadcast) ..1. = LG bit: Locally administered address (this is NOT the factory default) Source: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43) Address: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: :: (::), Dst: ff02::16 (ff02::16) 0110 = Version: 6 [0110 = This field makes the filter "ip.version == 6" possible: 6] = Traffic class: 0x 00.. = Differentiated Services Field: Default (0x) ..0. = ECN-Capable Transport (ECT): Not set ...0 = ECN-CE: Not set = Flowlabel: 0x Payload length: 36 Next header: IPv6 hop-by-hop option (0x00) Hop limit: 1 Source: :: (::) Destination: ff02::16 (ff02::16) Hop-by-Hop Option Next header: ICMPv6 (0x3a) Length: 0 (8 bytes) PadN: 2 bytes Router alert: MLD (4 bytes) Internet Control Message Protocol v6 Type: 143 (Multicast Listener Report Message v2) Code: 0 (Should always be zero) Checksum: 0x1a8f [correct] Reserved: 0 (Should always be zero) Number of records: 1 Changed to exclude: ff02::1:ffb8:5443 (ff02::1:ffb8:5443) Mode: Changed to exclude (4) Aux data len: 0 Number of Sources: 0 Multicast Address: ff02::1:ffb8:5443 No. Time Source Destination Protocol Info 2 0.97 :: ff02::1:ffb8:5443 ICMPv6 Neighbor solicitation for fe80::250:fcff:feb8:5443 Frame 2: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) Arrival Time: Sep 29, 2011 09:11:06.785918000 UTC Epoch Time: 1317287466.785918000 seconds [Time delta from previous captured frame: 0.97000 seconds] [Time delta from previous displayed frame: 0.97000 seconds] [Time since reference or first frame: 0.97000 seconds] Frame Number: 2 Frame Length: 78 bytes (624 bits) Capture Length: 78 bytes (624 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ipv6:icmpv6] [Coloring Rule Name: ICMP] [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43), Dst: IPv6mcast_ff:b8:54:43 (33:33:ff:b8:54:43)
