Re: IPSEC NAT-T
On Sun, Nov 01, 2009 at 09:00:30AM -0800, Gabe wrote: > Hello, Hi. > What's the latest "stable" patch available for the latest 7.x source? Stable patches, to be used with ipsec-tools 0.7 branch, are available here: http://people.freebsd.org/~vanhu/NAT-T/ As we're working on backporting FreeBSD / ipsec-tools HEAD works on STABLE/7 branch, I haven't generated a new one for a while, let me know if the latest public patch has some issues. Yvan. ___ 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: IPSEC NAT-T
- Original Message > From: VANHULLEBUS Yvan > To: Gabe > Cc: freebsd-net@freebsd.org > Sent: Tue, November 3, 2009 2:41:14 AM > Subject: Re: IPSEC NAT-T > > On Sun, Nov 01, 2009 at 09:00:30AM -0800, Gabe wrote: > > Hello, > > Hi. > > > > What's the latest "stable" patch available for the latest 7.x source? > > Stable patches, to be used with ipsec-tools 0.7 branch, are available > here: > http://people.freebsd.org/~vanhu/NAT-T/ > > As we're working on backporting FreeBSD / ipsec-tools HEAD works on > STABLE/7 branch, I haven't generated a new one for a while, let me > know if the latest public patch has some issues. > > > Yvan. > ___ > 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" Yeah the latest patch did not work on the latest source, it would not allow make buildkernel to succeed. I worked around it by using the latest 7.2-RELEASE. ___ 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/138999: commit references a PR
The following reply was made to PR kern/138999; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/138999: commit references a PR
Date: Tue, 3 Nov 2009 12:52:49 + (UTC)
Author: kib
Date: Tue Nov 3 12:52:35 2009
New Revision: 198853
URL: http://svn.freebsd.org/changeset/base/198853
Log:
If socket buffer space appears to be lower then sum of count of already
prepared bytes and next portion of transfer, inner loop of kern_sendfile()
aborts, not preparing next mbuf for socket buffer, and not modifying
any outer loop invariants. The thread loops in the outer loop forever.
Instead of breaking from inner loop, prepare only bytes that fit into
the socket buffer space.
In collaboration with: pho
Reviewed by: bz
PR: kern/138999
MFC after: 2 weeks
Modified:
head/sys/kern/uipc_syscalls.c
Modified: head/sys/kern/uipc_syscalls.c
==
--- head/sys/kern/uipc_syscalls.c Tue Nov 3 12:03:13 2009
(r198852)
+++ head/sys/kern/uipc_syscalls.c Tue Nov 3 12:52:35 2009
(r198853)
@@ -2037,20 +2037,12 @@ retry_space:
rem = obj->un_pager.vnp.vnp_size -
uap->offset - fsbytes - loopbytes;
xfsize = omin(rem, xfsize);
+ xfsize = omin(space - loopbytes, xfsize);
if (xfsize <= 0) {
VM_OBJECT_UNLOCK(obj);
done = 1; /* all data sent */
break;
}
- /*
- * Don't overflow the send buffer.
- * Stop here and send out what we've
- * already got.
- */
- if (space < loopbytes + xfsize) {
- VM_OBJECT_UNLOCK(obj);
- break;
- }
/*
* Attempt to look up the page. Allocate
___
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"
Re: kern/140245: [ath] [panic] Kernel panic during network activity on device ath in 7.2-RELEASE-p4
Old Synopsis: Kernel panic during network activity on device ath in 7.2-RELEASE-p4 New Synopsis: [ath] [panic] Kernel panic during network activity on device ath in 7.2-RELEASE-p4 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 3 14:17:17 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140245 ___ 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: carp advskew not 'sticking'
On Nov 1, 2009, at 19:09, Ask Bjørn Hansen wrote: On a set of gw boxes I have 5 carp interfaces. 4 are working fine, but on one for some reason the advskew setting isn't "sticking" (and I get carp2: incorrect hash). I'm running 7.2-STABLE from a few days ago. gw-a# ifconfig carp2 vhid 12 advskew 100 pass abc123 10.0.100.1/24 gw-a# ifconfig carp2 carp2: flags=49 metric 0 mtu 1500 inet 10.0.100.1 netmask 0xff00 carp: BACKUP vhid 12 advbase 1 advskew 0 gw-b# ifconfig carp2 vhid 12 advskew 200 pass abc123 10.0.100.1/24 gw-b# ifconfig carp2 carp2: flags=49 metric 0 mtu 1500 inet 10.0.100.1 netmask 0xff00 carp: MASTER vhid 12 advbase 1 advskew 0 Hi everyone, Just for the sake of the archives: I'm not 100% sure, but I think this was caused by another set of boxes mistakenly on the same vlan with the same vhid. - ask___ 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"
DHCP client not getting IP address from Time Warner
Hi everyone, After years with Speakeasy at home I'm trying out Time Warner Cable (we live too far from the CO to get good DSL speeds). On OS X I plug-in and get an IP from their DHCP server: http://dl.getdropbox.com/u/25895/dhcp/dhcp-osx.txt On FreeBSD their DHCP server seems to just ignore me (but I see lots of broadcast replies to 255.255.255.255/ff:ff:ff:ff:ff:ff). I've tried with both the standard dhclient and the isc dhclient from ports. 00:00:24:c9:23:c1 is my FreeBSD box (Soekris 5501 with vr ethernet): http://dl.getdropbox.com/u/25895/dhcp/dhcp-freebsd.txt The OS X dump was made with dhcpdump 1.7 and sudo tcpdump -i en0 -s 1518 -lenx port bootps or port bootpc | ./ dhcpdump The FreeBSD one with "dhcpdump -i vr1". Below is a tcpdump of one of the DHCP requests. Any ideas would be greatly appreciated. - ask 15:46:02.424186 00:00:24:c9:23:c1 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:24:c9:23:c1, length 300 0x: 4510 0148 1011 a996 0x0010: 0044 0043 0134 43bb 0101 0600 0x0020: ea65 7a82 0x0030: 24c9 23c1 0x0040: 0x0050: 0x0060: 0x0070: 0x0080: 0x0090: 0x00a0: 0x00b0: 0x00c0: 0x00d0: 0x00e0: 0x00f0: 0x0100: 6382 5363 3501 013d 0x0110: 0701 24c9 23c1 0c05 6777 2d62 6e37 0x0120: 0801 1c02 7903 0f06 0cff 0x0130: 0x0140: ___ 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: DHCP client not getting IP address from Time Warner
Hello, The logs display something that I find very disturbing. In the dhcpdump log, the DHCPDISCOVER message your interface sends an erroneous MAC address, there is a "01:" that is added in front of the actual MAC address of your interface. What is sent in the discover message is "01:00:..." instead of "00:00:...". Then what happens explains itself : the DHCP server will send a DHCPOFFER by using the requesting client's MAC address, but since the given MAC address is wrong, he broadcasts it (which I don't think is the behaviour that is expected in normal cases...). I think this is also why the client doesn't emit a DHCPREQUEST (which is emitted by the client to confirm that it is choosing the proposed settings from the server, and implicitly turning down any other offers made by other servers). I'll look into it when I get back home (at work right now). If possible : could you try to connect your Time Warner cable with another interface ? Or the same one as the one you used under Mac OS X (that way we would see if we get the same behaviour, regardless of the network interface chosen) ? Kind regards, Aman Jassal Le Mar 3 novembre 2009 16:47, Ask Bjørn Hansen a écrit : > Hi everyone, > > > After years with Speakeasy at home I'm trying out Time Warner Cable > (we live too far from the CO to get good DSL speeds). > > > On OS X I plug-in and get an IP from their DHCP server: > > > http://dl.getdropbox.com/u/25895/dhcp/dhcp-osx.txt > > > On FreeBSD their DHCP server seems to just ignore me (but I see lots > of broadcast replies to 255.255.255.255/ff:ff:ff:ff:ff:ff). I've tried > with both the standard dhclient and the isc dhclient from ports. > > 00:00:24:c9:23:c1 is my FreeBSD box (Soekris 5501 with vr ethernet): > > > http://dl.getdropbox.com/u/25895/dhcp/dhcp-freebsd.txt > > > The OS X dump was made with dhcpdump 1.7 and > > > sudo tcpdump -i en0 -s 1518 -lenx port bootps or port bootpc | ./ dhcpdump > > > The FreeBSD one with "dhcpdump -i vr1". > > > Below is a tcpdump of one of the DHCP requests. > > > Any ideas would be greatly appreciated. > > > > - ask > > > > 15:46:02.424186 00:00:24:c9:23:c1 > ff:ff:ff:ff:ff:ff, ethertype IPv4 > (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from 00:00:24:c9:23:c1, length 300 > 0x: 4510 0148 1011 a996 > 0x0010: 0044 0043 0134 43bb 0101 0600 > 0x0020: ea65 7a82 > 0x0030: 24c9 23c1 > 0x0040: > 0x0050: > 0x0060: > 0x0070: > 0x0080: > 0x0090: > 0x00a0: > 0x00b0: > 0x00c0: > 0x00d0: > 0x00e0: > 0x00f0: > 0x0100: 6382 5363 3501 013d > 0x0110: 0701 24c9 23c1 0c05 6777 2d62 6e37 > 0x0120: 0801 1c02 7903 0f06 0cff > 0x0130: > 0x0140: > > > ___ > 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: DHCP client not getting IP address from Time Warner
Power-cycle your cable box, leaving it off for a few minutes. Cable co's seem to check the MAC, and take a while to forget the previous one. On Tue, Nov 03, 2009 at 07:47:14AM -0800, Ask Bjrn Hansen wrote: > Hi everyone, > > After years with Speakeasy at home I'm trying out Time Warner Cable > (we live too far from the CO to get good DSL speeds). > > On OS X I plug-in and get an IP from their DHCP server: > > http://dl.getdropbox.com/u/25895/dhcp/dhcp-osx.txt > > On FreeBSD their DHCP server seems to just ignore me (but I see lots > of broadcast replies to 255.255.255.255/ff:ff:ff:ff:ff:ff). I've > tried with both the standard dhclient and the isc dhclient from ports. ___ 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: DHCP client not getting IP address from Time Warner
On Nov 3, 2009, at 8:21, JASSAL Aman wrote:
Hello,
The logs display something that I find very disturbing.
In the dhcpdump log, the DHCPDISCOVER message your interface sends an
erroneous MAC address, there is a "01:" that is added in front of the
actual MAC address of your interface. What is sent in the discover
message
is "01:00:..." instead of "00:00:...".
Hi Aman,
Yeah - I should have pointed that out. I tried forcing it to be
correct with
interface "vr1" {
send dhcp-client-identifier 00:00:24:c9:23:c1;
}
to no effect.
http://dl.getdropbox.com/u/25895/dhcp/dhcp-freebsd-2.txt
Then what happens explains itself : the DHCP server will send a
DHCPOFFER
by using the requesting client's MAC address, but since the given MAC
address is wrong, he broadcasts it (which I don't think is the
behaviour
that is expected in normal cases...).
I thought the broadcasts were misguided responses to me, too, at first
-- but looking further I think it's just broadcasting when it's giving
(or not) IPs to other clients. I've no idea why it does that.
I only included one, but in http://dl.getdropbox.com/u/25895/dhcp/dhcp-osx.txt
you can see that on OS X I get the weird replies to
ff:ff:ff:ff:ff:ff, too.
I also noticed that OS X adds two extra options in the request:
OPTION: 57 ( 2) Maximum DHCP message size 1500
OPTION: 51 ( 4) IP address leasetime 7776000 (12w6d)
Just to test how can I make dhclient add those, too?
I think this is also why the client doesn't emit a DHCPREQUEST
(which is
emitted by the client to confirm that it is choosing the proposed
settings
from the server, and implicitly turning down any other offers made by
other servers).
I'll look into it when I get back home (at work right now). If
possible :
could you try to connect your Time Warner cable with another
interface ?
Or the same one as the one you used under Mac OS X (that way we
would see
if we get the same behaviour, regardless of the network interface
chosen)
?
The Soekris box only has vr interfaces; the OS X NIC is in my laptop
so unless I install FreeBSD on there I won't be able to test
that. :-) I did actually try one of the other vr interfaces on the
Soekris box with the same result (they work fine with isc-dhcp running
on another FreeBSD box).
- ask
___
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: DHCP client not getting IP address from Time Warner
On Nov 3, 2009, at 8:27, Barney Wolff wrote: Power-cycle your cable box, leaving it off for a few minutes. Cable co's seem to check the MAC, and take a while to forget the previous one. Hah - yeah, I tried that, too. No difference. (Plugging in one of the macs and then another seems to work fine, too). Thanks for the idea though. - ask ___ 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"
Small bug with TCP zero windows
Several years ago Dillon added a feature to TCP that casued soreceive() to send an ACK right away if data was drained from a TCP socket that had previously advertised a zero-sized window. The current code requires the receive window to be exactly zero for this to kick in. If window scaling is enabled and the window is smaller than the scale, then the effective window that is advertised is zero. However, in that case the zero-sized window handling is not enabled because the window is not exactly zero. The patch below changes the code to check the raw window value against zero. Arguably it could check 'th_win' directly instead if folks would prefer that. Index: tcp_output.c === --- tcp_output.c(revision 198794) +++ tcp_output.c(working copy) @@ -992,7 +992,7 @@ * to read more data than can be buffered prior to transmitting on * the connection. */ - if (recwin == 0) + if (recwin >> tp->rcv_scale == 0) tp->t_flags |= TF_RXWIN0SENT; else tp->t_flags &= ~TF_RXWIN0SENT; -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Small bug with TCP zero windows
On Tue, 3 Nov 2009, John Baldwin wrote: Several years ago Dillon added a feature to TCP that casued soreceive() to send an ACK right away if data was drained from a TCP socket that had previously advertised a zero-sized window. The current code requires the receive window to be exactly zero for this to kick in. If window scaling is enabled and the window is smaller than the scale, then the effective window that is advertised is zero. However, in that case the zero-sized window handling is not enabled because the window is not exactly zero. The patch below changes the code to check the raw window value against zero. Arguably it could check 'th_win' directly instead if folks would prefer that. hmm, looking a few lines up, there is a htons() there as well; obviously doesn't matter for 0. th_win is set to something different for SYNs. I guess what you are doing is ok, and even though it is not needed, I feel that it would be easier to read it with an extra pair of (). Index: tcp_output.c === --- tcp_output.c(revision 198794) +++ tcp_output.c(working copy) @@ -992,7 +992,7 @@ * to read more data than can be buffered prior to transmitting on * the connection. */ - if (recwin == 0) + if (recwin >> tp->rcv_scale == 0) tp->t_flags |= TF_RXWIN0SENT; else tp->t_flags &= ~TF_RXWIN0SENT; -- 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: Marvell 88E8057
On Tue, Nov 03, 2009 at 12:45:52AM -0500, kalin m wrote:
>
> hi pyun... and all
>
> after a few hours i'm sorry to report that the card is visible but not
> usable (yet?!). here is what i have done so far:
>
> 1. got the files from http://svn.freebsd.org/viewvc/base/head/sys/dev/
> 2. applied the patch that pyun provided.
> 3. replaced if_maddr_rlock(ifp) with IF_ADDR_UNLOCK(ifp) in if_msk.c -
> two instances.
> 4. replaced the files in /usr/src/sys/dev for mii and msk with he new
> ones on the freebsd 7.2 machine.
> 5. recompiled the kernel..
>
> here is what i get:
>
> from dmesg at boot:
>
> mskc0: port 0xde00-0xdeff mem
> 0xfddfc000-0xfddf irq 18 at device 0.0 on pci2
> mskc0: unknown device: id=0xba, rev=0x00
> device_attach: mskc0 attach returned 6
>
> cant find what 6 stands for but it's not good..
>
Sorry, there was a check that keep 88E8057 from attaching.
I've regenerated patch.
Index: sys/dev/msk/if_msk.c
===
--- sys/dev/msk/if_msk.c(revision 198812)
+++ sys/dev/msk/if_msk.c(working copy)
@@ -223,6 +223,8 @@
"Marvell Yukon 88E8071 Gigabit Ethernet" },
{ VENDORID_MARVELL, DEVICEID_MRVL_436C,
"Marvell Yukon 88E8072 Gigabit Ethernet" },
+ { VENDORID_MARVELL, DEVICEID_MRVL_4380,
+ "Marvell Yukon 88E8057 Gigabit Ethernet" },
{ VENDORID_DLINK, DEVICEID_DLINK_DGE550SX,
"D-Link 550SX Gigabit Ethernet" },
{ VENDORID_DLINK, DEVICEID_DLINK_DGE560SX,
@@ -237,7 +239,9 @@
"Yukon EX",
"Yukon EC",
"Yukon FE",
-"Yukon FE+"
+"Yukon FE+",
+"Yukon Supreme",
+"Yukon Ultra 2"
};
static int mskc_probe(device_t);
@@ -1144,6 +1148,7 @@
case CHIP_ID_YUKON_EC_U:
case CHIP_ID_YUKON_EX:
case CHIP_ID_YUKON_FE_P:
+ case CHIP_ID_YUKON_UL_2:
CSR_WRITE_2(sc, B0_CTST, Y2_HW_WOL_OFF);
/* Enable all clocks. */
@@ -1647,7 +1652,8 @@
sc->msk_hw_rev = (CSR_READ_1(sc, B2_MAC_CFG) >> 4) & 0x0f;
/* Bail out if chip is not recognized. */
if (sc->msk_hw_id < CHIP_ID_YUKON_XL ||
- sc->msk_hw_id > CHIP_ID_YUKON_FE_P) {
+ sc->msk_hw_id > CHIP_ID_YUKON_UL_2 ||
+ sc->msk_hw_id == CHIP_ID_YUKON_SUPR) {
device_printf(dev, "unknown device: id=0x%02x, rev=0x%02x\n",
sc->msk_hw_id, sc->msk_hw_rev);
mtx_destroy(&sc->msk_mtx);
@@ -1746,6 +1752,10 @@
sc->msk_clock = 156;/* 156 Mhz */
sc->msk_pflags |= MSK_FLAG_JUMBO;
break;
+ case CHIP_ID_YUKON_UL_2:
+ sc->msk_clock = 156;/* 156 Mhz */
+ sc->msk_pflags |= MSK_FLAG_JUMBO;
+ break;
default:
sc->msk_clock = 156;/* 156 Mhz */
break;
Index: sys/dev/msk/if_mskreg.h
===
--- sys/dev/msk/if_mskreg.h (revision 198812)
+++ sys/dev/msk/if_mskreg.h (working copy)
@@ -144,6 +144,7 @@
#define DEVICEID_MRVL_436A 0x436A
#define DEVICEID_MRVL_436B 0x436B
#define DEVICEID_MRVL_436C 0x436C
+#define DEVICEID_MRVL_4380 0x4380
/*
* D-Link gigabit ethernet device ID
@@ -891,6 +892,8 @@
#define CHIP_ID_YUKON_EC 0xb6 /* Chip ID for YUKON-2 EC */
#define CHIP_ID_YUKON_FE 0xb7 /* Chip ID for YUKON-2 FE */
#define CHIP_ID_YUKON_FE_P 0xb8 /* Chip ID for YUKON-2 FE+ */
+#define CHIP_ID_YUKON_SUPR 0xb9 /* Chip ID for YUKON-2 Supreme */
+#define CHIP_ID_YUKON_UL_2 0xba /* Chip ID for YUKON-2 Ultra 2 */
#defineCHIP_REV_YU_XL_A0 0 /* Chip Rev. for Yukon-2 A0 */
#defineCHIP_REV_YU_XL_A1 1 /* Chip Rev. for Yukon-2 A1 */
___
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"
