dhclient doing DISCOVER with bad IP checksum - bge
Sorry for the cross-post, but this could be either lists problem. I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make world. The server is refusing to answer the DISCOVER request, as it thinks the IP checksum is wrong, which tcpdump also confirms. Other DHCP clients are working fine on this network, so I do not believe it to be the network, server or dhcpd. Server is running a 2 Port Intel card - em driver. Client is a Dell PE1750 with 2 onboard NIC's - bge driver. I have tried turning off both RXCSUM and TXCSUM on both the client and server machines with no luck. I also tried the second NIC on the server with the same result. This setup was working just a couple of weeks ago, and the only thing that has changed is updating the src for a make world. PXE booting this server does result in an IP being issued, so it is pointing towards something new/changed in 7-STABLE. I have attached a 3 packet dump of the DISCOVER requests. Can anybody shed some light on this for me? Thanks, -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. dhclient_badcsum.cap Description: Binary data ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/129219 net[ppp] Kernel panic when using kernel mode ppp o kern/129135 netvge driver on a VIA mini-ITX not working f kern/129074 net[ppp] [panic] kernel panic with pppoe_server o kern/128917 net[wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net[msk] if_msk page fault while in kernel mode o kern/128840 net[igb] page fault under load with igb/LRO o kern/128833 net[bge] Network packets corrupted when bge card is in 64 o bin/128602 net[an] wpa_supplicant(8) crashes with an(4) o kern/128598 net[bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net[nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net[request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net[patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net[ip6] [panic] Fatal Trap 12 in ip6_forward = o kern/128181 net[fxp] panic in fxp_add_rfabuf o conf/128030 net[request] Isn't it time to enable IPsec in GENERIC? o bin/128001 netwpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net[tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net[ixgbe] [patch] wrong error counting o kern/127826 net[iwi] iwi0 driver has reduced performance and connecti o kern/127815 net[gif] [patch] if_gif does not set vlan attributes from o kern/127724 net[rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 netarp: Segmentation fault (core dumped) s kern/127587 net[bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net[icmp]: icmp socket receives icmp replies not owned by o bin/127192 netrouted(8) removes the secondary alias IP of interface f kern/127145 net[wi]: prism (wi) driver crash at bigger traffic o kern/127102 net[wpi] Intel 3945ABG low throughput o kern/127057 net[udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net[carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net[carp][patch] add carp userland notifications via devc o kern/126945 net[carp] CARP interface destruction with ifconfig destro o kern/126924 net[an] [patch] printf -> device_printf and simplify prob o kern/126895 net[patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net[vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 netwpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net[carp] CARP interface renaming makes system no longer o kern/126695 netrtfree messages and network disruption upon use of if_ o kern/126688 net[ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net[ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net[nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net[ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net[fxp] [panic] fxp(4) related kernel panic o kern/126339 net[ipw] ipw driver drops the connection o kern/126214 net[ath] txpower problem with Atheros wifi card o kern/126075 net[in] Network: internet control accesses beyond end of o bin/125922 net[patch] Deadlock in arp(8) o kern/125920 net[arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net[netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net[carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net[ral] ifconfig ral0 scan produces no output unless in o kern/125258 net[socket] socket's SO_REUSEADDR option does not work o kern/125239 net[gre] kernel crash when using gre f kern/125195 net[fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net[ppp] host routes added by ppp with gateway flag (regr o kern/124904 net[fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net[iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net[ieee80211] net80211 discards power-save queue packets o kern/124609 net[ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net[ral] promiscuous mode for wireless device ral0 looses o kern/124160 net[libc] connect(2) function loops indefinitely o kern/124127 net[msk] watchdog timeout (mi
FreeBSD 7.1 tcp problem (syncache)?
Hi,
We was using one machine with FreeBSD 6.4-RELEASE running
apache-worker-2.2.3 + mysql, this server can answer high request from
one client using ab:
{client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE
...
Benchmarking * (be patient)
Completed 200 requests
Completed 400 requests
Completed 600 requests
Completed 800 requests
Completed 1000 requests
Completed 1200 requests
Completed 1400 requests
Completed 1600 requests
Completed 1800 requests
Finished 2000 requests
...
{client}$
Using other hardware whit FreeBSD 7.1-PRERELEASE running
apache-worker-2.2.9_5 + mysql, we have a poor result:
{client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE
...
Test aborted after 10 failures
apr_connect(): Invalid argument (22)
{client}$
Looking for a problem on new server log we found:
kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry (possibly
syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry (possibly
syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry (possibly
syncookie only), segment ignored
All sysctl and apache conf are same on both server, is there a tcp
problem with FreeBSD 7.x?
Paulo Fragoso.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1 tcp problem (syncache)?
Paulo Fragoso wrote:
>
> Using other hardware whit FreeBSD 7.1-PRERELEASE running
> apache-worker-2.2.9_5 + mysql, we have a poor result:
>
>
> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE
> ...
> Test aborted after 10 failures
>
> apr_connect(): Invalid argument (22)
> {client}$
The important thing is what operating system is used on the machine
running "ab", in both cases. "ab" is known to be broken with FreeBSD so
if you run "ab" on FreeBSD, you'll get various problems.
signature.asc
Description: OpenPGP digital signature
Re: FreeBSD 7.1 tcp problem (syncache)?
Paulo Fragoso wrote:
Hi,
We was using one machine with FreeBSD 6.4-RELEASE running
apache-worker-2.2.3 + mysql, this server can answer high request from
one client using ab:
{client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE
...
Benchmarking * (be patient)
Completed 200 requests
Completed 400 requests
Completed 600 requests
Completed 800 requests
Completed 1000 requests
Completed 1200 requests
Completed 1400 requests
Completed 1600 requests
Completed 1800 requests
Finished 2000 requests
...
{client}$
Using other hardware whit FreeBSD 7.1-PRERELEASE running
apache-worker-2.2.9_5 + mysql, we have a poor result:
{client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE
...
Test aborted after 10 failures
apr_connect(): Invalid argument (22)
{client}$
Looking for a problem on new server log we found:
kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry (possibly
syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry (possibly
syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry (possibly
syncookie only), segment ignored
This error is harmless and occurs when the client closes the socket
before the TCP session has terminated. The RST have crossed and hit
the syncache. The same happens on 6.4 but it never told you about it.
All sysctl and apache conf are same on both server, is there a tcp
problem with FreeBSD 7.x?
Are you using the HTTP accept filter on the server? This may cause
the listen accept queue to overflow.
Please post the output of "netstat -n -s -p tcp" to further diagnose
the problem.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1 tcp problem (syncache)?
Em 01/12/2008 11:42, Andre Oppermann escreveu:
Paulo Fragoso wrote:
Hi,
We was using one machine with FreeBSD 6.4-RELEASE running
apache-worker-2.2.3 + mysql, this server can answer high request from
one client using ab:
{client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE
...
Benchmarking * (be patient)
Completed 200 requests
Completed 400 requests
Completed 600 requests
Completed 800 requests
Completed 1000 requests
Completed 1200 requests
Completed 1400 requests
Completed 1600 requests
Completed 1800 requests
Finished 2000 requests
...
{client}$
Using other hardware whit FreeBSD 7.1-PRERELEASE running
apache-worker-2.2.9_5 + mysql, we have a poor result:
{client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE
...
Test aborted after 10 failures
apr_connect(): Invalid argument (22)
{client}$
Looking for a problem on new server log we found:
kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry
(possibly syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry
(possibly syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry
(possibly syncookie only), segment ignored
This error is harmless and occurs when the client closes the socket
before the TCP session has terminated. The RST have crossed and hit
the syncache. The same happens on 6.4 but it never told you about it.
Ok, but we can not understand why same solution fails using FreeBSD 7.1
and works fina with
All sysctl and apache conf are same on both server, is there a tcp
problem with FreeBSD 7.x?
Are you using the HTTP accept filter on the server? This may cause
the listen accept queue to overflow.
No.
server-7.1# kldstat
Id Refs AddressSize Name
14 0x8010 b302e0 kernel
21 0xa3391000 8eba ipfw.ko
31 0xa33fe000 1ea green_saver.ko
server-7.1#
server-6.4# kldstat
Id Refs AddressSize Name
14 0x8010 a380f0 kernel
21 0x979f 8566 ipfw.ko
31 0x97a35000 1dd green_saver.ko
server-6.4#
Please post the output of "netstat -n -s -p tcp" to further diagnose
the problem.
netstat output from two servers was attached.
Our tests are based on 08 ab tests, changing -n and -c parameters at
client machine, starting with:
ab -n 100 -c 10 http://server/path_to_cgi
and finishing with:
ab -n 5000 -c 1000 http://server/path_to_cgi
The old server using FreeBSD-6.4 and running on worst hardware can
answer all request with some errors:
FreeBSD 6.4:
ab -n -c
100 10
1000 10 (8 errors)
1000 50 (12 errors)
1000 100 (12 errors)
1000 500 (11 errors)
2000 500 (24 errors)
2000 1000 (24 errors)
5000 1000 (4997 errors)
but we can not receive any answer for two last test using server-7.1
FreeBSD 7.1:
ab -n -c
100 10 (1 error)
1000 10 (5 errors)
1000 50 (7 errors)
1000 100 (8 errors)
1000 500 (11 errors)
2000 500 (15 errors)
2000 1000 no answer
5000 1000 no answer
ab return this error on test machine:
--
Test aborted after 10 failures
apr_connect(): Invalid argument (22)
--
Is there a new limit in FreeBSD-7.1?
Paulo Fragoso
server-7.1# netstat -n -s -p tcp
tcp:
75063 packets sent
31728 data packets (27702356 bytes)
2 data packets (1864 bytes) retransmitted
0 data packets unnecessarily retransmitted
0 resends initiated by MTU discovery
34657 ack-only packets (9002 delayed)
0 URG only packets
0 window probe packets
142 window update packets
8532 control packets
80919 packets received
28917 acks (for 15918245 bytes)
9425 duplicate acks
0 acks for unsent data
26168 packets (3681069 bytes) received in-sequence
893 completely duplicate packets (76110 bytes)
0 old duplicate packets
15 packets with some dup. data (1770 bytes duped)
60 out-of-order packets (86880 bytes)
10 packets (0 bytes) of data after window
0 window probes
3323 window update packets
2 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 discarded due to memory problems
3 connection requests
11907 connection accepts
0 bad co
Re: FreeBSD 7.1 tcp problem (syncache)?
Our machine test have apache-2.0.61_2 running FreeBSD-6.3-RELEASE-p3,
its ab program is used on all tests.
Paulo.
On 01/12/2008 12:18, Petri Helenius wrote:
I couldn't get Apache 2.2 ab to work on 7.0 at all. The ab from 2.0
worked fine...
Pete
Andre Oppermann wrote:
Paulo Fragoso wrote:
Hi,
We was using one machine with FreeBSD 6.4-RELEASE running
apache-worker-2.2.3 + mysql, this server can answer high request
from one client using ab:
{client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE
...
Benchmarking * (be patient)
Completed 200 requests
Completed 400 requests
Completed 600 requests
Completed 800 requests
Completed 1000 requests
Completed 1200 requests
Completed 1400 requests
Completed 1600 requests
Completed 1800 requests
Finished 2000 requests
...
{client}$
Using other hardware whit FreeBSD 7.1-PRERELEASE running
apache-worker-2.2.9_5 + mysql, we have a poor result:
{client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE
...
Test aborted after 10 failures
apr_connect(): Invalid argument (22)
{client}$
Looking for a problem on new server log we found:
kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry
(possibly syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry
(possibly syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry
(possibly syncookie only), segment ignored
This error is harmless and occurs when the client closes the socket
before the TCP session has terminated. The RST have crossed and hit
the syncache. The same happens on 6.4 but it never told you about it.
All sysctl and apache conf are same on both server, is there a tcp
problem with FreeBSD 7.x?
Are you using the HTTP accept filter on the server? This may cause
the listen accept queue to overflow.
Please post the output of "netstat -n -s -p tcp" to further diagnose
the problem.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1 tcp problem (syncache)?
I couldn't get Apache 2.2 ab to work on 7.0 at all. The ab from 2.0
worked fine...
Pete
Andre Oppermann wrote:
Paulo Fragoso wrote:
Hi,
We was using one machine with FreeBSD 6.4-RELEASE running
apache-worker-2.2.3 + mysql, this server can answer high request from
one client using ab:
{client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE
...
Benchmarking * (be patient)
Completed 200 requests
Completed 400 requests
Completed 600 requests
Completed 800 requests
Completed 1000 requests
Completed 1200 requests
Completed 1400 requests
Completed 1600 requests
Completed 1800 requests
Finished 2000 requests
...
{client}$
Using other hardware whit FreeBSD 7.1-PRERELEASE running
apache-worker-2.2.9_5 + mysql, we have a poor result:
{client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE
...
Test aborted after 10 failures
apr_connect(): Invalid argument (22)
{client}$
Looking for a problem on new server log we found:
kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry
(possibly syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry
(possibly syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry
(possibly syncookie only), segment ignored
This error is harmless and occurs when the client closes the socket
before the TCP session has terminated. The RST have crossed and hit
the syncache. The same happens on 6.4 but it never told you about it.
All sysctl and apache conf are same on both server, is there a tcp
problem with FreeBSD 7.x?
Are you using the HTTP accept filter on the server? This may cause
the listen accept queue to overflow.
Please post the output of "netstat -n -s -p tcp" to further diagnose
the problem.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Window updates
Hi Andre, When delayed Ack is set the window update is not sent. Does this mean when odd number of packets are received and later read, a window update won't go out either till the next segment arrives or 200 msecs delayed ack timer ? Can this reduced window block the sender from sending the next segment that we are waiting for to open up the window ? What's the purpose of the 2 MSS check by the way ? Venkat From: Andre Oppermann <[EMAIL PROTECTED]> To: David Malone <[EMAIL PROTECTED]> Cc: Rui Paulo <[EMAIL PROTECTED]>; freebsd-net@freebsd.org; Venkat Venkatsubra <[EMAIL PROTECTED]>; Kevin Oberman <[EMAIL PROTECTED]> Sent: Sunday, November 30, 2008 5:18:22 PM Subject: Re: FreeBSD Window updates Andre Oppermann wrote: > David Malone wrote: >> I've got an example extract tcpdump of this at the end of the mail >> - here 6 ACKs are sent, 5 of which are pure window updates and >> several are 2us apart! >> >> I think the easy option is to delete the code that generates explicit >> window updates if the window moves by 2*MSS. We then should be doing >> something similar to Linux. The other easy alternative would be to >> add a sysclt that lets us generate an window update every N*MSS and >> by default set it to something big, like 10 or 100. That should >> effectively eliminate the updates during bulk data transfer, but >> may still generate some window updates after a loss. > > The main problem of the pure window update test in tcp_output() is > its complete ignorance of delayed ACKs. Second is the strict 4.4BSD > adherence to sending an update for every window increase of >= 2*MSS. > The third issue of sending a slew of window updates after having > received a FIN (telling us the other end won't ever send more data) > I have already fixed some moons ago. > > In my new-tcp work I've come across the window update logic some time > ago and backchecked with relevant RFCs and other implementations. > Attached is a compiling but otherwise untested backport of the new logic. Slightly improved version attached. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1 tcp problem (syncache)?
On Mon, 2008-12-01 at 10:53 -0300, Paulo Fragoso wrote:
> Hi,
>
> We was using one machine with FreeBSD 6.4-RELEASE running
> apache-worker-2.2.3 + mysql, this server can answer high request from
> one client using ab:
>
>
> {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE
> ...
> Benchmarking * (be patient)
> Completed 200 requests
> Completed 400 requests
> Completed 600 requests
> Completed 800 requests
> Completed 1000 requests
> Completed 1200 requests
> Completed 1400 requests
> Completed 1600 requests
> Completed 1800 requests
> Finished 2000 requests
> ...
> {client}$
>
>
> Using other hardware whit FreeBSD 7.1-PRERELEASE running
> apache-worker-2.2.9_5 + mysql, we have a poor result:
>
>
> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE
> ...
> Test aborted after 10 failures
>
> apr_connect(): Invalid argument (22)
> {client}$
>
>
> Looking for a problem on new server log we found:
>
> kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4;
> syncache_chkrst: Spurious RST without matching syncache entry (possibly
> syncookie only), segment ignored
> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
> syncache_chkrst: Spurious RST without matching syncache entry (possibly
> syncookie only), segment ignored
> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
> syncache_chkrst: Spurious RST without matching syncache entry (possibly
> syncookie only), segment ignored
>
> All sysctl and apache conf are same on both server, is there a tcp
> problem with FreeBSD 7.x?
>
> Paulo Fragoso.
>
Just to rule it out, have you tried testing using a more robust tool
than ab? ab is generally disliked by the apache devs I've met. Does it
still fall over using something like siege[1] or flood[2]?
Cheers
Tom
[1] http://www.joedog.org/JoeDog/Siege
[2] http://httpd.apache.org/test/flood/
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Window updates
Hi Andre, > Slightly improved version attached. I like the idea of checking if the change is about 1 when scaled by the window scaling factor. It might even be better to check if the new window would look better when scaled down, because these aren't exactly the same. Especially when the window is small. > + * If the receive socket buffer has less than 1/4 of space > + * available and if the difference is at least two max size > + * segments, send an immediate window update to peer. I'm worried that this might leave us still being too aggressive in sending these updates. The "change by a factor of two" check might be - it will send lots of updates if the window is small (and at risk of closing) but won't send frequent pure updates if the window is big. This shouldn't be a problem because if the window is big then either: 1) there's lots of data in flight, which will naturally generate ACKs to keep the sender updated or 2) there's not much data in flight, in which case the window should be in no danger of getting too small. If we keep a rule like this, it might be better to make the limit >= 3*MSS, rather than >= 2*MSS, as I think this will tend to piggy back updates on the delayed ACK naturally (though I haven't tested this). > + * Otherwise if the difference is 1/8 (or more) of the receive > + * socket buffer, or at least 1/2 of the maximum possible window, > + * then we send a window update too. What's the motivation here? David. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1 tcp problem (syncache)?
On 01/12/2008 12:41, Tom Evans wrote:
On Mon, 2008-12-01 at 10:53 -0300, Paulo Fragoso wrote:
Hi,
We was using one machine with FreeBSD 6.4-RELEASE running
apache-worker-2.2.3 + mysql, this server can answer high request from
one client using ab:
{client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE
...
Benchmarking * (be patient)
Completed 200 requests
Completed 400 requests
Completed 600 requests
Completed 800 requests
Completed 1000 requests
Completed 1200 requests
Completed 1400 requests
Completed 1600 requests
Completed 1800 requests
Finished 2000 requests
...
{client}$
Using other hardware whit FreeBSD 7.1-PRERELEASE running
apache-worker-2.2.9_5 + mysql, we have a poor result:
{client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE
...
Test aborted after 10 failures
apr_connect(): Invalid argument (22)
{client}$
Looking for a problem on new server log we found:
kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry (possibly
syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry (possibly
syncookie only), segment ignored
kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4;
syncache_chkrst: Spurious RST without matching syncache entry (possibly
syncookie only), segment ignored
All sysctl and apache conf are same on both server, is there a tcp
problem with FreeBSD 7.x?
Paulo Fragoso.
Just to rule it out, have you tried testing using a more robust tool
than ab? ab is generally disliked by the apache devs I've met. Does it
still fall over using something like siege[1] or flood[2]?
Cheers
Tom
[1] http://www.joedog.org/JoeDog/Siege
[2] http://httpd.apache.org/test/flood/
We have tried siege because similar to ab configuration, but we have
problem to repeat our ab tests:
client$ siege -b -r1000 -c10 http://system_using_7.1-PRERELEASE
HTTP/1.1 200 0.05 secs:1948 bytes ==> /cgi-bin/path_to_program
HTTP/1.1 200 0.04 secs:1948 bytes ==> /cgi-bin/path_to_program
HTTP/1.1 200 0.05 secs:1948 bytes ==> /cgi-bin/path_to_program
Segmentation fault: 11 (core dumped)
same problem is happening trying old url:
http://system_using_6.4-RELEASE. Have you had some advice?
We are using ab since 2004 to make a historical reference for our tests
for different hardware and systems.
Why using same hardware to run ab we can test one server running
6.4-RELEASE but fails to teste 7.1-PRERELEASE? New way to answer request
in 7.1 can crash ab at another machine? We are suspecting there is a new
limit in 7.x which not clear for us yet.
Paulo.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Window updates
Venkat Venkatsubra wrote: Hi Andre, When delayed Ack is set the window update is not sent. Does this mean when odd number of packets are received and later read, a window update won't go out either till the next segment arrives or 200 msecs delayed ack timer ? Can this reduced window block the sender from sending the next segment that we are waiting for to open up the window ? Yes. The very idea of delayed ACK is to reduce the network utilization by ACKing only every other segment. Window updates should not override this as they currently do. Nagle comes into plays as well where we wait for the application to write something within the delayed ACK timeout to piggyback the answer together with the ACK (and window update). To answer your question: I do think we are fine with waiting for the delayed ACK. If an application starts to seriously lag behind like in your example the feedback mechanism should work and cause the sender to slow down too. The feedback loop in TCP is not only the network but also the sending and receiving application. In a normal bulk transfer where the receiving application services the receive buffer in regular intervals we update the window with every ACK. I'm open to other ideas if they fix the problem David is seeing without having more serious shortcomings. What's the purpose of the 2 MSS check by the way ? This is part of the Silly Window Syndrome prevention. A good description is here: http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm PS: Attached is an updated version of the patch. The flag TF_DELACK can't be used to test for the presence of a delayed ACK. The presence of the delack timer has to be tested. -- Andre Venkat From: Andre Oppermann <[EMAIL PROTECTED]> To: David Malone <[EMAIL PROTECTED]> Cc: Rui Paulo <[EMAIL PROTECTED]>; freebsd-net@freebsd.org; Venkat Venkatsubra <[EMAIL PROTECTED]>; Kevin Oberman <[EMAIL PROTECTED]> Sent: Sunday, November 30, 2008 5:18:22 PM Subject: Re: FreeBSD Window updates Andre Oppermann wrote: David Malone wrote: I've got an example extract tcpdump of this at the end of the mail - here 6 ACKs are sent, 5 of which are pure window updates and several are 2us apart! I think the easy option is to delete the code that generates explicit window updates if the window moves by 2*MSS. We then should be doing something similar to Linux. The other easy alternative would be to add a sysclt that lets us generate an window update every N*MSS and by default set it to something big, like 10 or 100. That should effectively eliminate the updates during bulk data transfer, but may still generate some window updates after a loss. The main problem of the pure window update test in tcp_output() is its complete ignorance of delayed ACKs. Second is the strict 4.4BSD adherence to sending an update for every window increase of >= 2*MSS. The third issue of sending a slew of window updates after having received a FIN (telling us the other end won't ever send more data) I have already fixed some moons ago. In my new-tcp work I've come across the window update logic some time ago and backchecked with relevant RFCs and other implementations. Attached is a compiling but otherwise untested backport of the new logic. Slightly improved version attached. Index: tcp_output.c === RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.158 diff -u -p -r1.158 tcp_output.c --- tcp_output.c27 Nov 2008 13:19:42 - 1.158 +++ tcp_output.c1 Dec 2008 21:06:28 - @@ -539,29 +539,59 @@ after_sack_rexmit: } /* -* Compare available window to amount of window -* known to peer (as advertised window less -* next expected input). If the difference is at least two -* max size segments, or at least 50% of the maximum possible -* window, then want to send a window update to peer. +* Compare available window to amount of window known to peer +* (as advertised window less next expected input) and decide +* if we have to send a pure window update segment. +* +* When a delayed ACK is scheduled, do nothing. It will update +* the window anyway in a few milliseconds when the: +* - next segment arrives we have to ack immediately; +* - application sends some data back to the peer; +* - delayed ACK timer expires. +* +* If the receive socket buffer has less than 1/4 of space +* available and if the difference is at least two max size +* segments, send an immediate window update to peer. +* +* Otherwise if the difference is 1/8 (or more) of the receive +* socket buffer, or at least 1/2 of the maximum possible window, +* then we send a window update too. +* * Skip this if the co
Re: Gathering Hardware State During a Driver Initiated Kernel Panic
On Monday 24 November 2008 04:56:22 pm Sam Leffler wrote: > David Christensen wrote: > > Is there a method or callback in FreeBSD where a driver can > > be notified that it has caused a kernel panic in order to > > generate a dump of internal hardware state information? I've > > written a sysctl call for manual intervention and can handle > > some "expected" hardware events completely in the driver but > > I don't know of a way to get control again in cases where the > > driver wasn't expecting a failure. > > > > Not sure how one can deduce a driver is at fault but you might define a > ddb command for the driver and invoke that on panic using the ddb script > mechanisms (see ddb(4)). You might be able to set the current 'panic' ddb script function to one you define in your code somehow. That is, set it on entry to bce_start() and then reset it to empty when bce_start() returns. Similarly for the interrupt handler, bce_init(), and bce_ioctl(). I haven't looked to see if there is a clean way to set a script function in C though. -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Window updates
Hi Andre, >To answer your question: I do think we are fine with waiting for the >delayed ACK. If an application starts to seriously lag behind like >in your example the feedback mechanism should work and cause the sender >to slow down too. The feedback loop in TCP is not only the network but The case I was thinking was not apps lagging behind on the read. The incoming packets got ahead and got dumped on the socket receive buffer before the app's blocked read could get scheduled by the OS and start reading the data. I am assuming the read needs the socket lock and it has to contend for this lock with the incoming packets. The stack may not have any control over when the read eventually gets to run. Suppose it runs after the 13th incoming packet got copied to the socket buffer and the window size is 13 MSS ? > > What's the purpose of the 2 MSS check by the way ? >This is part of the Silly Window Syndrome prevention. A good description is >here: Even without the 2 MSS check you are going to prevent SWS, isn't that right ? The other checks will make sure small window updates are not sent. Venkat From: Andre Oppermann <[EMAIL PROTECTED]> To: Venkat Venkatsubra <[EMAIL PROTECTED]> Cc: David Malone <[EMAIL PROTECTED]>; Rui Paulo <[EMAIL PROTECTED]>; Kevin Oberman <[EMAIL PROTECTED]>; freebsd-net@freebsd.org Sent: Monday, December 1, 2008 3:11:43 PM Subject: Re: FreeBSD Window updates Venkat Venkatsubra wrote: > Hi Andre, > > When delayed Ack is set the window update is not sent. > Does this mean when odd number of packets are received and later read, > a window update won't go out either till the next segment arrives or > 200 msecs delayed ack timer ? Can this reduced window block the sender from > sending the next segment that we are waiting for to open up the window ? Yes. The very idea of delayed ACK is to reduce the network utilization by ACKing only every other segment. Window updates should not override this as they currently do. Nagle comes into plays as well where we wait for the application to write something within the delayed ACK timeout to piggyback the answer together with the ACK (and window update). To answer your question: I do think we are fine with waiting for the delayed ACK. If an application starts to seriously lag behind like in your example the feedback mechanism should work and cause the sender to slow down too. The feedback loop in TCP is not only the network but also the sending and receiving application. In a normal bulk transfer where the receiving application services the receive buffer in regular intervals we update the window with every ACK. I'm open to other ideas if they fix the problem David is seeing without having more serious shortcomings. > What's the purpose of the 2 MSS check by the way ? This is part of the Silly Window Syndrome prevention. A good description is here: http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm PS: Attached is an updated version of the patch. The flag TF_DELACK can't be used to test for the presence of a delayed ACK. The presence of the delack timer has to be tested. -- Andre > Venkat > > > > > From: Andre Oppermann <[EMAIL PROTECTED]> > To: David Malone <[EMAIL PROTECTED]> > Cc: Rui Paulo <[EMAIL PROTECTED]>; freebsd-net@freebsd.org; Venkat > Venkatsubra <[EMAIL PROTECTED]>; Kevin Oberman <[EMAIL PROTECTED]> > Sent: Sunday, November 30, 2008 5:18:22 PM > Subject: Re: FreeBSD Window updates > > Andre Oppermann wrote: >> David Malone wrote: >>> I've got an example extract tcpdump of this at the end of the mail >>> - here 6 ACKs are sent, 5 of which are pure window updates and >>> several are 2us apart! >>> >>> I think the easy option is to delete the code that generates explicit >>> window updates if the window moves by 2*MSS. We then should be doing >>> something similar to Linux. The other easy alternative would be to >>> add a sysclt that lets us generate an window update every N*MSS and >>> by default set it to something big, like 10 or 100. That should >>> effectively eliminate the updates during bulk data transfer, but >>> may still generate some window updates after a loss. >> The main problem of the pure window update test in tcp_output() is >> its complete ignorance of delayed ACKs. Second is the strict 4.4BSD >> adherence to sending an update for every window increase of >= 2*MSS. >> The third issue of sending a slew of window updates after having >> received a FIN (telling us the other end won't ever send more data) >> I have already fixed some moons ago. >> >> In my new-tcp work I've come across the window update logic some time >> ago and backchecked with relevant RFCs and other implementations. >> Attached is a compiling but otherwise untested backport of the new logic. > > Slightly improved version attached. > ___ freebsd-net@freebsd.org
Re: kern/129352: [xl] [patch] xl0 watchdog timeout
Old Synopsis: xl0 watchdog timeout New Synopsis: [xl] [patch] xl0 watchdog timeout Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 1 22:53:23 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/122743: [panic] vm_page_unwire: invalid wire count: 0
The following reply was made to PR kern/122743; it has been noted by GNATS. From: Anton Yuzhaninov <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/122743: [panic] vm_page_unwire: invalid wire count: 0 Date: Tue, 02 Dec 2008 02:00:40 +0300 It looks like similar to this: http://docs.freebsd.org/cgi/mid.cgi?492B2F46.9000709 Try to change type for wire_count in struct vm_page from u_short to u_int (on i386 it has some overhead - sizeof(vm_page) increased by 4 bytes). -- Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6
2008/12/1 Pyun YongHyeon <[EMAIL PROTECTED]>: > On Sun, Nov 30, 2008 at 03:18:41AM +, Andrew Tulloch wrote: > > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > > following when the re driver attempts to attach to the two onboard > > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > > > re0: > Ethernet> port 0x9e00-0x9eff mem > > 0xfd3ff000-0xfd3f,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > > pci8 > > re0: Chip rev. 0x2800 > > re0: MAC rev. 0x0010 > > re0: Unknown H/W revision: 0x2800 > > device_attach: re0 attach returned 6 > > pcib9: irq 17 at device 28.5 on pci0 > > pci9: on pcib9 > > re1: > Ethernet> port 0x8e00-0x8eff mem > > 0xfd1ff000-0xfd1f,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on > > pci9 > > re1: Chip rev. 0x2800 > > re1: MAC rev. 0x0010 > > re1: Unknown H/W revision: 0x2800 > > device_attach: re1 attach returned 6 > > > > pciconf -lvc extract: > > [EMAIL PROTECTED]:8:0:0: class=0x02 card=0xe0001458 > chip=0x816810ec rev=0x03 hdr=0x00 > > vendor = 'Realtek Semiconductor' > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > class = network > > subclass = ethernet > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit > > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > > cap 03[cc] = VPD > > [EMAIL PROTECTED]:9:0:0: class=0x02 card=0xe0001458 > chip=0x816810ec rev=0x03 hdr=0x00 > > vendor = 'Realtek Semiconductor' > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > class = network > > subclass = ethernet > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit > > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > > cap 03[cc] = VPD > > > > > > Is there any simple patch I can apply to get the driver to attach, > > assuming it should work? > > > > This controller seems to support MSI-X with 4 messages. > Unfortunately previous PCIe controllers from RealTek were notorious > for MSI issues so it's hard to know this revision really works with > MSI-X. I guess it was added to support RSS(receive-side scaling of > MS NDIS 6.0). > As sephe said if the controller configuration is the same as 8168C > family, the attached patch would make re(4) work as expected. > > -- > Regards, > Pyun YongHyeon > Pyun, I applied the patch, but it didn't attach initially, I added an extra entry to re_hwrevs as that seemed to be what was missing and it attached and seems to function (as far as a quick ping test and make update). Changes I made to if_re.c attached. If you have anything to try for MSI-X I can probably test those. Thanks, Andrew re.patch Description: Binary data ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6
On Tue, Dec 02, 2008 at 12:50:07AM +, Andrew wrote: > 2008/12/1 Pyun YongHyeon <[EMAIL PROTECTED]>: > > On Sun, Nov 30, 2008 at 03:18:41AM +, Andrew Tulloch wrote: > > > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > > > following when the re driver attempts to attach to the two onboard > > > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > > > > > re0: > > Ethernet> port 0x9e00-0x9eff mem > > > 0xfd3ff000-0xfd3f,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > > > pci8 > > > re0: Chip rev. 0x2800 > > > re0: MAC rev. 0x0010 > > > re0: Unknown H/W revision: 0x2800 > > > device_attach: re0 attach returned 6 > > > pcib9: irq 17 at device 28.5 on pci0 > > > pci9: on pcib9 > > > re1: > > Ethernet> port 0x8e00-0x8eff mem > > > 0xfd1ff000-0xfd1f,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on > > > pci9 > > > re1: Chip rev. 0x2800 > > > re1: MAC rev. 0x0010 > > > re1: Unknown H/W revision: 0x2800 > > > device_attach: re1 attach returned 6 > > > > > > pciconf -lvc extract: > > > [EMAIL PROTECTED]:8:0:0: class=0x02 card=0xe0001458 > > chip=0x816810ec rev=0x03 hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > > class = network > > > subclass = ethernet > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > cap 05[50] = MSI supports 1 message, 64 bit > > > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > > > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > > > cap 03[cc] = VPD > > > [EMAIL PROTECTED]:9:0:0: class=0x02 card=0xe0001458 > > chip=0x816810ec rev=0x03 hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > > class = network > > > subclass = ethernet > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > cap 05[50] = MSI supports 1 message, 64 bit > > > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > > > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > > > cap 03[cc] = VPD > > > > > > > > > Is there any simple patch I can apply to get the driver to attach, > > > assuming it should work? > > > > > > > This controller seems to support MSI-X with 4 messages. > > Unfortunately previous PCIe controllers from RealTek were notorious > > for MSI issues so it's hard to know this revision really works with > > MSI-X. I guess it was added to support RSS(receive-side scaling of > > MS NDIS 6.0). > > As sephe said if the controller configuration is the same as 8168C > > family, the attached patch would make re(4) work as expected. > > > > -- > > Regards, > > Pyun YongHyeon > > > > Pyun, > I applied the patch, but it didn't attach initially, I added an extra > entry to re_hwrevs as that seemed to be what was missing and it > attached and seems to function (as far as a quick ping test and make > update). Changes I made to if_re.c attached. If you have anything to > try for MSI-X I can probably test those. > You're right. I've missed to update revision entry. :-) I guess MSI-X requires a documentation from RealTek as it may have to map interrupt source to MSI-X vectors. It may also need to map PBA to MSI-X work on 8168D. Would you show me dmesg output of re(4)? Thanks for the patch and testing! -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[ipsec]could you help me explain where problem is for aes-ctr of ESP
Hello, all: following is my setkey configration. I can get SAD and SPD. but when I run " ping6 -I rl0 3ffe:501::103:20a:ebff:fe85:9e56 " on FreeBSD FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must be multiple of 16 kernel: decrypt fail in IPv6 ESP input : SA(SPI 8192 src=3ffe:0501::0103:020a:ebff:fe85:9e56 dst=3ffe:0501::0104:021d:0fff:fe19:59fc) but when I use "ping6 -I rl0 -s 4(or 6 or 20) 3ffe:501::103:20a:ebff:fe85:9e56" that the report disappear. I read RFC, did not find the explain. could you give me a explain? Thanks on RedHat (ipsec-tools 0.6.5) #!/sbin/setkey -f flush; spdflush; add 3ffe:501::104:21d:fff:fe19:59fc 3ffe:501::103:20a:ebff:fe85:9e56 esp 0x1000 -m transport -E aes-ctr "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; spdadd 3ffe:501::104:21d:fff:fe19:59fc 3ffe:501::103:20a:ebff:fe85:9e56 any -P in ipsec esp/transport//require; add 3ffe:501::103:20a:ebff:fe85:9e56 3ffe:501::104:21d:fff:fe19:59fc esp 0x2000 -m transport -E aes-ctr "ipv6readylogoaes1to2" -A hmac-sha1 "ipv6readylogsha11to2"; spdadd 3ffe:501::103:20a:ebff:fe85:9e56 3ffe:501::104:21d:fff:fe19:59fc any -P out ipsec esp/transport//require; on FreeBSD6.3(ipsec-tools 0.7, using 0.6.6, problem keep still ) flush; spdflush; add 3ffe:501::103:20a:ebff:fe85:9e56 3ffe:501::104:21d:fff:fe19:59fc esp 0x2000 -m transport -E aes-ctr "ipv6readylogoaes1to2" -A hmac-sha1 "ipv6readylogsha11to2"; spdadd 3ffe:501::103:20a:ebff:fe85:9e56 3ffe:501::104:21d:fff:fe19:59fc any -P in ipsec esp/transport//require; add 3ffe:501::104:21d:fff:fe19:59fc 3ffe:501::103:20a:ebff:fe85:9e56 esp 0x1000 -m transport -E aes-ctr "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; spdadd 3ffe:501::104:21d:fff:fe19:59fc 3ffe:501::103:20a:ebff:fe85:9e56 any -P out ipsec esp/transport//require; ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[ipsec] why did not freebsd6.3 support icmp6 echo request on tunnel mode ? it is ok on transport mode.
Hello, all: the following configuration is my setkey info. when I run " setkey -f filename", system report "the result of line 4 :Invalid argument. the result of line 6 : Invalid argument." change "icmp6 128,0" to "icmp6 or any" , that is no problem . or change "tunnel" to "transport" , that is no problem. I do not know why , but the following configuration is no problem on RHEL5.2 that FreeBSD6.3 need patch ? could you give me explain Thank you very much flush; spdflush; add 3ffe:501::103:20a:ebff:fe85:9e56 3ffe:501::104:21d:fff:fe19:59fc esp 0x2000 -m tunnel -E 3des-cbc "ipv6readylogo3des1to2req" -A hmac-sha1 “ipv6readysha11to2req”; spdadd 3ffe:501::103:20a:ebff:fe85:9e56 3ffe:501::104:21d:fff:fe19:59fc icmp6 128,0 -P in ipsec esp/tunnel/3ffe:501::103:20a:ebff:fe85:9e56-3ffe:501::104:21d:fff:fe19:59fc/require; add 3ffe:501::104:21d:fff:fe19:59fc 3ffe:501::103:20a:ebff:fe85:9e56 esp 0x1000 -m tunnel -E 3des-cbc "ipv6readylogo3des2to1req" -A hmac-sha1 “ipv6readysha12to1req”; spdadd 3ffe:501::104:21d:fff:fe19:59fc 3ffe:501::103:20a:ebff:fe85:9e56 icmp6 128,0 -P out ipsec esp/tunnel/3ffe:501::104:21d:fff:fe19:59fc-3ffe:501::103:20a:ebff:fe85:9e56/require; ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[ipsec] aes-ctr question
Hello, all: following is my setkey configration. I can get SAD and SPD. but when I run " ping6 -I rl0 3ffe:501::103:20a:ebff:fe85:9e56 " on FreeBSD FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must be multiple of 16 kernel: decrypt fail in IPv6 ESP input : SA(SPI 8192 src=3ffe:0501::0103:020a:ebff:fe85:9e56 dst=3ffe:0501::0104:021d:0fff:fe19:59fc) but when I use "ping6 -I rl0 -s 11(or 12 or 13 or 14) 3ffe:501::103:20a:ebff:fe85:9e56" that the ping pass. I read RFC, did not find the explain. could you give me a explain? Thanks flush; spdflush; add 3ffe:501::103:20a:ebff:fe85:9e56 3ffe:501::104:21d:fff:fe19:59fc esp 0x1000 -m tunnel -E aes-ctr "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; spdadd 3ffe:501::103:20a:ebff:fe85:9e56 3ffe:501::104:21d:fff:fe19:59fc any -P in ipsec esp/tunnel/3ffe:501::103:20a:ebff:fe85:9e56-3ffe:501::104:21d:fff:fe19:59fc/require; add 3ffe:501::104:21d:fff:fe19:59fc 3ffe:501::103:20a:ebff:fe85:9e56 esp 0x2000 -m tunnel -E aes-ctr "ipv6readylogoaes1to2" -A hmac-sha1 "ipv6readylogsha11to2"; spdadd 3ffe:501::104:21d:fff:fe19:59fc 3ffe:501::103:20a:ebff:fe85:9e56 any -P out ipsec esp/tunnel/3ffe:501::104:21d:fff:fe19:59fc-3ffe:501::103:20a:ebff:fe85:9e56/require; ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??)
Can someone please confirm or rule out my issue with dhclient sending bad IP checksum packets. It would really suck if 7.1 was released with a broken DHCP client. Jonathan Feally wrote: Sorry for the cross-post, but this could be either lists problem. I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make world. The server is refusing to answer the DISCOVER request, as it thinks the IP checksum is wrong, which tcpdump also confirms. Other DHCP clients are working fine on this network, so I do not believe it to be the network, server or dhcpd. Server is running a 2 Port Intel card - em driver. Client is a Dell PE1750 with 2 onboard NIC's - bge driver. I have tried turning off both RXCSUM and TXCSUM on both the client and server machines with no luck. I also tried the second NIC on the server with the same result. This setup was working just a couple of weeks ago, and the only thing that has changed is updating the src for a make world. PXE booting this server does result in an IP being issued, so it is pointing towards something new/changed in 7-STABLE. I have attached a 3 packet dump of the DISCOVER requests. Can anybody shed some light on this for me? Thanks, -Jon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??)
On Tuesday 02 December 2008 15:57:15 Jonathan Feally wrote: > Can someone please confirm or rule out my issue with dhclient sending > bad IP checksum packets. It would really suck if 7.1 was released with a > broken DHCP client. I had 7.1-PRE (early Octover) send out DHCP requests without issue, although I don't have that system available now. It was using em card. I have a 7.0-STABLE system with an sk card from July that does DHCP requests just fine too.. I don't have any bge systems running 7 to test with though sorry.. Does it always give dud packets or just DHCP? Can you try another card in the client? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
