Re: MFC Re: soreceive_stream: issues with O_NONBLOCK
On 11.07.2011 17:15, Andrew Boyer wrote: On Jul 8, 2011, at 6:51 AM, Andre Oppermann wrote: On 07.07.2011 21:24, Mikolaj Golub wrote: On Thu, 07 Jul 2011 12:47:15 +0200 Andre Oppermann wrote: AO Please try this patch: AO http://people.freebsd.org/~andre/soreceive_stream.diff-20110707 It works for me. No issues detected so far. Thanks. Committed in r223863. Many thanks for testing! -- Andre Hello Andre, It appears that r197236 was never MFC'd, so soreceive_stream is still on by default in stable/8. Would you be able to MFC it along with 223839 and 223863? soreceive_stream() was never on by default. In fact one had to compile it in and enable it with a tuneable. I plan do the MFC's in a few days. -- Andre ___ 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: ESP Raw Socket: Returned IP packet incorrect
Thanks for your reply. Where can I find documentation about this? (Or would it be possible for you to direct me at the proper sources?) Thanks Regards Matt On 11 July 2011 18:01, Michael Tüxen michael.tue...@lurchi.franken.dewrote: On Jul 11, 2011, at 5:26 PM, Matthew Cini Sarreo wrote: Hello all; I have recently encountered a problem when using raw sockets on FreeBSD 8 (8.0-RELEASE) when using ESP raw sockets. I have created a raw esp socket using: socket(AF_INET, SOCK_RAW, 50); which works fine. However, when there is a packet on the socket, recvfrom() returns a packet where the length bytes in the IP header are incorrect; they are swapped (MSB is placed in the LSB and vice-versa) tcpdump shows the following: tcpdump: listening on le0, link-type EN10MB (Ethernet), capture size 96 bytes 15:00:53.993810 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ESP (50), length 120) 10.0.251.228 10.0.252.231: ESP(spi=0xa0534f17,seq=0x3), length 100 0x: 4500 0078 4000 4032 2d88 0a00 fbe4 0x0010: 0a00 fce7 a053 4f17 0003 6885 8abd 0x0020: 5ded 44dc 842f 3081 8fa3 bde4 2265 0x0030: 7438 2bf4 049c 664b 7dc4 44ef 1f6f 5e7d 0x0040: b8c1 482f 8c3b f488 a19a 3d9a d5fe ed9d 0x0050: b1c2 However, recvfrom() returns the following buffer: 4500 6400 0040 4032 2D88 0A00 FBE4 0A00 FCE7 A053 4F17 0003 6885 8ABD 5DED 44DC 842F 3081 8FA3 BDE4 2265 7438 2BF4 049C 664B 7DC4 44EF 1F6F 5E7D B8C1 482F 8C3B F488 A19A 3D9A D5FE ED9D B1C2 As it is easy to see, the length is not correct (bytes 2 and 3 are 0x6400 instead of 0x0064) and it does not correspond to the value returned by recvfrom(). Is this a known issue? Am I missing some options for raw sockets that are required for FreeBSD? I have attempted this on a socket to a TUN interface (not with an ESP socket) and the buffer had the proper length; it seems to only happen with ESP. This code runs fine on multiple Linux distributions and on Windows; it was only noticed with FreeBSD. Could it be that there is some other ESP application running and interfering (I have not installed any; don't know if there are by default and I'm quite new to any of the BSDs)? I think Linux provides the tot_len field in network byte order whereas FreeBSD provides it in host byte order. At least they expect it that way when using a send call. So you must take care of this in the source code of the application by using an #ifdef... Best regards Michael Any help would be much appreciated. Matt ___ 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: ESP Raw Socket: Returned IP packet incorrect
On Jul 12, 2011, at 11:23 AM, Matthew Cini Sarreo wrote: Thanks for your reply. Where can I find documentation about this? (Or would it be possible for you to direct me at the proper sources?) At http://fxr.watson.org/fxr/source/netinet/ip_input.c#L464 the length field is converted to host byte order. I have not looked at the Linux sources. I figured it out when writing an SCTP test tool which uses raw socket IO and support Solaris, Linux, FreeBSD and Mac OS X. Best regards Michael Thanks Regards Matt On 11 July 2011 18:01, Michael Tüxen michael.tue...@lurchi.franken.de wrote: On Jul 11, 2011, at 5:26 PM, Matthew Cini Sarreo wrote: Hello all; I have recently encountered a problem when using raw sockets on FreeBSD 8 (8.0-RELEASE) when using ESP raw sockets. I have created a raw esp socket using: socket(AF_INET, SOCK_RAW, 50); which works fine. However, when there is a packet on the socket, recvfrom() returns a packet where the length bytes in the IP header are incorrect; they are swapped (MSB is placed in the LSB and vice-versa) tcpdump shows the following: tcpdump: listening on le0, link-type EN10MB (Ethernet), capture size 96 bytes 15:00:53.993810 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ESP (50), length 120) 10.0.251.228 10.0.252.231: ESP(spi=0xa0534f17,seq=0x3), length 100 0x: 4500 0078 4000 4032 2d88 0a00 fbe4 0x0010: 0a00 fce7 a053 4f17 0003 6885 8abd 0x0020: 5ded 44dc 842f 3081 8fa3 bde4 2265 0x0030: 7438 2bf4 049c 664b 7dc4 44ef 1f6f 5e7d 0x0040: b8c1 482f 8c3b f488 a19a 3d9a d5fe ed9d 0x0050: b1c2 However, recvfrom() returns the following buffer: 4500 6400 0040 4032 2D88 0A00 FBE4 0A00 FCE7 A053 4F17 0003 6885 8ABD 5DED 44DC 842F 3081 8FA3 BDE4 2265 7438 2BF4 049C 664B 7DC4 44EF 1F6F 5E7D B8C1 482F 8C3B F488 A19A 3D9A D5FE ED9D B1C2 As it is easy to see, the length is not correct (bytes 2 and 3 are 0x6400 instead of 0x0064) and it does not correspond to the value returned by recvfrom(). Is this a known issue? Am I missing some options for raw sockets that are required for FreeBSD? I have attempted this on a socket to a TUN interface (not with an ESP socket) and the buffer had the proper length; it seems to only happen with ESP. This code runs fine on multiple Linux distributions and on Windows; it was only noticed with FreeBSD. Could it be that there is some other ESP application running and interfering (I have not installed any; don't know if there are by default and I'm quite new to any of the BSDs)? I think Linux provides the tot_len field in network byte order whereas FreeBSD provides it in host byte order. At least they expect it that way when using a send call. So you must take care of this in the source code of the application by using an #ifdef... Best regards Michael Any help would be much appreciated. Matt ___ 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: MFC Re: soreceive_stream: issues with O_NONBLOCK
On Jul 12, 2011, at 3:10 AM, Andre Oppermann wrote: On 11.07.2011 17:15, Andrew Boyer wrote: On Jul 8, 2011, at 6:51 AM, Andre Oppermann wrote: On 07.07.2011 21:24, Mikolaj Golub wrote: On Thu, 07 Jul 2011 12:47:15 +0200 Andre Oppermann wrote: AO Please try this patch: AO http://people.freebsd.org/~andre/soreceive_stream.diff-20110707 It works for me. No issues detected so far. Thanks. Committed in r223863. Many thanks for testing! -- Andre Hello Andre, It appears that r197236 was never MFC'd, so soreceive_stream is still on by default in stable/8. Would you be able to MFC it along with 223839 and 223863? soreceive_stream() was never on by default. In fact one had to compile it in and enable it with a tuneable. I plan do the MFC's in a few days. -- Andre My bad, I missed the #if 0's in tcp_usrreq.c. Looking forward to the MFC's to try it out. -Andrew -- Andrew Boyerabo...@averesystems.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: bce packet loss
I do still see fixed setups in service provider handoffs - for example this colo, Level3 and Hurricane. Also all our metro ethernet stuff specifies a fixed configuration. Well one could also say that this sort of thing tends to result from the, There is a knob, I MUST twist it! syndrome. It's a layer 8-9 issue. It results from an auto-negotiation giving a half-duplex connection, and no one noticing until 6 months down the road, then demanding a huge credit from the provider for not selling a full-duplex circuit as was contracted. This happens way more often that you'd think. R. ___ 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: em driver, 82574L chip, and possibly ASPM
On 7/12/2011 2:54 PM, Hooman Fazaeli wrote: tanx. out of curiosity, can some one pls. explain this? In if_em.c, function em_start_locked, there is: if (txr-tx_avail = EM_TX_CLEANUP_THRESHOLD) em_txeof(txr); inside while loop. While is if_igb.c, function igb_start_locked, a similar code it is out of while loop: if (txr-tx_avail = IGB_TX_CLEANUP_THRESHOLD) igb_txeof(txr); is this intentional or mistake? No idea, but Jack Vogel might know. ---Mike On 7/6/2011 2:58 PM, Mike Tancsa wrote: On 7/6/2011 4:29 AM, Hooman Fazaeli wrote: Can you pls. share the patch for freebsd 7? Its in the tree. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/ ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em driver, 82574L chip, and possibly ASPM
I have similar problems on a couple of 7.3 boxes with latest driver form
-CURRENT.
I just wanted to know if your 7 boxes work fine so I look for cause else where.
On 2/7/2011 3:23 AM, Mike Tancsa wrote:
So far so good. I would often get a hang on the level zero dumps to my
backup server Sunday AM, and it made it through! So a good sign, but
not a definitive sign.
I have a PCIe em card that has this chipset as well and was showing the
same sort of problem in a customer's RELENG_7 box. I will see if I can
get the customer to try the card in their box with the patch for
RELENG_7 as it would show this issue at least once a day until I pulled
the card for an older version
---Mike
On 2/4/2011 1:12 PM, Jack Vogel wrote:
Was curious too, but being more patient than you :)
Jack
On Fri, Feb 4, 2011 at 10:09 AM, Sean Brunosean...@yahoo-inc.com wrote:
Any more data on this problem or do we have to wait a while?
Sean
On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote:
On 2/2/2011 12:37 PM, Jack Vogel wrote:
So has everyone that wanted to get something testing been able to do
so?
I have been testing in the back and will deploy to my production box
this afternoon. As I am not able to reproduce it easily, it will be a
bit before I can say the issue is gone. Jan however, was able to
trigger it with greater ease ?
---Mike
Jack
On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsam...@sentex.net wrote:
On 2/1/2011 5:03 PM, Sean Bruno wrote:
On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
To those who are going to test, here is the if_em.c, based on head,
with my
changes, I have to leave for the afternoon, and have not had a
chance
to build
this, but it should work. I will check back in the later evening.
Any blatant problems Sean, feel free to fix them :)
Jack
I suspect that line 1490 should be:
if (more_rx || (ifp-if_drv_flags IFF_DRV_OACTIVE)) {
I have hacked up a RELENG_8 version which I think is correct including
the above change
http://www.tancsa.com/if_em-8.c
--- if_em.c.orig2011-02-01 21:47:14.0 -0500
+++ if_em.c 2011-02-01 21:47:19.0 -0500
@@ -30,7 +30,7 @@
POSSIBILITY OF SUCH DAMAGE.
**/
-/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
jfv Exp $*/
+/*$FreeBSD$*/
#ifdef HAVE_KERNEL_OPTION_HEADERS
#include opt_device_polling.h
@@ -93,7 +93,7 @@
/*
* Driver version:
*/
-char em_driver_version[] = 7.1.9;
+char em_driver_version[] = 7.1.9-test;
/*
* PCI Device ID Table
@@ -927,11 +927,10 @@
if (!adapter-link_active)
return;
-/* Call cleanup if number of TX descriptors low */
- if (txr-tx_avail= EM_TX_CLEANUP_THRESHOLD)
- em_txeof(txr);
-
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
+ /* First cleanup if TX descriptors low */
+ if (txr-tx_avail= EM_TX_CLEANUP_THRESHOLD)
+ em_txeof(txr);
if (txr-tx_avail EM_MAX_SCATTER) {
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
break;
@@ -1411,8 +1410,7 @@
if (!drbr_empty(ifp, txr-br))
em_mq_start_locked(ifp, txr, NULL);
#else
- if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
- em_start_locked(ifp, txr);
+ em_start_locked(ifp, txr);
#endif
EM_TX_UNLOCK(txr);
@@ -1475,11 +1473,10 @@
struct ifnet*ifp = adapter-ifp;
struct tx_ring *txr = adapter-tx_rings;
struct rx_ring *rxr = adapter-rx_rings;
- boolmore;
-
if (ifp-if_drv_flags IFF_DRV_RUNNING) {
- more = em_rxeof(rxr, adapter-rx_process_limit, NULL);
+ boolmore_rx;
+ more_rx = em_rxeof(rxr, adapter-rx_process_limit,
NULL);
EM_TX_LOCK(txr);
em_txeof(txr);
@@ -1487,12 +1484,10 @@
if (!drbr_empty(ifp, txr-br))
em_mq_start_locked(ifp, txr, NULL);
#else
- if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
- em_start_locked(ifp, txr);
+ em_start_locked(ifp, txr);
#endif
- em_txeof(txr);
EM_TX_UNLOCK(txr);
- if (more) {
+ if (more_rx || (ifp-if_drv_flags IFF_DRV_OACTIVE))
{
taskqueue_enqueue(adapter-tq,
adapter-que_task);
return;
}
@@ -1604,7 +1599,6 @@
if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
em_start_locked(ifp, txr);
#endif
- em_txeof(txr);
E1000_WRITE_REG(adapter-hw, E1000_IMS, txr-ims);
EM_TX_UNLOCK(txr);
Re: Debugging dropped shell connections over a VPN
On 07/07/11 14:39, Chuck Swiger wrote:
On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote:
My setup is something like this:
- My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris machines
running various OS versions.
- My gateway / firewall machine is running FreeBSD-8.1-RELEASE-p1 with ipfw,
nat and racoon for the firewall and VPN.
The problem is that rlogin, ssh and telnet connections over the VPN get dropped
after some period of inactivity.
You're probably getting NAT timeouts against the VPN connection if it is left
idle. racoon ought to have a config setting called natt_keepalive which sends
periodic keepalives-- see whether that's disabled.
Regards,
Thanks for the suggestions Chuck, sorry it's taken so long to respond
but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in
order to try this out.
One thing that I did not explicitly mention before is that I am routing
a network over the VPN.
I did not have previously NAT-Traversal enabled nor was it configured in
my kernel. After reconfiguring, compiling and installing the new
kernel, I added the following to the phase 1 configuration for my VPN:
timer
{
# Default is 20 seconds.
natt_keepalive 10 sec;
}
# Enable NAT traversal.
#nat_traversal on;
nat_traversal force;
# Enable IKE fragmentation.
ike_frag on;
# Enable ESP fragmentaion at 552 bytes.
esp_frag 552;
The only immediately noticeable change is that I am no longer getting
the following warnings at racoon startup:
WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): UDP_ENCAP
Invalid argument
I assume this is the result of adding IPSEC_NAT_T to the kernel config.
My shell connections are still being dropped, so I'm pretty much back to
square one.
So, any other ideas on how to debug this?
Anybody know how to get racoon to log everything to one file? Right
now, depending on the log level, I am getting messages in racoon.log
(specified with -l at startup), messages and debug.log. It would really
be nice to have just one log to look at.
--
Paul Keusemannpkeu...@visi.com
4266 Joppa Court (952) 894-7805
Savage, MN 55378
___
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: em driver, 82574L chip, and possibly ASPM
On 7/12/2011 3:03 PM, Hooman Fazaeli wrote: I have similar problems on a couple of 7.3 boxes with latest driver form -CURRENT. I just wanted to know if your 7 boxes work fine so I look for cause else where. Yes, all has been working quite well for me to date. em1@pci0:11:0:0:class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ed68a4 em1: Intel(R) PRO/1000 Network Connection 7.2.3 port 0x2000-0x201f mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: bce packet loss
There won't be any indication in the driver since flow control is managed in hardware. You'd need a wire capture to see that bce(4) has stopped sending frames in response to receiving an XOFF flow control frame or started sending frames in response to receiving an XON flow control frame. Ah. I was hoping for something in the ifconfig output. I'll see if tcpdump and wireshark can tell me anything about this host. Flow control frames are consumed by the MAC and aren't passed to the OS stack so you won't see them with a host based packet capture application like tcpdump. You'd need something like a JDSU Xgig protocol analyzer to see them on the wire. One the one host (w/bce) I just set to full auto, the switch claims to have negotiated 1000FD w/flow control (this specifically shows as auto+enabled on the switch side). I see that the sysctl dev.bce.1 tree has some info, and I can see that the NIC is receiving flow control frames: dev.bce.1.stat_XonPauseFramesReceived: 16638 dev.bce.1.stat_XoffPauseFramesReceived: 17239 These lines are a bit puzzling though: dev.bce.1.stat_FlowControlDone: 0 dev.bce.1.stat_XoffStateEntered: 0 Auto-negotiation occurs between PHYs and then the link comes up. When link is up bce(4) will configure the MAC based on the auto-neg results returned by brgphy(4) (the switch should follow a similar procedure on its side). Flow control occurs at the MAC level. It looks like the MAC is not configured to support flow control as negotiated by the PHY during auto-neg, resulting in flow control frames being ignored. The driver will set this in the MAC based on PHY results: http://fxr.watson.org/fxr/source/dev/bce/if_bce.c#L2046 Either the PHY results are coming back incorrectly or it may be firmware on bce(4) is disabling the behavior even though bce(4) correctly enables it. 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: Debugging dropped shell connections over a VPN
On Jul 12, 2011, at 12:26 PM, Paul Keusemann wrote: So, any other ideas on how to debug this? Gather data with tcpdump. If you do it on one of the VPN endpoints, you ought to see the VPN contents rather than just packets going by in the encrypted tunnel. Anybody know how to get racoon to log everything to one file? Right now, depending on the log level, I am getting messages in racoon.log (specified with -l at startup), messages and debug.log. It would really be nice to have just one log to look at. This is likely governed by /etc/syslog.conf, but if you specify -l then racoon shouldn't use syslog logging. Regards, -- -Chuck ___ 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/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks
The following reply was made to PR kern/152036; it has been noted by GNATS. From: Kelly Yancey kyan...@apple.com To: bug-follo...@freebsd.org Cc: Subject: Re: kern/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks Date: Tue, 12 Jul 2011 19:24:22 -0700 Thanks, now lets just change the category to kern to reflect=85oh, wait.= ___ 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
