Re: kern/143622: [pfil] [patch] unlock pfil lock while calling firewall hooks
Old Synopsis: [patch] unlock pfil lock while calling firewall hooks New Synopsis: [pfil] [patch] unlock pfil lock while calling firewall hooks Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 7 05:34:40 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143622 ___ 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: How does rpc.lockd know where to send a request
M. Warner Losh wrote: In message: <4b6e2b40.1070...@elischer.org> Julian Elischer writes: : M. Warner Losh wrote: : > I have a problem. All systems are running freebsd-current form : > sometime in the last month, although similar systems running : > 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS : > client is doing something that baffles my mind entirely, maybe you can : > help. Please bear with me, this is a little complicated, but I wanted : > to include all the details. : > I have a host, let's call it dune. dune is at 10.0.0.5. dune is also : > the master for the carp interface 10.0.0.99. It is running rpc.lockd : > and is an nfs server. I've told nfs, rpcbind, lockd and statd to only : > listen on address 10.0.0.99. : > I have a second host. maud-dib is 10.0.0.8. I do "mount : > 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic : > going to 10.0.0.99. All is happy in the world. When I start, there's : > no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. : > Until I do the following 'lockf /dune/imp/junk ls' (I have write perms : > to /dune/imp). At this point, rpc.lockd hangs. I get the message : > "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is : > really there. However, wireshark shows the NLM traffic going to IP : > address 10.0.0.5. maud-dib has no carp interfaces. : > That's odd. So my question is 'how does lockd know where to go to : > talk the NLM protocol?' : > : : my recollection is that maud-dib will sent an initial packet to dune : and dune will respond but that the response may come from 10.0.0.5, : after which maud-dib will redirect all requests there, which will not : work because dune is not listenning there. : : teh problem is that dune's daemon is setting a local address of : IPADDR_ANY (0.0.0.0) which tells the packets to use a from : address that is the address ofthe interface that they exit from. : : Since 10.0.0.5 is the primary address on that interface, that gets : selected. : you may try some trickery where you add the .5 address AFTER the .99 : address so that the .99 is the primary address. Actually, it looks like this is getting returned, as a ASCII string '10.0.0.5' in frame 68 in response to the GETADDR call. Since I've told it specifically '-h 10.0.0.99' I'd have thought it would respect that. Since it is supposed to be bound to 10.0.0.99, I'd proffer the argument this is a bug in rpcbind's implementation of GETADDR. I never would have thought it would have been returned as an ASCII string, but you live and learn, eh? Now, on to fixing the bug. Warner P.S. http://people.freebsd.org/~imp/wireshark.dat has the trace I'm referring to (and I've posted it in another message on this thread). : > I did a packet capture from before I did the mount on maud-dib. I can : > see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an : > ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to : > 10.0.0.5. This gets an ICMP port unreachable message, since I told : > nfs, et al, to bind only to 10.0.0.99. : > So, I thought, 'the answer is obvious, I'll just look for the packet : > that has the string 'dune' in it (which is the hostname of 10.0.0.5). : > No packets have that string in it, other than the mount packet which : > has /dune in it. Nor is there any DNS activity doing a lookup. Nor : > is there any static mapping in /etc/hosts on 10.0.0.8. : > Next thought: Oh, somebody like portmapper or the NFS protocol from : > 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do : > locking requests to 10.0.0.5. That's trivial to find, I think to : > myself. I'll look for the octets 0a 00 00 05 (hex). The only : > instances of that are in the ARP packet, the NLM request and the ICMP : > unreachable packets. No other packets includes these bytes. Nor do : > any include the reverse. : > Right after the mount, there's nothing in the connection table that : > points to 10.0.0.5, only 10.0.0.99. : > So I'm having a serious WTF moment. How the heck is this even : > possible. Any ideas on where to look for where this gets set and/or : > communicated? : > thanks a bunch for any insight that you can give... : > Warner : > ___ : > 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" : : try swapping the addresses on the interface. ___ 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: How does rpc.lockd know where to send a request
M. Warner Losh wrote: In message: <4b6e2b40.1070...@elischer.org> Julian Elischer writes: : M. Warner Losh wrote: : > I have a problem. All systems are running freebsd-current form : > sometime in the last month, although similar systems running : > 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS : > client is doing something that baffles my mind entirely, maybe you can : > help. Please bear with me, this is a little complicated, but I wanted : > to include all the details. : > I have a host, let's call it dune. dune is at 10.0.0.5. dune is also : > the master for the carp interface 10.0.0.99. It is running rpc.lockd : > and is an nfs server. I've told nfs, rpcbind, lockd and statd to only : > listen on address 10.0.0.99. : > I have a second host. maud-dib is 10.0.0.8. I do "mount : > 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic : > going to 10.0.0.99. All is happy in the world. When I start, there's : > no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. : > Until I do the following 'lockf /dune/imp/junk ls' (I have write perms : > to /dune/imp). At this point, rpc.lockd hangs. I get the message : > "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is : > really there. However, wireshark shows the NLM traffic going to IP : > address 10.0.0.5. maud-dib has no carp interfaces. : > That's odd. So my question is 'how does lockd know where to go to : > talk the NLM protocol?' : > : : my recollection is that maud-dib will sent an initial packet to dune : and dune will respond but that the response may come from 10.0.0.5, : after which maud-dib will redirect all requests there, which will not : work because dune is not listenning there. But wouldn't the response from 10.0.0.5 mean I could search for the hex string and see 0a05 in the packet header? probably, but it may also besoemwhere in the protocol, and not in the header.. It's quite common (I saw it at cisco) for protocols to have fields within them that say "who is responding" where a common address is used instead of where thepacket comes from, but that that address is selected by some mechanism that detirmines the address that would be used to send a packet to teh recipient. the usual mechanism to do this is to open a udp socket, bind to the destination and then do a getsocnname() which will return the primary address of the interface that would be used to send the packet, then that address is used in some "who I am" field within the protocol. anyhow, make sure the primary address on the interface is 99 and hte secondary is 5 before launching your next experiment. if it doesn't change things then that's one theory down the drain. : teh problem is that dune's daemon is setting a local address of : IPADDR_ANY (0.0.0.0) which tells the packets to use a from : address that is the address ofthe interface that they exit from. No, dune's daemon is sitting on 10.0.0.99. : Since 10.0.0.5 is the primary address on that interface, that gets : selected. : you may try some trickery where you add the .5 address AFTER the .99 : address so that the .99 is the primary address. Normally, I'd believe you. But since there's nothing listening on the * address, and also nothing listening on the 10.0.0.5 address, I'm less sure. After looking at the wireshark dump, I don't see any 10.0.0.5 packets until the ARP for it near the end of the trace. http://people.freebsd.org/~imp/wireshark.dat if you are interested. This is a good theory, and I'll have to look into it deeper. Warner : > I did a packet capture from before I did the mount on maud-dib. I can : > see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an : > ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to : > 10.0.0.5. This gets an ICMP port unreachable message, since I told : > nfs, et al, to bind only to 10.0.0.99. : > So, I thought, 'the answer is obvious, I'll just look for the packet : > that has the string 'dune' in it (which is the hostname of 10.0.0.5). : > No packets have that string in it, other than the mount packet which : > has /dune in it. Nor is there any DNS activity doing a lookup. Nor : > is there any static mapping in /etc/hosts on 10.0.0.8. : > Next thought: Oh, somebody like portmapper or the NFS protocol from : > 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do : > locking requests to 10.0.0.5. That's trivial to find, I think to : > myself. I'll look for the octets 0a 00 00 05 (hex). The only : > instances of that are in the ARP packet, the NLM request and the ICMP : > unreachable packets. No other packets includes these bytes. Nor do : > any include the reverse. : > Right after the mount, there's nothing in the connection table that : > points to 10.0.0.5, only 10.0.0.99. : > So I'm having a serious WTF moment. How the heck is this even : > possible. Any ideas on where to look for where this gets set and/
Re: How does rpc.lockd know where to send a request
In message: <4b6e2b40.1070...@elischer.org> Julian Elischer writes: : M. Warner Losh wrote: : > I have a problem. All systems are running freebsd-current form : > sometime in the last month, although similar systems running : > 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS : > client is doing something that baffles my mind entirely, maybe you can : > help. Please bear with me, this is a little complicated, but I wanted : > to include all the details. : > I have a host, let's call it dune. dune is at 10.0.0.5. dune is also : > the master for the carp interface 10.0.0.99. It is running rpc.lockd : > and is an nfs server. I've told nfs, rpcbind, lockd and statd to only : > listen on address 10.0.0.99. : > I have a second host. maud-dib is 10.0.0.8. I do "mount : > 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic : > going to 10.0.0.99. All is happy in the world. When I start, there's : > no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. : > Until I do the following 'lockf /dune/imp/junk ls' (I have write perms : > to /dune/imp). At this point, rpc.lockd hangs. I get the message : > "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is : > really there. However, wireshark shows the NLM traffic going to IP : > address 10.0.0.5. maud-dib has no carp interfaces. : > That's odd. So my question is 'how does lockd know where to go to : > talk the NLM protocol?' : > : : my recollection is that maud-dib will sent an initial packet to dune : and dune will respond but that the response may come from 10.0.0.5, : after which maud-dib will redirect all requests there, which will not : work because dune is not listenning there. : : teh problem is that dune's daemon is setting a local address of : IPADDR_ANY (0.0.0.0) which tells the packets to use a from : address that is the address ofthe interface that they exit from. : : Since 10.0.0.5 is the primary address on that interface, that gets : selected. : you may try some trickery where you add the .5 address AFTER the .99 : address so that the .99 is the primary address. Actually, it looks like this is getting returned, as a ASCII string '10.0.0.5' in frame 68 in response to the GETADDR call. Since I've told it specifically '-h 10.0.0.99' I'd have thought it would respect that. Since it is supposed to be bound to 10.0.0.99, I'd proffer the argument this is a bug in rpcbind's implementation of GETADDR. I never would have thought it would have been returned as an ASCII string, but you live and learn, eh? Now, on to fixing the bug. Warner P.S. http://people.freebsd.org/~imp/wireshark.dat has the trace I'm referring to (and I've posted it in another message on this thread). : > I did a packet capture from before I did the mount on maud-dib. I can : > see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an : > ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to : > 10.0.0.5. This gets an ICMP port unreachable message, since I told : > nfs, et al, to bind only to 10.0.0.99. : > So, I thought, 'the answer is obvious, I'll just look for the packet : > that has the string 'dune' in it (which is the hostname of 10.0.0.5). : > No packets have that string in it, other than the mount packet which : > has /dune in it. Nor is there any DNS activity doing a lookup. Nor : > is there any static mapping in /etc/hosts on 10.0.0.8. : > Next thought: Oh, somebody like portmapper or the NFS protocol from : > 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do : > locking requests to 10.0.0.5. That's trivial to find, I think to : > myself. I'll look for the octets 0a 00 00 05 (hex). The only : > instances of that are in the ARP packet, the NLM request and the ICMP : > unreachable packets. No other packets includes these bytes. Nor do : > any include the reverse. : > Right after the mount, there's nothing in the connection table that : > points to 10.0.0.5, only 10.0.0.99. : > So I'm having a serious WTF moment. How the heck is this even : > possible. Any ideas on where to look for where this gets set and/or : > communicated? : > thanks a bunch for any insight that you can give... : > Warner : > ___ : > 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: How does rpc.lockd know where to send a request
In message: <4b6e2b40.1070...@elischer.org> Julian Elischer writes: : M. Warner Losh wrote: : > I have a problem. All systems are running freebsd-current form : > sometime in the last month, although similar systems running : > 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS : > client is doing something that baffles my mind entirely, maybe you can : > help. Please bear with me, this is a little complicated, but I wanted : > to include all the details. : > I have a host, let's call it dune. dune is at 10.0.0.5. dune is also : > the master for the carp interface 10.0.0.99. It is running rpc.lockd : > and is an nfs server. I've told nfs, rpcbind, lockd and statd to only : > listen on address 10.0.0.99. : > I have a second host. maud-dib is 10.0.0.8. I do "mount : > 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic : > going to 10.0.0.99. All is happy in the world. When I start, there's : > no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. : > Until I do the following 'lockf /dune/imp/junk ls' (I have write perms : > to /dune/imp). At this point, rpc.lockd hangs. I get the message : > "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is : > really there. However, wireshark shows the NLM traffic going to IP : > address 10.0.0.5. maud-dib has no carp interfaces. : > That's odd. So my question is 'how does lockd know where to go to : > talk the NLM protocol?' : > : : my recollection is that maud-dib will sent an initial packet to dune : and dune will respond but that the response may come from 10.0.0.5, : after which maud-dib will redirect all requests there, which will not : work because dune is not listenning there. But wouldn't the response from 10.0.0.5 mean I could search for the hex string and see 0a05 in the packet header? : teh problem is that dune's daemon is setting a local address of : IPADDR_ANY (0.0.0.0) which tells the packets to use a from : address that is the address ofthe interface that they exit from. No, dune's daemon is sitting on 10.0.0.99. : Since 10.0.0.5 is the primary address on that interface, that gets : selected. : you may try some trickery where you add the .5 address AFTER the .99 : address so that the .99 is the primary address. Normally, I'd believe you. But since there's nothing listening on the * address, and also nothing listening on the 10.0.0.5 address, I'm less sure. After looking at the wireshark dump, I don't see any 10.0.0.5 packets until the ARP for it near the end of the trace. http://people.freebsd.org/~imp/wireshark.dat if you are interested. This is a good theory, and I'll have to look into it deeper. Warner : > I did a packet capture from before I did the mount on maud-dib. I can : > see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an : > ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to : > 10.0.0.5. This gets an ICMP port unreachable message, since I told : > nfs, et al, to bind only to 10.0.0.99. : > So, I thought, 'the answer is obvious, I'll just look for the packet : > that has the string 'dune' in it (which is the hostname of 10.0.0.5). : > No packets have that string in it, other than the mount packet which : > has /dune in it. Nor is there any DNS activity doing a lookup. Nor : > is there any static mapping in /etc/hosts on 10.0.0.8. : > Next thought: Oh, somebody like portmapper or the NFS protocol from : > 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do : > locking requests to 10.0.0.5. That's trivial to find, I think to : > myself. I'll look for the octets 0a 00 00 05 (hex). The only : > instances of that are in the ARP packet, the NLM request and the ICMP : > unreachable packets. No other packets includes these bytes. Nor do : > any include the reverse. : > Right after the mount, there's nothing in the connection table that : > points to 10.0.0.5, only 10.0.0.99. : > So I'm having a serious WTF moment. How the heck is this even : > possible. Any ideas on where to look for where this gets set and/or : > communicated? : > thanks a bunch for any insight that you can give... : > Warner : > ___ : > 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: How does rpc.lockd know where to send a request
M. Warner Losh wrote: I have a problem. All systems are running freebsd-current form sometime in the last month, although similar systems running 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS client is doing something that baffles my mind entirely, maybe you can help. Please bear with me, this is a little complicated, but I wanted to include all the details. I have a host, let's call it dune. dune is at 10.0.0.5. dune is also the master for the carp interface 10.0.0.99. It is running rpc.lockd and is an nfs server. I've told nfs, rpcbind, lockd and statd to only listen on address 10.0.0.99. I have a second host. maud-dib is 10.0.0.8. I do "mount 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic going to 10.0.0.99. All is happy in the world. When I start, there's no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. Until I do the following 'lockf /dune/imp/junk ls' (I have write perms to /dune/imp). At this point, rpc.lockd hangs. I get the message "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is really there. However, wireshark shows the NLM traffic going to IP address 10.0.0.5. maud-dib has no carp interfaces. That's odd. So my question is 'how does lockd know where to go to talk the NLM protocol?' my recollection is that maud-dib will sent an initial packet to dune and dune will respond but that the response may come from 10.0.0.5, after which maud-dib will redirect all requests there, which will not work because dune is not listenning there. teh problem is that dune's daemon is setting a local address of IPADDR_ANY (0.0.0.0) which tells the packets to use a from address that is the address ofthe interface that they exit from. Since 10.0.0.5 is the primary address on that interface, that gets selected. you may try some trickery where you add the .5 address AFTER the .99 address so that the .99 is the primary address. I did a packet capture from before I did the mount on maud-dib. I can see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to 10.0.0.5. This gets an ICMP port unreachable message, since I told nfs, et al, to bind only to 10.0.0.99. So, I thought, 'the answer is obvious, I'll just look for the packet that has the string 'dune' in it (which is the hostname of 10.0.0.5). No packets have that string in it, other than the mount packet which has /dune in it. Nor is there any DNS activity doing a lookup. Nor is there any static mapping in /etc/hosts on 10.0.0.8. Next thought: Oh, somebody like portmapper or the NFS protocol from 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do locking requests to 10.0.0.5. That's trivial to find, I think to myself. I'll look for the octets 0a 00 00 05 (hex). The only instances of that are in the ARP packet, the NLM request and the ICMP unreachable packets. No other packets includes these bytes. Nor do any include the reverse. Right after the mount, there's nothing in the connection table that points to 10.0.0.5, only 10.0.0.99. So I'm having a serious WTF moment. How the heck is this even possible. Any ideas on where to look for where this gets set and/or communicated? thanks a bunch for any insight that you can give... Warner ___ 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"
How does rpc.lockd know where to send a request
I have a problem. All systems are running freebsd-current form sometime in the last month, although similar systems running 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS client is doing something that baffles my mind entirely, maybe you can help. Please bear with me, this is a little complicated, but I wanted to include all the details. I have a host, let's call it dune. dune is at 10.0.0.5. dune is also the master for the carp interface 10.0.0.99. It is running rpc.lockd and is an nfs server. I've told nfs, rpcbind, lockd and statd to only listen on address 10.0.0.99. I have a second host. maud-dib is 10.0.0.8. I do "mount 10.0.0.99:/dune /dune" on maud-dib. Wireshark shows all the traffic going to 10.0.0.99. All is happy in the world. When I start, there's no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. Until I do the following 'lockf /dune/imp/junk ls' (I have write perms to /dune/imp). At this point, rpc.lockd hangs. I get the message "10.0.0.99:/dune: lockd not responding" which seems odd. lockd is really there. However, wireshark shows the NLM traffic going to IP address 10.0.0.5. maud-dib has no carp interfaces. That's odd. So my question is 'how does lockd know where to go to talk the NLM protocol?' I did a packet capture from before I did the mount on maud-dib. I can see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to 10.0.0.5. This gets an ICMP port unreachable message, since I told nfs, et al, to bind only to 10.0.0.99. So, I thought, 'the answer is obvious, I'll just look for the packet that has the string 'dune' in it (which is the hostname of 10.0.0.5). No packets have that string in it, other than the mount packet which has /dune in it. Nor is there any DNS activity doing a lookup. Nor is there any static mapping in /etc/hosts on 10.0.0.8. Next thought: Oh, somebody like portmapper or the NFS protocol from 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do locking requests to 10.0.0.5. That's trivial to find, I think to myself. I'll look for the octets 0a 00 00 05 (hex). The only instances of that are in the ARP packet, the NLM request and the ICMP unreachable packets. No other packets includes these bytes. Nor do any include the reverse. Right after the mount, there's nothing in the connection table that points to 10.0.0.5, only 10.0.0.99. So I'm having a serious WTF moment. How the heck is this even possible. Any ideas on where to look for where this gets set and/or communicated? thanks a bunch for any insight that you can give... Warner ___ 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/143573: [em] em(4) NIC crashes intermittently
The following reply was made to PR kern/143573; it has been noted by GNATS. From: Ivan Voras To: Mars G Miro Cc: bug-follo...@freebsd.org, earl.la...@gmail.com, Jack Vogel Subject: Re: kern/143573: [em] em(4) NIC crashes intermittently Date: Sun, 7 Feb 2010 01:41:08 +0100 On 7 February 2010 00:59, Mars G Miro wrote: > This looks like these: > http://forums.freebsd.org/archive/index.php/t-10475.html > http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054369.html > > How about this? > http://www.mail-archive.com/comm...@crater.dragonflybsd.org/msg03494.html > I don't know - from the looks of the traces it seems like all of these point to a different bug... ___ 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/143573: [em] em(4) NIC crashes intermittently
The following reply was made to PR kern/143573; it has been noted by GNATS. From: Mars G Miro To: bug-follo...@freebsd.org, earl.la...@gmail.com, Jack Vogel , Ivan Voras Cc: Subject: Re: kern/143573: [em] em(4) NIC crashes intermittently Date: Sun, 7 Feb 2010 07:59:49 +0800 This looks like these: http://forums.freebsd.org/archive/index.php/t-10475.html http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054369.html How about this? http://www.mail-archive.com/comm...@crater.dragonflybsd.org/msg03494.html -- cheers mars - Joan Crawford - "I, Joan Crawford, I believe in the dollar. Everything I earn, I spend." - http://www.brainyquote.com/quotes/authors/j/joan_crawford.html ___ 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: Software TKIP group rekeying and phase1 issue
On Saturday 06 February 2010 22:56:15 Sam Leffler wrote:
> Bernhard Schmidt wrote:
> > Hi,
> >
> > When hostapd triggers rekeying of the group key, wpa_supplicant
> > successfully sets the correct new key. On first use of the new key
> > tkip_mixing_phase1() should be applied before decrypting any frames,
> > tkip_decrypt() does this as
> >
> > if (iv32 != (u32)(key->wk_keyrsc[tid] >> 16) || !ctx->rx_phase1_done) {
> > tkip_mixing_phase1(ctx->rx_ttak, key->wk_key,
> > wh->i_addr2, iv32);
> > ctx->rx_phase1_done = 1;
> > }
> >
> > But, after a rekeying event, neither of this condition match, especially
> > as rx_phase1_done is no longer zero, therefore tkip_mixing_phase1() isn't
> > called which leads to dropped frames with "TKIP ICV mismatch on decrypt"
> > messages.
> >
> > A working solution for that is to set rx_phase1_done to zero inside
> > tkip_setkey(). I'm not sure whether that is the best solution or if it is
> > better to set/reset the wk_keyrsc sequence, at least this diff works for
> > me and few other over at the Forums.
> >
> > Index: sys/net80211/ieee80211_crypto_tkip.c
> > ===
> > --- sys/net80211/ieee80211_crypto_tkip.c(revision 203242)
> > +++ sys/net80211/ieee80211_crypto_tkip.c(working copy)
> > @@ -144,6 +144,8 @@ tkip_setkey(struct ieee80211_key *k)
> > return 0;
> > }
> > k->wk_keytsc = 1; /* TSC starts at 1 */
> > + if (k->wk_flags & IEEE80211_KEY_GROUP)
> > + ctx->rx_phase1_done = 0;
> > return 1;
> > }
>
> Reseting this flag in setkey looks right but why only for group keys? I
> don't think you want to reset the keyrsc unless instructed; if I recall
> a new RSC may be sent down by the authenticator when plumbing a key--but
> it's been a while since I looked at this.
>
> Have you looked at other implementations?
Doing that for all keys is probably right, have to test that.
I did look at other implementation, they do zero out (tkip_ctx *)ctx inside
tkip_setkey() and restore part of its content from the key, which has the side
effect that rx_phase1_done also zero. No one handles that case intentionally.
--
Bernhard
___
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/143593: [ipsec] When using IPSec, tcpdump doesn't show outgoing packets on gif interface
The following reply was made to PR kern/143593; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: Eugene Grosbein Cc: freebsd-net@FreeBSD.org, bug-follo...@freebsd.org, j...@fromru.com Subject: Re: kern/143593: [ipsec] When using IPSec, tcpdump doesn't show outgoing packets on gif interface Date: Sat, 6 Feb 2010 22:02:01 + (UTC) On Sat, 6 Feb 2010, Eugene Grosbein wrote: Hi Eugene, > The following reply was made to PR kern/143593; it has been noted by GNATS. > > From: Eugene Grosbein > To: Vadim Fedorenko > Cc: bug-follo...@freebsd.org > Subject: Re: kern/143593: [ipsec] When using IPSec, tcpdump doesn't show > outgoing > packets on gif interface > Date: Sat, 06 Feb 2010 13:21:37 +0700 > > Hi! > > This is not a bug but some misunderstanding how IPSEC tunnel mode works. > You need not use gif tunnel and IPSEC tunnel at once. But still you could for various reasons. > You should use IPSEC transport mode with gif or IPSEC tunnel mode > without gif. > > In fact, for IPSEC tunnel mode your kernel encrypts and encapsulates > outgoing packets > before it chooses outgoing interface. And IPSEC-encapsulated packet already > has B.B.B.B as destination IP so it is not routed to your gif-tunnel. > Instead, it is routed to your real network interface, therefore tcpdump > -i gif0 does not show it. > > Just change your IPSEC configuration to transport mode > keeping your gif configuration unchanged. > Then outgoing packets will be routed to gif0 by means of routing table > (and not by IPSEC tunnel mode config) and tcpdump will show them. > Gif tunnel will encapsulate them and only then they will be encrypted > with IPSEC and sent. > > I suggest this PR be closed. Please ask this type of questions in the > lists first. While what you say ist best practise and will mitigate the problem, there is a known problem here nonetheless. I think kern/121642 was one of the original submissions and this should be marked as a duplicate and possibly migrated there. There are more slightly similar problems reported (kern/110959, ...) I think similar strange results might be seen if stacking gif and gre w/o IPsec (or maybe it was gif in gif). -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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/143593: [ipsec] When using IPSec, tcpdump doesn't show outgoing packets on gif interface
On Sat, 6 Feb 2010, Eugene Grosbein wrote: Hi Eugene, The following reply was made to PR kern/143593; it has been noted by GNATS. From: Eugene Grosbein To: Vadim Fedorenko Cc: bug-follo...@freebsd.org Subject: Re: kern/143593: [ipsec] When using IPSec, tcpdump doesn't show outgoing packets on gif interface Date: Sat, 06 Feb 2010 13:21:37 +0700 Hi! This is not a bug but some misunderstanding how IPSEC tunnel mode works. You need not use gif tunnel and IPSEC tunnel at once. But still you could for various reasons. You should use IPSEC transport mode with gif or IPSEC tunnel mode without gif. In fact, for IPSEC tunnel mode your kernel encrypts and encapsulates outgoing packets before it chooses outgoing interface. And IPSEC-encapsulated packet already has B.B.B.B as destination IP so it is not routed to your gif-tunnel. Instead, it is routed to your real network interface, therefore tcpdump -i gif0 does not show it. Just change your IPSEC configuration to transport mode keeping your gif configuration unchanged. Then outgoing packets will be routed to gif0 by means of routing table (and not by IPSEC tunnel mode config) and tcpdump will show them. Gif tunnel will encapsulate them and only then they will be encrypted with IPSEC and sent. I suggest this PR be closed. Please ask this type of questions in the lists first. While what you say ist best practise and will mitigate the problem, there is a known problem here nonetheless. I think kern/121642 was one of the original submissions and this should be marked as a duplicate and possibly migrated there. There are more slightly similar problems reported (kern/110959, ...) I think similar strange results might be seen if stacking gif and gre w/o IPsec (or maybe it was gif in gif). -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: Software TKIP group rekeying and phase1 issue
Bernhard Schmidt wrote:
Hi,
When hostapd triggers rekeying of the group key, wpa_supplicant successfully
sets the correct new key. On first use of the new key tkip_mixing_phase1()
should be applied before decrypting any frames, tkip_decrypt() does this as
if (iv32 != (u32)(key->wk_keyrsc[tid] >> 16) || !ctx->rx_phase1_done) {
tkip_mixing_phase1(ctx->rx_ttak, key->wk_key,
wh->i_addr2, iv32);
ctx->rx_phase1_done = 1;
}
But, after a rekeying event, neither of this condition match, especially as
rx_phase1_done is no longer zero, therefore tkip_mixing_phase1() isn't called
which leads to dropped frames with "TKIP ICV mismatch on decrypt" messages.
A working solution for that is to set rx_phase1_done to zero inside
tkip_setkey(). I'm not sure whether that is the best solution or if it is
better to set/reset the wk_keyrsc sequence, at least this diff works for me
and few other over at the Forums.
Index: sys/net80211/ieee80211_crypto_tkip.c
===
--- sys/net80211/ieee80211_crypto_tkip.c(revision 203242)
+++ sys/net80211/ieee80211_crypto_tkip.c(working copy)
@@ -144,6 +144,8 @@ tkip_setkey(struct ieee80211_key *k)
return 0;
}
k->wk_keytsc = 1;/* TSC starts at 1 */
+ if (k->wk_flags & IEEE80211_KEY_GROUP)
+ ctx->rx_phase1_done = 0;
return 1;
}
Reseting this flag in setkey looks right but why only for group keys? I
don't think you want to reset the keyrsc unless instructed; if I recall
a new RSC may be sent down by the authenticator when plumbing a key--but
it's been a while since I looked at this.
Have you looked at other implementations?
Sam
___
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: HT rate set in net80211 not changeable for STA
Alexander Egorenkov wrote: And is any API in planning that would make it possible to change the advertised HT rate set by STA during run time and not at compile time ? E.g. ieee80211_set_ht_rateset :-) On Sat, Feb 6, 2010 at 3:44 PM, Rui Paulo wrote: On 6 Feb 2010, at 08:28, Alexander Egorenkov wrote: Hi, the HT rate set advertized by a STA is hardcoded in net80211 and the maximum MCS is 15, but my device also supports MCS32 (HT duplicate mode). Is there a possibility to change the HT rates set advertized by a STA except changing the code and recompiling net80211 stack ? Not really. The advertised rate set should be initially set according to the capabilities of the device. There were no devices > 2x2 when I wrote the code so MCS15 is the max. To support such devices you need to do more than just grow the rateset. Making the rate set user-controllable would be ok to add but probably used only for testing. Sam ___ 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/143593: [ipsec] When using IPSec, tcpdump doesn't show outgoing packets on gif interface
The following reply was made to PR kern/143593; it has been noted by GNATS. From: Eugene Grosbein To: Vadim Fedorenko Cc: bug-follo...@freebsd.org Subject: Re: kern/143593: [ipsec] When using IPSec, tcpdump doesn't show outgoing packets on gif interface Date: Sat, 06 Feb 2010 13:21:37 +0700 Hi! This is not a bug but some misunderstanding how IPSEC tunnel mode works. You need not use gif tunnel and IPSEC tunnel at once. You should use IPSEC transport mode with gif or IPSEC tunnel mode without gif. In fact, for IPSEC tunnel mode your kernel encrypts and encapsulates outgoing packets before it chooses outgoing interface. And IPSEC-encapsulated packet already has B.B.B.B as destination IP so it is not routed to your gif-tunnel. Instead, it is routed to your real network interface, therefore tcpdump -i gif0 does not show it. Just change your IPSEC configuration to transport mode keeping your gif configuration unchanged. Then outgoing packets will be routed to gif0 by means of routing table (and not by IPSEC tunnel mode config) and tcpdump will show them. Gif tunnel will encapsulate them and only then they will be encrypted with IPSEC and sent. I suggest this PR be closed. Please ask this type of questions in the lists first. ___ 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: HT rate set in net80211 not changeable for STA
And is any API in planning that would make it possible to change the advertised HT rate set by STA during run time and not at compile time ? E.g. ieee80211_set_ht_rateset :-) On Sat, Feb 6, 2010 at 3:44 PM, Rui Paulo wrote: > On 6 Feb 2010, at 08:28, Alexander Egorenkov wrote: > > > Hi, > > > > the HT rate set advertized by a STA is hardcoded in net80211 > > and the maximum MCS is 15, but my device also supports MCS32 (HT > duplicate > > mode). > > Is there a possibility to change the HT rates set advertized by a STA > > except changing > > the code and recompiling net80211 stack ? > > Not really. > > -- > Rui Paulo > > ___ 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: HT rate set in net80211 not changeable for STA
On 6 Feb 2010, at 08:28, Alexander Egorenkov wrote: > Hi, > > the HT rate set advertized by a STA is hardcoded in net80211 > and the maximum MCS is 15, but my device also supports MCS32 (HT duplicate > mode). > Is there a possibility to change the HT rates set advertized by a STA > except changing > the code and recompiling net80211 stack ? Not really. -- Rui Paulo ___ 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/141646: commit references a PR
The following reply was made to PR kern/141646; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/141646: commit references a PR
Date: Sat, 6 Feb 2010 13:49:48 + (UTC)
Author: eri
Date: Sat Feb 6 13:49:35 2010
New Revision: 203548
URL: http://svn.freebsd.org/changeset/base/203548
Log:
Propagate the vlan eventis to the underlying interfaces/members so they can
do initialization of hw related features.
PR: kern/141646
Reviewed by: thompsa
Approved by: thompsa(co-mentor)
MFC after: 2 weeks
Modified:
head/sys/net/if_lagg.c
head/sys/net/if_lagg.h
Modified: head/sys/net/if_lagg.c
==
--- head/sys/net/if_lagg.c Sat Feb 6 13:39:08 2010(r203547)
+++ head/sys/net/if_lagg.c Sat Feb 6 13:49:35 2010(r203548)
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
@@ -198,6 +199,50 @@ static moduledata_t lagg_mod = {
DECLARE_MODULE(if_lagg, lagg_mod, SI_SUB_PSEUDO, SI_ORDER_ANY);
+#if __FreeBSD_version >= 80
+/*
+ * This routine is run via an vlan
+ * config EVENT
+ */
+static void
+lagg_register_vlan(void *arg, struct ifnet *ifp, u_int16_t vtag)
+{
+struct lagg_softc *sc = ifp->if_softc;
+struct lagg_port*lp;
+
+if (ifp->if_softc != arg) /* Not our event */
+return;
+
+LAGG_RLOCK(sc);
+if (!SLIST_EMPTY(&sc->sc_ports)) {
+SLIST_FOREACH(lp, &sc->sc_ports, lp_entries)
+EVENTHANDLER_INVOKE(vlan_config, lp->lp_ifp, vtag);
+}
+LAGG_RUNLOCK(sc);
+}
+
+/*
+ * This routine is run via an vlan
+ * unconfig EVENT
+ */
+static void
+lagg_unregister_vlan(void *arg, struct ifnet *ifp, u_int16_t vtag)
+{
+struct lagg_softc *sc = ifp->if_softc;
+struct lagg_port*lp;
+
+if (ifp->if_softc != arg) /* Not our event */
+return;
+
+LAGG_RLOCK(sc);
+if (!SLIST_EMPTY(&sc->sc_ports)) {
+SLIST_FOREACH(lp, &sc->sc_ports, lp_entries)
+EVENTHANDLER_INVOKE(vlan_unconfig, lp->lp_ifp, vtag);
+}
+LAGG_RUNLOCK(sc);
+}
+#endif
+
static int
lagg_clone_create(struct if_clone *ifc, int unit, caddr_t params)
{
@@ -253,6 +298,13 @@ lagg_clone_create(struct if_clone *ifc,
*/
ether_ifattach(ifp, eaddr);
+#if __FreeBSD_version >= 80
+ sc->vlan_attach = EVENTHANDLER_REGISTER(vlan_config,
+ lagg_register_vlan, sc, EVENTHANDLER_PRI_FIRST);
+ sc->vlan_detach = EVENTHANDLER_REGISTER(vlan_unconfig,
+ lagg_unregister_vlan, sc, EVENTHANDLER_PRI_FIRST);
+#endif
+
/* Insert into the global list of laggs */
mtx_lock(&lagg_list_mtx);
SLIST_INSERT_HEAD(&lagg_list, sc, sc_entries);
@@ -272,6 +324,11 @@ lagg_clone_destroy(struct ifnet *ifp)
lagg_stop(sc);
ifp->if_flags &= ~IFF_UP;
+#if __FreeBSD_version >= 80
+ EVENTHANDLER_DEREGISTER(vlan_config, sc->vlan_attach);
+ EVENTHANDLER_DEREGISTER(vlan_unconfig, sc->vlan_detach);
+#endif
+
/* Shutdown and remove lagg ports */
while ((lp = SLIST_FIRST(&sc->sc_ports)) != NULL)
lagg_port_destroy(lp, 1);
Modified: head/sys/net/if_lagg.h
==
--- head/sys/net/if_lagg.h Sat Feb 6 13:39:08 2010(r203547)
+++ head/sys/net/if_lagg.h Sat Feb 6 13:49:35 2010(r203548)
@@ -198,6 +198,10 @@ struct lagg_softc {
void(*sc_lladdr)(struct lagg_softc *);
void(*sc_req)(struct lagg_softc *, caddr_t);
void(*sc_portreq)(struct lagg_port *, caddr_t);
+#if __FreeBSD_version >= 80
+ eventhandler_tag vlan_attach;
+ eventhandler_tag vlan_detach;
+#endif
};
struct lagg_port {
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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"
HT rate set in net80211 not changeable for STA
Hi, the HT rate set advertized by a STA is hardcoded in net80211 and the maximum MCS is 15, but my device also supports MCS32 (HT duplicate mode). Is there a possibility to change the HT rates set advertized by a STA except changing the code and recompiling net80211 stack ? Thanks. Alex. ___ 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"
