6.2-RELENG/7.0-CURRENT: em(4) fails on 82571EB
many thanks for your feedback jack you might well be right with the problems popping up when using a bunch of 571's ...anyway - its just that on 6.1-RELENG we never had a problem with the 571's [ You say no traffic works, on NONE of the ports?? Do you have anyway to disable part of them? Do the 541's work? ] the 541's work - the problem affects only the 571's will try to disable some of the 571's in the bios today [I need more debugging, assign address to em0, instrument it however you need to] i can do that - plus kernel recompilation/patching and testing whatever you might need i can provide you access to the box over internet if you like [does anything get transmitted] as far as i remember this causes some 'watchdog - timer' messages because of the transmit buffer not being emptied not checked recently - will do this today [what interrupt handling is done, etc etc...] as far as i remember *only* link up/down interrupt is working - recieve interrupts 'fails'. will test this for transmit today for transmit not checked recently - will insert a printf into em_intr/em_fast_intr today to check this rgds, pat Ursprüngliche Nachricht Von: [EMAIL PROTECTED] Datum: 09.07.2007 19:36 An: <[EMAIL PROTECTED]> Kopie: Betreff: Re: 6.2-RELENG/7.0-CURRENT: em(4) fails on 82571EB The 82571 device has been supported for a long time, the trick comes when you have a gang of them how the thing is all wired up, we have had issues even with our quad port adapters and some vendor BIOS's. This is a custom so I'm only going to be able to guess that its interrupts. You say no traffic works, on NONE of the ports?? Do you have anyway to disable part of them? Do the 541's work? I need more debugging, assign address to em0, instrument it however you need to, does anything get transmitted, what interrupt handling is done, etc etc... Jack On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > hello everybody > i encountered some problems with the intel 82571EB chipset when i > tried to upgrade from FreeBSD 6.1-RELENG to 6.2-RELENG/7.0- CURRENT on > a network appliance (NEXCOM 1108GL) > the appliance has 3 different intel ethernet controllers soldered > to the motherboard > E1000_DEV_ID_82541GI 0x1076 > E1000_DEV_ID_82571EB_COPPER 0x105E > E1000_DEV_ID_82571EB_SERDES 0x1060 > current intel driver version: > 6.5.3 (from 7.0-CURRENT) > > problem description: > chipset initialisation seems to work OK > ifconfig displays the devices / link state seems to be OK > 'ifconfig up' and 'tcpdump' are NOK (>no packets recieved on > interface - leds indicate packet reception) > interrupts seem to be OK (link up/down triggers em_intr on 6.2- > RELENG - behaviour on 7.0-CURRENT unknown yet) > > affected releases: > it seems to be the same problem on 6.2-RELENG/7.0-CURRENT > 6.1-RELENG works fine... > > anyone interested in tracking this down...? > any experience with this behaviour @intel? > i have a server in the lab which is ready to act as a guinea pig > for tests/paches... > --- > rgds, pat > > freebsd# uname -a > FreeBSD freebsd.sharedtcs.net 7.0-CURRENT-200706 > FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 > > freebsd# pciconf -l | grep em > [EMAIL PROTECTED]:0:0: class=0x02 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > [EMAIL PROTECTED]:0:1: class=0x02 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > [EMAIL PROTECTED]:0:0: class=0x02 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > [EMAIL PROTECTED]:0:1: class=0x02 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > [EMAIL PROTECTED]:0:0: class=0x02 card=0x10761903 chip=0x10608086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. ext. SERDES > for SFP modules) > [EMAIL PROTECTED]:0:1: class=0x02 card=0x10761903 chip=0x10608086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. ext. SERDES > for SFP modules) > [EMAIL PROTECTED]:0:0: class=0x02 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > [EMAIL PROTECTED]:0:1: class=0x02 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > [EMAIL PROTECTED]:7:0: class=0x02 card=0x10761903 chip=0x10768086 > rev=0x05 hdr=0x00 (82541EI Gigabit Ethernet Controller w. int. PHY) > [EMAIL PROTECTED]:9:0: class=0x02 card=0x10761903 chip=0x10768086 > rev=0x05 hdr=0x00 (82541EI Gigabit Ethernet Controller w. int. PHY) > > freebsd# cat /var/run/dmesg.boot > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > The Rege
Re: Problems with BCE network adapter (Dell PE2950)
Tom Judge wrote:
David Christensen wrote:
Sorry for the top post, please try following patch:
http://people.freebsd.org/~sephe/if_bce.c.diff
This is probably the cause; I noticed it when bce(4) was ported to
DragonFly.
Thanks Sephe, I think you're on to something. I have some
debug code in the driver to simulate mbuf allocation
failures and when I enable that I start receiving the same
error messages Tom reported (along with various kernel
panics), but when I include your change the system seems
to keep humming along.
I'll certainly add your code into an update shortly.
Dave
I'm not going to have a chance to test this patch until next week but I
will let you know what the results are.
Tom
So here goes, after 2 days testing we have come up with the following data.
The configuration
[PE[12]950] > [PowerConnect 5324]
The system is running 8192 byte Jumbo Frames.
sultan# ifconfig bce0
bce0: flags=8847 mtu 8192
options=3b
inet 172.31.0.28 netmask 0xff00 broadcast 172.31.0.255
inet 172.31.0.163 netmask 0x broadcast 172.31.0.163
ether 00:19:b9:e4:4d:cc
media: Ethernet autoselect (1000baseTX )
status: active
After applying both David and Sephe's patches I have yet to get a system
in a state where it is stable with jumbo frames enabled, the systems
crash almost immediately after the switch changes the port state
(Spanning tree) from LEARNING to FORWARDING. The output from this crash
can be found attached as crash-1.txt.gz.
If the frame size is left at 1500 then the interface seems stable,
however I can't fully test this as the interface is connected to a GigE
only network with an mtu of 8192.
If BCE_DEBUG is remove from if_bcereg.h then the system just exhibits
the original problem and may or may not crash.
The next test was to try the kernel with BCE_DEBUG and with the
following extra patch (so that the driver does not jump to the
breakpoint when an unexpected mbuf is found in the rx buffer).
--- if_bce.c(revision 62)
+++ if_bce.c(revision 66)
@@ -4050,7 +4050,8 @@
DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)),
BCE_PRINTF("%s(%d): Unexpected mbuf
found in rx_bd[0x%04X]!\n",
__FILE__, __LINE__, sw_chain_cons);
- bce_breakpoint(sc));
+ bce_dump_mbuf(sc, m));
+// bce_breakpoint(sc));
/*
* ToDo: If the received packet is small enough
With this patch the system boots and does not crash straight away,
however it is almost completely unusable. The output with this kernel
can be found attached as crash-2.txt.gz. Also this causes the following
new error message:
fgrep -n leak crash-2.txt
3194:bce0: /usr/src/sys/dev/bce/if_bce.c(3842): Memory leak! Lost 114
mbufs from rx chain!
Has no one else come across this problem, or are Jumbo frames not widely
used?
Tom
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf 4.1 Update available for testing
On Tuesday 10 July 2007, Henrik Brix Andersen wrote: > Hi, > > On Sat, Jun 16, 2007 at 03:47:24AM +0200, Max Laier wrote: > > To make testing easier I'm working on RELENG_6 patches as well, but > > it will be a bit to get through the fix/build/repeat-cycles. > > I can't seem to locate the patches for RELENG_6 on > http://people.freebsd.org/~mlaier/PF41/ - are they available for > testing? Oh ... forgot about that ... there are several problems with that. First of all RELENG_6 is missing the interface group infrastructure which is essential to pf now. This makes it difficult to produce patches. I could do it, but ... > Do you plan on MFC'ing pf-4.1 to RELENG_6 before RELENG_6_3 is > branched? ... it can never be MFCed due to the ABI breakage in several essential places (ifnet and pf ioctls). There is some work going on in OpenBSD 4.2 to reduce userland ABI changes in the future, but for now updating pf means breaking ABIs means no MFC unfortunately. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pf 4.1 Update available for testing
Hi Max, On Tue, Jul 10, 2007 at 03:20:05PM +0200, Max Laier wrote: > On Tuesday 10 July 2007, Henrik Brix Andersen wrote: > Oh ... forgot about that ... there are several problems with that. First > of all RELENG_6 is missing the interface group infrastructure which is > essential to pf now. This makes it difficult to produce patches. I > could do it, but ... I see. > > Do you plan on MFC'ing pf-4.1 to RELENG_6 before RELENG_6_3 is > > branched? > > ... it can never be MFCed due to the ABI breakage in several essential > places (ifnet and pf ioctls). > > There is some work going on in OpenBSD 4.2 to reduce userland ABI changes > in the future, but for now updating pf means breaking ABIs means no MFC > unfortunately. Ah, of course - didn't think of that. Guess we'll just have to wait for 7.0 to hit the streets, then :) Thank you for working on this. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> pgpTK16GTOvpw.pgp Description: PGP signature
Re: pf 4.1 Update available for testing
Hi, On Sat, Jun 16, 2007 at 03:47:24AM +0200, Max Laier wrote: > To make testing easier I'm working on RELENG_6 patches as well, but it > will be a bit to get through the fix/build/repeat-cycles. I can't seem to locate the patches for RELENG_6 on http://people.freebsd.org/~mlaier/PF41/ - are they available for testing? Do you plan on MFC'ing pf-4.1 to RELENG_6 before RELENG_6_3 is branched? Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> pgpPGq2G49nFQ.pgp Description: PGP signature
Re: FreeBSD 7 TCP syncache fix: request for testers
Mike, good day. Tue, Jul 10, 2007 at 12:20:49AM -0500, Mike Silbersack wrote: > Anyway, the attached patch simplifies the syncache structure a bit and > makes it retransmit properly. I'd appreciate testing from anyone who > has experienced TCP problems with FreeBSD 7, as well as anyone who is > pushing significant traffic through FreeBSD 7. Can't say that I am pushing much traffic through my box, but after applying your patch and rebuilding the kernel I am still seeing the messages like - TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags 0x19; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: Response timeout - But what had changed is that the lines with the 'syncache_timer' started to appear. There were no such lines prior to the patch, only the 'failed SYNCOOKIE' ones. But the patch received only half a day of testing, so I will continue the tests and will inform you if some other information will be available. Up to date I don't see problems that had appeared without the patch, but they tend to show up after a midnight ;)) Thank you! -- Eygene ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with BCE network adapter (Dell PE2950)
Tom Judge wrote:
Tom Judge wrote:
David Christensen wrote:
Sorry for the top post, please try following patch:
http://people.freebsd.org/~sephe/if_bce.c.diff
This is probably the cause; I noticed it when bce(4) was ported to
DragonFly.
Thanks Sephe, I think you're on to something. I have some
debug code in the driver to simulate mbuf allocation
failures and when I enable that I start receiving the same
error messages Tom reported (along with various kernel
panics), but when I include your change the system seems
to keep humming along. I'll certainly add your code into an update
shortly.
Dave
I'm not going to have a chance to test this patch until next week but
I will let you know what the results are.
Tom
So here goes, after 2 days testing we have come up with the following
data.
The configuration
[PE[12]950] > [PowerConnect 5324]
The system is running 8192 byte Jumbo Frames.
sultan# ifconfig bce0
bce0: flags=8847 mtu 8192
options=3b
inet 172.31.0.28 netmask 0xff00 broadcast 172.31.0.255
inet 172.31.0.163 netmask 0x broadcast 172.31.0.163
ether 00:19:b9:e4:4d:cc
media: Ethernet autoselect (1000baseTX )
status: active
After applying both David and Sephe's patches I have yet to get a system
in a state where it is stable with jumbo frames enabled, the systems
crash almost immediately after the switch changes the port state
(Spanning tree) from LEARNING to FORWARDING. The output from this crash
can be found attached as crash-1.txt.gz.
If the frame size is left at 1500 then the interface seems stable,
however I can't fully test this as the interface is connected to a GigE
only network with an mtu of 8192.
If BCE_DEBUG is remove from if_bcereg.h then the system just exhibits
the original problem and may or may not crash.
The next test was to try the kernel with BCE_DEBUG and with the
following extra patch (so that the driver does not jump to the
breakpoint when an unexpected mbuf is found in the rx buffer).
--- if_bce.c(revision 62)
+++ if_bce.c(revision 66)
@@ -4050,7 +4050,8 @@
DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)),
BCE_PRINTF("%s(%d): Unexpected mbuf
found in rx_bd[0x%04X]!\n",
__FILE__, __LINE__, sw_chain_cons);
- bce_breakpoint(sc));
+ bce_dump_mbuf(sc, m));
+// bce_breakpoint(sc));
/*
* ToDo: If the received packet is small enough
With this patch the system boots and does not crash straight away,
however it is almost completely unusable. The output with this kernel
can be found attached as crash-2.txt.gz. Also this causes the following
new error message:
fgrep -n leak crash-2.txt
3194:bce0: /usr/src/sys/dev/bce/if_bce.c(3842): Memory leak! Lost 114
mbufs from rx chain!
Has no one else come across this problem, or are Jumbo frames not widely
used?
Tom
It would seem that the crash can be simulated just by increasing the MTU
above 1500 (tested in single user mode).
Tom
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mpd isn't listening on 1723 because he can't get it thhough it isn't used
Hello, I want to set up a VPN server on a freebsd machine so Windows clients can use it. I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. When I run mpd I get this: mpd Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 11377, version 3.18 ([EMAIL PROTECTED] 10:10 8-Jul-2007) [bundle1] ppp node is "mpd11377-bundle1" mpd: bind: Can't assign requested address mpd: can't get PPTP listening socket mpd: bind: Can't assign requested address mpd: can't get PPTP listening socket [bundle1] using interface ng0 Of course since he couldn't get a hold of port 1723 he couldn't establish a socket and nothing happens. netstat shows no one is listening on 1723: netstat -a | fgrep LIS tcp4 0 0 freebsd2.ssh montreal.50547 ESTABLISHED tcp4 0 0 freebsd2.ssh montreal.61574 ESTABLISHED tcp4 0 0 *.ssh *.*LISTEN tcp6 0 0 *.ssh *.*LISTEN tcp4 0 0 *.smtp *.*LISTEN tcp6 0 0 *.nfsd *.*LISTEN tcp4 0 0 *.nfsd *.*LISTEN tcp6 0 0 *.636 *.*LISTEN tcp4 0 0 *.637 *.*LISTEN tcp4 0 0 *.sunrpc *.*LISTEN tcp6 0 0 *.sunrpc *.*LISTEN There is no other instance of mpd running Here are the mpd conf and link files: default: load pptp1conf # load pptp2conf pptp1conf: new -i ng0 bundle1 pptp1 set ipcp ranges 192.168.1.103/32 192.168.1.200/32 load common #pptp2conf: # new -i ng1 bundle2 pptp2 # set ipcp ranges 192.168.1.103/32 192.168.1.201/32 # load common common: set iface disable on-demand set iface enable proxy-arp set iface idle 0 set iface enable tcpmssfix set bundle enable multilink set link enable acfcomp protocomp set link no pap chap set link enable chap # set link mtu 1460 set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 208.67.222.222 208.67.220.220 #set ipcp nbns 172.20.1.1 172.20.1.8 #set bundle enable compression #set ccp yes mppc #set ccp yes mpp-e40 #set ccp yes mpp-e128 #set ccp yes mpp-stateless pptp1: set link type pptp set pptp self 82.238.41.134 500 set pptp enable incoming set pptp disable originate pptp2: set link type pptp set pptp self 82.238.41.134 set pptp enable incoming set pptp disable originate As usual, all help appreciated Bernard Higonnet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
newbie problems mpd server on freebsd
Hello,
I want to set up a VPN server on a freebsd machine so Windows clients can use
it.
I am using FreeBSD 6.1 and mpd 3.18 from the ports collection.
My basic problem is that mpd does not do anything and doesn't complain about
anything, so I'm not making much progress.
I run mpd with "mpd -k -s higvpn"
Here are various facts and/or symptoms
1) all the show commands show there isn't anything (bundles, links, etc. etc.)
2) netstat says nobody's listening on 1723
3) Windows VPN's produce error 678 ("There was no answer") which seems
consonant with (2)
4) I can't find any trace info anywhere
5) there is no firewall issue because the freebsd vpn server and Windows
machine are both on my own little network (192.168.0) and neither machine has
one for the time being
In an effort to embarrass myself here is my mpd.conf file
default:
load pptp1
load pptp2
pptp1:
new -i ng0 pptp1 pptp1
load common
pptp2:
new -i ng1 pptp2 pptp2
load common
common:
set iface disable on-demand
set iface enable proxy-arp
set iface idle 0
set iface enable tcpmssfix
set bundle enable multilink
set link enable acfcomp protocomp
set link no pap chap
set link enable chap
set link keep-alive 10 60
set ipcp yes vjcomp
set ipcp ranges 82.238.41.134/32 192.168.0.201/24
set ipcp dns 208.67.222.222 208.67.220.220
#set ipcp nbns 172.20.1.1 172.20.1.8
#set bundle enable compression
#set ccp yes mppc
#set ccp yes mpp-e40
#set ccp yes mpp-e128
#set ccp yes mpp-stateless
TIA
Bernard Higonnet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with BCE network adapter (Dell PE2950)
Tom Judge wrote:
Tom Judge wrote:
Tom Judge wrote:
David Christensen wrote:
Sorry for the top post, please try following patch:
http://people.freebsd.org/~sephe/if_bce.c.diff
This is probably the cause; I noticed it when bce(4) was ported to
DragonFly.
Thanks Sephe, I think you're on to something. I have some
debug code in the driver to simulate mbuf allocation
failures and when I enable that I start receiving the same
error messages Tom reported (along with various kernel
panics), but when I include your change the system seems
to keep humming along. I'll certainly add your code into an update
shortly.
Dave
I'm not going to have a chance to test this patch until next week but
I will let you know what the results are.
Tom
So here goes, after 2 days testing we have come up with the following
data.
The configuration
[PE[12]950] > [PowerConnect 5324]
The system is running 8192 byte Jumbo Frames.
sultan# ifconfig bce0
bce0: flags=8847 mtu 8192
options=3b
inet 172.31.0.28 netmask 0xff00 broadcast 172.31.0.255
inet 172.31.0.163 netmask 0x broadcast 172.31.0.163
ether 00:19:b9:e4:4d:cc
media: Ethernet autoselect (1000baseTX )
status: active
After applying both David and Sephe's patches I have yet to get a
system in a state where it is stable with jumbo frames enabled, the
systems crash almost immediately after the switch changes the port
state (Spanning tree) from LEARNING to FORWARDING. The output from
this crash can be found attached as crash-1.txt.gz.
If the frame size is left at 1500 then the interface seems stable,
however I can't fully test this as the interface is connected to a
GigE only network with an mtu of 8192.
If BCE_DEBUG is remove from if_bcereg.h then the system just exhibits
the original problem and may or may not crash.
The next test was to try the kernel with BCE_DEBUG and with the
following extra patch (so that the driver does not jump to the
breakpoint when an unexpected mbuf is found in the rx buffer).
--- if_bce.c(revision 62)
+++ if_bce.c(revision 66)
@@ -4050,7 +4050,8 @@
DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)),
BCE_PRINTF("%s(%d): Unexpected mbuf
found in rx_bd[0x%04X]!\n",
__FILE__, __LINE__, sw_chain_cons);
- bce_breakpoint(sc));
+ bce_dump_mbuf(sc, m));
+// bce_breakpoint(sc));
/*
* ToDo: If the received packet is small enough
With this patch the system boots and does not crash straight away,
however it is almost completely unusable. The output with this kernel
can be found attached as crash-2.txt.gz. Also this causes the
following new error message:
fgrep -n leak crash-2.txt
3194:bce0: /usr/src/sys/dev/bce/if_bce.c(3842): Memory leak! Lost 114
mbufs from rx chain!
Has no one else come across this problem, or are Jumbo frames not
widely used?
Tom
It would seem that the crash can be simulated just by increasing the MTU
above 1500 (tested in single user mode).
Ok so I think I have fix the problem with the rx_bd tracking. I have
ported rboyer's patch to NetBSD's bnx driver to FreeBSD (patch
attached). The patch seems to get rid of two problems:
1) Unexpected mbuf in rx_bd
2) Too many free rx_bd's
However I am still faced with the problem of frames with missing
ethernet headers:
bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found.
Min(60), Actual(0), Max(9022)
bce0: mbuf: vaddr = 0xFF00:7B69AC00, m_len = 9216, m_flags = ( M_EXT
M_PKTHDR ) m_data = 0x:86F76000
0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
bce0: - m_pkthdr: flags = ( ) csum_flags = ( )
bce0: - m_ext: vaddr = 0x:86F76000, ext_size = 9216, type =
EXT_JUMBO9
bce0: discard frame w/o leading ethernet header (len 4294967292 pkt len
4294967292)
bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found.
Min(60), Actual(0), Max(9022)
bce0: mbuf: vaddr = 0xFF00:5EB48B00, m_len = 9216, m_flags = ( M_EXT
M_PKTHDR ) m_data = 0x:86F73000
0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0
Re: mpd isn't listening on 1723 because he can't get it thhough it isn't used
Bernard T. Higonnet wrote: Hello, I want to set up a VPN server on a freebsd machine so Windows clients can use it. I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. When I run mpd I get this: mpd Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 11377, version 3.18 ([EMAIL PROTECTED] 10:10 8-Jul-2007) [bundle1] ppp node is "mpd11377-bundle1" mpd: bind: Can't assign requested address mpd: can't get PPTP listening socket mpd: bind: Can't assign requested address mpd: can't get PPTP listening socket [bundle1] using interface ng0 Of course since he couldn't get a hold of port 1723 he couldn't establish a socket and nothing happens. netstat shows no one is listening on 1723: netstat -a | fgrep LIS tcp4 0 0 freebsd2.ssh montreal.50547 ESTABLISHED tcp4 0 0 freebsd2.ssh montreal.61574 ESTABLISHED tcp4 0 0 *.ssh *.*LISTEN tcp6 0 0 *.ssh *.*LISTEN tcp4 0 0 *.smtp *.*LISTEN tcp6 0 0 *.nfsd *.*LISTEN tcp4 0 0 *.nfsd *.*LISTEN tcp6 0 0 *.636 *.*LISTEN tcp4 0 0 *.637 *.*LISTEN tcp4 0 0 *.sunrpc *.*LISTEN tcp6 0 0 *.sunrpc *.*LISTEN There is no other instance of mpd running Here are the mpd conf and link files: default: load pptp1conf # load pptp2conf pptp1conf: new -i ng0 bundle1 pptp1 set ipcp ranges 192.168.1.103/32 192.168.1.200/32 ^ Is this address defined on your server ? Henri load common #pptp2conf: # new -i ng1 bundle2 pptp2 # set ipcp ranges 192.168.1.103/32 192.168.1.201/32 # load common common: set iface disable on-demand set iface enable proxy-arp set iface idle 0 set iface enable tcpmssfix set bundle enable multilink set link enable acfcomp protocomp set link no pap chap set link enable chap # set link mtu 1460 set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 208.67.222.222 208.67.220.220 #set ipcp nbns 172.20.1.1 172.20.1.8 #set bundle enable compression #set ccp yes mppc #set ccp yes mpp-e40 #set ccp yes mpp-e128 #set ccp yes mpp-stateless pptp1: set link type pptp set pptp self 82.238.41.134 500 set pptp enable incoming set pptp disable originate pptp2: set link type pptp set pptp self 82.238.41.134 set pptp enable incoming set pptp disable originate As usual, all help appreciated Bernard Higonnet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: newbie problems mpd server on freebsd
Bernard T. Higonnet wrote:
Hello,
I want to set up a VPN server on a freebsd machine so Windows clients can use
it.
I am using FreeBSD 6.1 and mpd 3.18 from the ports collection.
My basic problem is that mpd does not do anything and doesn't complain about
anything, so I'm not making much progress.
I run mpd with "mpd -k -s higvpn"
Here are various facts and/or symptoms
1) all the show commands show there isn't anything (bundles, links, etc. etc.)
2) netstat says nobody's listening on 1723
3) Windows VPN's produce error 678 ("There was no answer") which seems
consonant with (2)
4) I can't find any trace info anywhere
5) there is no firewall issue because the freebsd vpn server and Windows
machine are both on my own little network (192.168.0) and neither machine has
one for the time being
In an effort to embarrass myself here is my mpd.conf file
default:
load pptp1
load pptp2
pptp1:
new -i ng0 pptp1 pptp1
load common
pptp2:
new -i ng1 pptp2 pptp2
load common
common:
set iface disable on-demand
set iface enable proxy-arp
set iface idle 0
set iface enable tcpmssfix
set bundle enable multilink
set link enable acfcomp protocomp
set link no pap chap
set link enable chap
set link keep-alive 10 60
set ipcp yes vjcomp
set ipcp ranges 82.238.41.134/32 192.168.0.201/24
^
what is this address ?
I would, as in your previous post put this statment after each new -i ngX.
set ipcp dns 208.67.222.222 208.67.220.220
#set ipcp nbns 172.20.1.1 172.20.1.8
#set bundle enable compression
#set ccp yes mppc
#set ccp yes mpp-e40
#set ccp yes mpp-e128
#set ccp yes mpp-stateless
what about mdp.links ?
Henri
TIA
Bernard Higonnet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: newbie problems mpd server on freebsd
On Tuesday 10 July 2007 21:37, Henri Hennebert wrote:
Please ignore this question. I only sent to the list by mistake. It is
replaced by the question "mpd isn't listening on 1723 because he can't get it
thhough it isn't used"
I am sorry.
Bernard T. Higonnet
> Bernard T. Higonnet wrote:
> > Hello,
> >
> > I want to set up a VPN server on a freebsd machine so Windows clients can
> > use it.
> >
> > I am using FreeBSD 6.1 and mpd 3.18 from the ports collection.
> >
> > My basic problem is that mpd does not do anything and doesn't complain
> > about anything, so I'm not making much progress.
> >
> > I run mpd with "mpd -k -s higvpn"
> >
> > Here are various facts and/or symptoms
> >
> > 1) all the show commands show there isn't anything (bundles, links, etc.
> > etc.) 2) netstat says nobody's listening on 1723
> > 3) Windows VPN's produce error 678 ("There was no answer") which seems
> > consonant with (2)
> > 4) I can't find any trace info anywhere
> > 5) there is no firewall issue because the freebsd vpn server and Windows
> > machine are both on my own little network (192.168.0) and neither machine
> > has one for the time being
> >
> >
> > In an effort to embarrass myself here is my mpd.conf file
> >
> > default:
> > load pptp1
> > load pptp2
> >
> > pptp1:
> > new -i ng0 pptp1 pptp1
> > load common
> >
> > pptp2:
> > new -i ng1 pptp2 pptp2
> > load common
> >
> > common:
> > set iface disable on-demand
> > set iface enable proxy-arp
> > set iface idle 0
> > set iface enable tcpmssfix
> > set bundle enable multilink
> > set link enable acfcomp protocomp
> > set link no pap chap
> > set link enable chap
> > set link keep-alive 10 60
> > set ipcp yes vjcomp
> > set ipcp ranges 82.238.41.134/32 192.168.0.201/24
>
>^
>
> what is this address ?
>
> I would, as in your previous post put this statment after each new -i ngX.
>
> > set ipcp dns 208.67.222.222 208.67.220.220
> > #set ipcp nbns 172.20.1.1 172.20.1.8
> > #set bundle enable compression
> > #set ccp yes mppc
> > #set ccp yes mpp-e40
> > #set ccp yes mpp-e128
> > #set ccp yes mpp-stateless
>
> what about mdp.links ?
>
> Henri
>
> > TIA
> > Bernard Higonnet
> > ___
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd isn't listening on 1723 because he can't get it thhough it isn't used
On Tuesday 10 July 2007 21:32, Henri Hennebert wrote: . . . > > set ipcp ranges 192.168.1.103/32 192.168.1.200/32 > > ^ > Is this address defined on your server ? You're quite right. This was a typing mistake and should be set ipcp ranges 192.168.0.103/32 192.168.0.200/32 Strangely enough, this did not fix the problem. Just to show that I did change this here's the output from show ipcp: [bundle1:pptp1] show ipcp [bundle1] IPCP [Initial] Allowed IP address ranges: Self: 192.168.0.103/32 Peer: 192.168.0.200/32 Current addressing: Self: 0.0.0.0 Peer: 0.0.0.0 Compression: Self: None Peer: None Server info we give to peer: DNS servers : 208.67.222.222 208.67.220.220 NBNS servers: 0.0.0.0 0.0.0.0 Server info peer gave to us: DNS servers : 0.0.0.0 0.0.0.0 NBNS servers: 0.0.0.0 0.0.0.0 IPCP Options: NameSelfPeer vjcomp enable accept req-pri-dns disable req-sec-dns disable req-pri-nbnsdisable req-sec-nbnsdisable pretend-ip disable radius-ip disable VJ Compression: Out comp : 0 Out total: 0 Missed : 0 Searched : 0 In comp : 0 In uncomp: 0 In error : 0 In tossed: 0 Thanks - every bit helps... Bernard Higonnet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with BCE network adapter (Dell PE2950)
On 7/10/07, Tom Judge <[EMAIL PROTECTED]> wrote: Ok so I think I have fix the problem with the rx_bd tracking. I have ported rboyer's patch to NetBSD's bnx driver to FreeBSD (patch attached). The patch seems to get rid of two problems: 1) Unexpected mbuf in rx_bd 2) Too many free rx_bd's Hi Tom. Thanks much for your work with this problem. I'm effected by major bce problems as well. Right now I'd be happy to get it working properly with an MTU of 1500. To that end I'm unable to get your patch to apply cleanly to my FreeBSD 6.2 tree. Most likely I've lost track of what patches in this thread to apply before your patch. If you have time, would you be so kind to cook a diff against a vanilla FreeBSD 6.2 tree or let me know which patches to apply first? Thanks! -- James. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with BCE network adapter (Dell PE2950)
James wrote: On 7/10/07, Tom Judge <[EMAIL PROTECTED]> wrote: Ok so I think I have fix the problem with the rx_bd tracking. I have ported rboyer's patch to NetBSD's bnx driver to FreeBSD (patch attached). The patch seems to get rid of two problems: 1) Unexpected mbuf in rx_bd 2) Too many free rx_bd's Hi Tom. Thanks much for your work with this problem. I'm effected by major bce problems as well. Right now I'd be happy to get it working properly with an MTU of 1500. To that end I'm unable to get your patch to apply cleanly to my FreeBSD 6.2 tree. Most likely I've lost track of what patches in this thread to apply before your patch. If you have time, would you be so kind to cook a diff against a vanilla FreeBSD 6.2 tree or let me know which patches to apply first? Thanks! A full patch against RELENG_6_2 (p5) is avaliable here: http://www.tomjudge.com/tmp/bce-patch-full-10-7-2007.gz You will also require this patch to sys/net/if_media.h that adds the 2.5Gb/s media definitions: http://www.tomjudge.com/tmp/if_media.h-patch-10-7-2007.gz These patches should be applied in /usr/src/sys/dev/bce and /usr/src/sys/net respectively. (e.g: cd /usr/src/sys/dev/bce; patch < /path/to/patch) This patch includes: * The latest driver from RELENG_6 (See http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bce/if_bce.c?only_with_tag=RELENG_6 for details ). NOTE: This does not include MSI support as 6.2 does not have MSI support. * David's patch to enable dumping the first 128 bytes of a bad packet * Stepherosa's patch which attempts to fix problems in the rx buffer (de)allocation during bce_rx_intr. * My patch from NetBSD that completely rewrites the way that the rx buffers are (de)allocated. Rather than allocate them on the fly in bce_rx_intr. Try to pre allocate as many as possible, and then allocate more during the bce_tick routine. Please let me know if you have any problems applying this patch, as this patch was generated from my subversion repository. On a side note, I have some systems (Dell PE2950's) running the vanilla 6.2 driver which are stable, they have a standard 1500 byte MTU. However these systems are not running such network intensive tasks as the ones with a 8192 byte MTU. On another side note it seems that OpenBSD removed Jumbo frame support from their driver 4 months ago as it was causing panics under high load however FreeBSD and NetBSD both have Jumbo frame support enabled. Tom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd isn't listening on 1723 because he can't get it thhough it isn't used
Bernard T. Higonnet wrote: I want to set up a VPN server on a freebsd machine so Windows clients can use it. I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. I whould recommend you to use mpd 4.2.2 from the ports collection. When I run mpd I get this: mpd: bind: Can't assign requested address mpd: can't get PPTP listening socket It should mean that this is probably incorrect: set pptp self 82.238.41.134 500 What do you mean by writing 500 here? Is the 82.238.41.134 is this router ip? -- Alexander Motin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: newbie problems mpd server on freebsd
Bernard T. Higonnet wrote: I run mpd with "mpd -k -s higvpn" As I can see, there is no higvpn label in your config. There is nothig to do for mpd on startup so it stays clean. -- Alexander Motin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Question about bce driver
I'm running 6.1 RELEASE (i386) and I've been replacing the if_bce.c file with a slightly newer one that at least got the driver working without hard lockups that required a reboot to fix. (Rather problematic on a remotely located web server.) If I download the latest driver from cvs (1.33), should I also replace the if_bcefw.h and if_bcereg.h files with the newer versions? Will the NIC work without creating new problems? Right now I get an occasional "flapping" of the NIC link state (down, up , down, up, etc.) but it at least works most of the time. I don't want to buildworld and get suprised by a non-functioning NIC. :-) If I use the newer versions, will I also need to use some other newer files that are called by them? Or would it be better to upgrade the entire box to 6.2? FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: grep bce /var/run/dmesg.boot bce0: mem 0xf400-0xf5ff irq 16 at device 0.0 on pci9 bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus0: on bce0 bce0: Ethernet address: 00:13:72:fb:2a:ad bce1: mem 0xf800-0xf9ff irq 16 at device 0.0 on pci5 bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus1: on bce1 bce1: Ethernet address: 00:13:72:fb:2a:ab -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: Problems with BCE network adapter (Dell PE2950)
On 7/10/07, Tom Judge <[EMAIL PROTECTED]> wrote: A full patch against RELENG_6_2 (p5) is avaliable here: http://www.tomjudge.com/tmp/bce-patch-full-10-7-2007.gz You will also require this patch to sys/net/if_media.h that adds the 2.5Gb/s media definitions: http://www.tomjudge.com/tmp/if_media.h-patch-10-7-2007.gz Thanks much. They both applied cleanly to my tree (also based on RELENG_6_2 p5). I'll start a build and give 'em a whirl tonight. -- James. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Bug in userland PPP LQR?
I may have found a bug in the LQR code of FreeBSD's userland PPP. I've been noticing that PPTP sessions are dropping with messages saying "** Too many LQR packets lost **" on some important wireless links. Wireless links occasionally do drop a packet or two, but it's rare to see 5 dropped packets in a row (which is supposed to be when PPP gives up and kills the link). Yet, the links go down when there's even an occasional dropped packet. I'm using LQR with an interval of 12 seconds, and the built-in threshold for dropping the connection (not changeable in this implementation) is 5 lost packets. This means that the link pretty much has to be down for 60 seconds before the connection gets cut off. In practice, however, connections are dying when data was coming through only a few seconds before and there's a very low percentage of dropped packets. This leads me to suspect that either (a) the lost packet counter is cumulative for the session; that is, it's not resetting when a good response comes in; or (b) the LQR mechanism it may be getting out of sync (perhaps due to unexpected sequence numbers) and always count up to 5 after the first missed packet. The code in /usr/src/usr.sbin/ppp/lqr.c is quite cryptic, and I'd like some help in figuring out just why I'm seeing so many dropped connections due to LQR. Any folks out there willing to help me analyze it? --Brett Glass ___ 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 TCP syncache fix: request for testers
On Tue, 10 Jul 2007, Eygene Ryabinkin wrote: Can't say that I am pushing much traffic through my box, but after applying your patch and rebuilding the kernel I am still seeing the messages like - TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags 0x19; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: Response timeout - But what had changed is that the lines with the 'syncache_timer' started to appear. There were no such lines prior to the patch, only the 'failed SYNCOOKIE' ones. The "syncache_timer: Response timeout" message means that the syncache sent a SYN-ACK response four times, but still didn't receive a response. This probably means that someone tried using a port scanner or was going through a faulty firewall. We'll definitely have to take that log message out before 7.0 is released. The fact that you're still getting the syncache_expand message tells me that there's another bug which I have not yet fixed still present. My suspicion is that the "Segment failed SYNCOOKIE authentication" message is the aftereffect of FreeBSD 7 randomly dropping TCP connections, and not the problem itself. My theory is that the connection is silently dropped, without the other endpoint knowing. That other endpoint then sends an ACK packet, which is then believed to be a syncookie. Since it is not, it obviously fails the verification. Finding that bug is my next goal. But the patch received only half a day of testing, so I will continue the tests and will inform you if some other information will be available. Up to date I don't see problems that had appeared without the patch, but they tend to show up after a midnight ;)) Thank you! Thanks for testing, I look forward to hearing how things work for you. Mike "Silby" Silbersack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpd isn't listening on 1723 because he can't get it thhough it isn't used
Alexander Motin wrote: Bernard T. Higonnet wrote: I want to set up a VPN server on a freebsd machine so Windows clients can use it. I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. I whould recommend you to use mpd 4.2.2 from the ports collection. I tried, but apparently when I created my freebsd I didn't ask for all the source code and 4.2.2 will not make... It should mean that this is probably incorrect: set pptp self 82.238.41.134 500 What do you mean by writing 500 here? Is the 82.238.41.134 is this router ip? I had found this peculiar mistake after sending my mail. I have fixed it by removing the 500 but it makes no difference at all. Apologies & thanks Bernard Higonnet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with BCE network adapter (Dell PE2950)
On 7/10/07, James <[EMAIL PROTECTED]> wrote: I'll start a build and give 'em a whirl tonight. hihi. I gave it a try by pxebooting a new release with the patches applied. During sysinstall the NIC comes up, gets a DHCP address, but fails to lookup my install server via DNS to install the minimal dist set. Running into the same problems as you at this point: bce1: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967) -- James. ___ 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 TCP syncache fix: request for testers
Mike, good day. Tue, Jul 10, 2007 at 08:29:14PM -0500, Mike Silbersack wrote: > The fact that you're still getting the syncache_expand message tells me that > there's another bug which I have not yet fixed still present. > > My suspicion is that the "Segment failed SYNCOOKIE authentication" message is > the aftereffect of FreeBSD 7 randomly dropping TCP connections, and not the > problem itself. My theory is that the connection is silently dropped, without > the other endpoint knowing. That other endpoint then sends an ACK packet, > which is then believed to be a syncookie. Since it is not, it obviously fails > the verification. OK, maybe I have something that can be related to this bug. It provokes another message, 'Spurious RST', but can be correlated with your guess. What is happening is that when one side closes the connection and releases the socket (running -CURRENT) while the other one is still pushing data through the connection, we are getting 'Spurious RST' messages. This happens, because we are checking the 'so->so_state' for the presence of the 'SS_NOFDREF' flag (tcp_input.c, version 1.361, line 1581) and dropping such connections with RST. But the connection was already closed (living in the FIN-WAIT-2 state, to be precise) from that side, so it provokes the debug message. If you're interested, I have the tcpdump trace and the relevant dmesg output for such a session: http://codelabs.ru/fbsd/session-with-close.tar.bz2 It was produced on the lo0 with client connecting to Apache instance and performing the close() on the socket after some (but not all) bytes of HTTP reply were received. > >But the patch received only half a day of testing, so I will continue > >the tests and will inform you if some other information will be > >available. Up to date I don't see problems that had appeared without > >the patch, but they tend to show up after a midnight ;)) > > Thanks for testing, You're welcome ;)) > I look forward to hearing how things work for you. My problem, as usual, showed up after midnight -- the sockets with the weird state: - tcp4 0 0 127.0.0.1.*127.0.0.1.40001CLOSED tcp4 0 0 127.0.0.1.*127.0.0.1.40001CLOSED - 127.0.0.1:40001 used to be the real connections to the service on the port 40001, but they lose their port association from the client side and are stuck in the CLOSED state. The effect is that I can not connect to the service listening to 127.0.0.1:40001 anymore. Only service restart helps. Perhaps that can give you some clue. Perhaps not: it may be totally unrelated to the syncache issues :(( This is also documented in the thread http://lists.freebsd.org/pipermail/freebsd-net/2007-June/014406.html Thank you! -- Eygene ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
