Re: iwi discarding oversized packets while mtu=1500 for src/dst
Hans Nieser wrote: > Hi, > > Today I wanted to go back to using FreeBSD on my laptop, which is still > installed but hasn't been used for several months because I am still > waiting for a stable Intel HDA driver. So I performed a full upgrade of my > installed ports. However I ran into an issue that prevented me from > logging in to my FreeBSD server over ssh. > > When I tried to login to the server I got the usual "Password: " prompt, > but as soon as I typed my password and hit enter, nothing happened. At > first I thought it was a DNS issue, but after disabling UseDNS in > sshd_config I still ran into it. Also, other computers on my LAN were able > to ssh to the server without problems and I could ssh from the server to > the laptop and any other computer on my LAN without problems. > > Upon closer inspection I found that logging into my FreeBSD sshd server > from my FreeBSD laptop triggered a bunch of iwi0 errors in dmesg (on the > laptop): > > iwi0: discard oversize frame (ether type 800 flags 3 len 1518 > max 1514) > iwi0: discard oversize frame (ether type 800 flags 3 len 1518 > max 1514) > iwi0: discard oversize frame (ether type 800 flags 3 len 1518 > max 1514) > iwi0: discard oversize frame (ether type 800 flags 3 len 1518 > max 1514) > (and many more, probably aggregated from several login attempts). > > Note that I have not touched any MTU settings at all and that all > computers on my LAN have the default MTU (1500) set (according to ifconfig). > > To check that my server's NIC was in fact sending packets of 1518 bytes I > sniffed a SSH login from my Gentoo desktop computer to the server with > wireshark which did capture a packet of 1518 bytes: > > No. TimeSourceDestination Protocol Info > 36 1.678370192.168.1.1 192.168.1.64 SSHv2 > Encrypted response packet len=1448 > > Frame 36 (1518 bytes on wire, 1518 bytes captured) > Ethernet II, Src: Albatron_0f:40:c7 (00:0a:48:0f:40:c7), Dst: > SitecomE_1b:35:d9 (00:0c:f6:1b:35:d9) > Internet Protocol, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.1.64 > (192.168.1.64) > Transmission Control Protocol, Src Port: ssh (22), Dst Port: 47797 > (47797), Seq: 1896, Ack: 1733, Len: 1448 > SSH Protocol > > So it would seem that my desktop's NIC (or WNIC actually) can handle these > "oversized" packets (if they are in fact oversized, I don't really know at > what layer the MTU setting is applied), while my Laptop's WNIC (iwi) doesn't. > > Can anyone shed some light on who or what is to blame for my problems and > what the best way to solve it is? I can at least get things working by > lowering my server's MTU, but I really don't understand why this is a > problem now because I'm pretty sure I've succesfully been able ssh to my > server in the past from my laptop and I never ever had to touch any MTU > settings. > > I should mention that I am actually not sure if the problem was present > before I updated all my ports since it was the first thing I did. But I > guess if it was caused by an update it would have to be something with the > iwi-firmware port, unfortunately I don't know if it was updated. > > My server's NIC: > [EMAIL PROTECTED]:0:0: class=0x02 card=0x10001458 chip=0x920010b7 > rev=0x78 > hdr=0x00 > vendor = '3COM Corp, Networking Division' > device = '3C905C-TX Fast EtherLink for PC Management NIC' > class= network > subclass = ethernet > > Laptop's NIC: > [EMAIL PROTECTED]:3:0: class=0x028000 card=0x27018086 chip=0x42208086 > rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/Wireless 2200BG Network Connection' > class= network I see none of the basic info needed to help. OS version? description of how the device is setup (e.g. ifconfig cmds) and current state--ifconfig iwi0. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iwi discarding oversized packets while mtu=1500 for src/dst
Sam Leffler wrote:
> Hans Nieser wrote:
>> Hi,
>>
>> Today I wanted to go back to using FreeBSD on my laptop, which is still
>> installed but hasn't been used for several months because I am still
>> waiting for a stable Intel HDA driver. So I performed a full upgrade of my
>> installed ports. However I ran into an issue that prevented me from
>> logging in to my FreeBSD server over ssh.
...
>> My server's NIC:
>> [EMAIL PROTECTED]:0:0: class=0x02 card=0x10001458 chip=0x920010b7
>> rev=0x78
>> hdr=0x00
>> vendor = '3COM Corp, Networking Division'
>> device = '3C905C-TX Fast EtherLink for PC Management NIC'
>> class= network
>> subclass = ethernet
>>
>> Laptop's NIC:
>> [EMAIL PROTECTED]:3:0: class=0x028000 card=0x27018086 chip=0x42208086
>> rev=0x05
>> hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'PRO/Wireless 2200BG Network Connection'
>> class= network
> I see none of the basic info needed to help. OS version? description
> of how the device is setup (e.g. ifconfig cmds) and current
> state--ifconfig iwi0.
Apologies, some extra info as requested (and some ASCII-art because I was
bored!):
The Laptop's WLAN NIC is connected to an AP integrated into my DSL device
(specifically, it's a Thompson SpeedTouch 716WL). My server's NIC is
connected over UTP to the 4-port switch also integrated into the DSL
device. So basically:
_
| |
| (Intarwebs) |
|_|
|
__|__
| ___|
| | | |
| DSL | LAN hub | WLAN AP |
|_|_|_|
| |
|___ |
|| | ||
| Server | ~ ~ ~ ~ ~ | Laptop |
|| ||
The wireless AP is configured to only allow 802.11g devices and uses
WPA-PSK for security with TKIP encryption.
Laptop setup -
[EMAIL PROTECTED]:~# uname -a
FreeBSD aphax-laptop.lan 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu May 11
07:17:09 CEST 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/APHAX-LAPTOP i386
[EMAIL PROTECTED]:~# ifconfig iwi0
iwi0: flags=8843 mtu 1500
inet6 fe80::215:ff:fe2b:20ab%iwi0 prefixlen 64 scopeid 0x2
inet 192.168.1.65 netmask 0xff00 broadcast 192.168.1.255
ether 00:15:00:2b:20:ab
media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps)
status: associated
ssid geendraadjes channel 8 bssid 00:11:f5:ca:50:71
authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 100
protmode CTS roaming MANUAL bintval 100
[EMAIL PROTECTED]:~# cat /etc/rc.conf | grep -B 4 ifconfig
hostname="aphax-laptop.lan"
network_interfaces="lo0"
#ifconfig_sk0="DHCP"
ifconfig_iwi0="DHCP WPA"
[EMAIL PROTECTED]:~# cat /etc/wpa_supplicant.conf
network={
ssid="nieser"
psk="xx"
}
network={
ssid="niba"
psk="xx"
}
network={
ssid="geendraadjes"
psk="x"
}
Server setup -
[EMAIL PROTECTED]:~# uname -a
FreeBSD mishmash.geendraadjes 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sat May
13 03:02:19 CEST 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MISHMASH i386
[EMAIL PROTECTED]:~# ifconfig xl0
xl0: flags=8843 mtu 1500
options=9
inet6 fe80::20a:48ff:fe0f:40c7%xl0 prefixlen 64 scopeid 0x1
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
ether 00:0a:48:0f:40:c7
media: Ethernet autoselect (100baseTX )
status: active
[EMAIL PROTECTED]:~# cat /etc/rc.conf | grep -B 2 ifconfig
defaultrouter="192.168.1.254"
hostname="mishmash.lan"
ifconfig_xl0="inet 192.168.1.1 netmask 255.255.255.0"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Intel em receive hang and possible pr #72970
Hi, We have experienced a very sporadic problem on 2 amd64 machines running FreeBSD 6.0-RELEASE. The hardware: Tyan K8SR motherboard 2 AMD 275 dual-core processors Intel Pro 1000 MT dual-port copper server card Intel Pro 1000 MF dual-port fiber server card Adaptec 2230S Raid controller These machines receive multicast & tcp data on multiple interfaces and process it & record it to disk and then rebroadcast it on one interface. Twice now (once on each machine after a recent upgradee to 6.0-RELEASE) the 2 fiber em interfaces seemed to stop receiving. Transmits seemed to still be happening, and the machine itself was not hung. We could console into it and do anything not network related. The first time this happened we opted to quickly disconnect the machine from the network and move its processes to a backup machine. We did not see anything interesting with netstat, vmstat, logs, etc (I do not remember however which exact tests I ran at the time). Everything seemed normal except that it was not receiving on the 2 fiber interfaces (we did not actually test the other interfaces, but one of our apps that uses the copper interfaces was still receiving data). We rebooted the machine and ran Intel's nic diagnostics. The card passed all of the tests through like 100 iterations. We eventually put the machine back into production. The second machine had the same problem. Unfortunately I was on vacation when it happened and did get to do any diagnostics. The developers just put the backup machine into production and rebooted the one with the problem. After poking around in various group/pr postings the most similar problem that we found was PR #72970. http://www.freebsd.org/cgi/query-pr.cgi?pr=72970 Does it seem that we are encountering that bug? Is that bug fixed in 6.1-RELEASE, or is there an easy patch to 6.0-RELEASE (i.e. can we only patch the em driver). If it does not seem that we are triggering that bug, does anyone have any thoughts about what the problem could be? We have done fairly intense stress testing in the past on these machines with tons of network/disk/cpu/memory activity all happening at the same time, and we've never encountered this bug. The fact that it is not easily repeatable makes it hard to test for. Any testing suggestions would also be appreciated. Thanks - Rob Watt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel em receive hang and possible pr #72970
On 8/31/06, Rob Watt <[EMAIL PROTECTED]> wrote: After poking around in various group/pr postings the most similar problem that we found was PR #72970. http://www.freebsd.org/cgi/query-pr.cgi?pr=72970 Does it seem that we are encountering that bug? Is that bug fixed in 6.1-RELEASE, or is there an easy patch to 6.0-RELEASE (i.e. can we only patch the em driver). That fix is only just into the STABLE code, so no, not in 6.1-RELEASE. You could take the tip of STABLE, but if you have only a 6.0 based system I know you are going to run into some backward incompatabililties. As a matter of fact I dont believe the STABLE tip will even build on RELEASE (something that I take issue with). Sounds like its at least possible this is your problem, worth setting up a system to test with I would say. Good Luck, Jack Intel LAD ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel em receive hang and possible pr #72970
Jack Vogel wrote: On 8/31/06, Rob Watt <[EMAIL PROTECTED]> wrote: After poking around in various group/pr postings the most similar problem that we found was PR #72970. http://www.freebsd.org/cgi/query-pr.cgi?pr=72970 Does it seem that we are encountering that bug? Is that bug fixed in 6.1-RELEASE, or is there an easy patch to 6.0-RELEASE (i.e. can we only patch the em driver). That fix is only just into the STABLE code, so no, not in 6.1-RELEASE. You could take the tip of STABLE, but if you have only a 6.0 based system I know you are going to run into some backward incompatabililties. As a matter of fact I dont believe the STABLE tip will even build on RELEASE (something that I take issue with). Sounds like its at least possible this is your problem, worth setting up a system to test with I would say. Good Luck, Jack Intel LAD ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" IF you want latest -STABLE you use stable, if you want code AS-IS when it was released, you use RELEASE signature.asc Description: OpenPGP digital signature
Re: Intel em receive hang and possible pr #72970
On 8/31/06, Joe Holden <[EMAIL PROTECTED]> wrote: Jack Vogel wrote: > On 8/31/06, Rob Watt <[EMAIL PROTECTED]> wrote: > >> After poking around in various group/pr postings the most similar problem >> that we found was PR #72970. >> http://www.freebsd.org/cgi/query-pr.cgi?pr=72970 >> >> Does it seem that we are encountering that bug? Is that bug fixed in >> 6.1-RELEASE, or is there an easy patch to 6.0-RELEASE (i.e. can we only >> patch the em driver). > > That fix is only just into the STABLE code, so no, not in 6.1-RELEASE. > You could take the tip of STABLE, but if you have only a 6.0 based > system I know you are going to run into some backward incompatabililties. > As a matter of fact I dont believe the STABLE tip will even build on > RELEASE (something that I take issue with). > > Sounds like its at least possible this is your problem, worth setting up a > system to test with I would say. > > Good Luck, > > Jack > Intel LAD > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" IF you want latest -STABLE you use stable, if you want code AS-IS when it was released, you use RELEASE I agree with that in the case of generic OS, but from the standpoint of a driver developer/maintainer I hope you see why this is a problem, yes? In the commercial world they dont want to upgrade a complete OS to get a couple line bug fix in a driver, so making the driver backward compatible WHEN POSSIBLE (and I know thats not always doable) is goodness. Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel em receive hang and possible pr #72970
Jack Vogel wrote: On 8/31/06, Joe Holden <[EMAIL PROTECTED]> wrote: Jack Vogel wrote: > On 8/31/06, Rob Watt <[EMAIL PROTECTED]> wrote: > >> After poking around in various group/pr postings the most similar problem >> that we found was PR #72970. >> http://www.freebsd.org/cgi/query-pr.cgi?pr=72970 >> >> Does it seem that we are encountering that bug? Is that bug fixed in >> 6.1-RELEASE, or is there an easy patch to 6.0-RELEASE (i.e. can we only >> patch the em driver). > > That fix is only just into the STABLE code, so no, not in 6.1-RELEASE. > You could take the tip of STABLE, but if you have only a 6.0 based > system I know you are going to run into some backward incompatabililties. > As a matter of fact I dont believe the STABLE tip will even build on > RELEASE (something that I take issue with). > > Sounds like its at least possible this is your problem, worth setting up a > system to test with I would say. > > Good Luck, > > Jack > Intel LAD > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" IF you want latest -STABLE you use stable, if you want code AS-IS when it was released, you use RELEASE I agree with that in the case of generic OS, but from the standpoint of a driver developer/maintainer I hope you see why this is a problem, yes? In the commercial world they dont want to upgrade a complete OS to get a couple line bug fix in a driver, so making the driver backward compatible WHEN POSSIBLE (and I know thats not always doable) is goodness. Jack Agreed, unfortunately major ABI changes break backwards compatability, which I agree, shouldn't happen in a STABLE branch. signature.asc Description: OpenPGP digital signature
Re: Intel em receive hang and possible pr #72970
On Thu, Aug 31, 2006 at 01:38:40PM -0700, Jack Vogel wrote: > On 8/31/06, Rob Watt <[EMAIL PROTECTED]> wrote: > > >After poking around in various group/pr postings the most similar problem > >that we found was PR #72970. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=72970 > > > >Does it seem that we are encountering that bug? Is that bug fixed in > >6.1-RELEASE, or is there an easy patch to 6.0-RELEASE (i.e. can we only > >patch the em driver). > > That fix is only just into the STABLE code, so no, not in 6.1-RELEASE. > You could take the tip of STABLE, but if you have only a 6.0 based > system I know you are going to run into some backward incompatabililties. > As a matter of fact I dont believe the STABLE tip will even build on > RELEASE (something that I take issue with). > > Sounds like its at least possible this is your problem, worth setting up a > system to test with I would say. A driver built against 6.0-RELEASE should work with any 6.x kernel unless someone screwed up unacceptably. We to allow the addition of new, optional features to the STABLE branch so we don't guarantee that drivers will work with kernels older than they are. The only reason the em code at the tip of 6-STABLE might not build with 6.0 sources is that it uses some enhancements. If an individual maintainer wants to make sure their driver will build with any sources they either need to not use new features or use them inside appropriate ifdef __FreeBSD_version sections. -- Brooks pgpg51HBHTlha.pgp Description: PGP signature
Re: iwi discarding oversized packets while mtu=1500 for src/dst
Sam Leffler wrote: > Hans Nieser wrote: > >> [EMAIL PROTECTED]:~# uname -a >> FreeBSD aphax-laptop.lan 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu May 11 >> 07:17:09 CEST 2006 >> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/APHAX-LAPTOP i386 > > Are you running the iwi driver that came with 6.1-release? If so it has > numerous problems that have been fixed in 6-STABLE and HEAD. I'm not > sure how best to update your system except by going to 6-STABLE via a > src upgrade. Yeah, I'm using the one that came with 6.1-RELEASE. Running 6-STBALE actually seems like a good idea since running FreeBSD on my laptop is a bit of an experiment for me anyway since there's some hardware that I already expected some trouble with (the Intel HDA sound for example, which I'm happy to report seems to work now with one of the alpha drivers posted to @multimedia). Thanks for the suggestion! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102607: [if_bridge] don't generate random L2 address
On Tue, Aug 29, 2006 at 11:56:29PM +0200, Stefan Bethke wrote: > Am 28.08.2006 um 18:19 schrieb Andrew Thompson: > > >1. change kernel code or to generate static IP address > > for bridge interface from attached member interfaces. > > or > > 2. use startup scripts to generate random number and > >store it somewhere in /var. > > or > > 3. Make system complain/warning if you set bridge0 to broadcast > >address. > > or > >4. Document in if_bridge(4) that L2 address is random and > >document > >correct format of ethernet addresses. > > > > First, the actual behavior and it's implications should be documented > in if_bridge(4), specifically the random assignment of a locally > administered address. (Cf. net/if_bridge.c:bridge_clone_create()) > > If the user wants a different (fixed) address on the bridge, I think > it's acceptable to configure this in rc.conf along with the member > interfaces. (Already implemented: ifconfig_bridge0="create ether > 01:23:45:67:89:ab...") I agree with this. The first option is unfeasable as you cant guarantee that the members will have a L2 address (tap/gif) and it could make a dependency where you cant assign an IP until one or more networks are bridged. As you say the correct way is to use rc.conf to set the MAC and it just needs a bit more documentation. Andrew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
routing problem with mpd
Dear all, I am trying to connect to my office's freebsd mpd server, but I am not able to ping other subnet except those same subnet that I was assigned by the mpd server. eg. Here is the IPs assigned to my laptop from my office's mpd server: IP: 10.2.99.23 Default gateway: 10.2.99.23 <<-- this is may be wrong, I want to set it to 10.2.1.1, but don't know how in windows xp. DNS server: 10.2.1.1 mpd.conf: pptp20: new -i ng20 pptp20 pptp200 set ipcp ranges 10.2.99.1/32 10.2.99.23/32 set ipcp dns 10.1.20.3 set ipcp nbns 10.1.20.3 load pptp_standard ifconfig: ng0: flags=88d1 mtu 1396 inet 10.2.1.1 --> 10.2.99.23 netmask 0x I am able to ping 10.2.1.1, but I can't ping 10.1.12.2 which is reachable (pingable) in the mpd server, eg: ]# traceroute 10.1.12.2 traceroute to 10.1.12.2 (10.1.12.2), 64 hops max, 40 byte packets 1 router.core.abc (10.1.10.1) 0.308 ms 0.181 ms 0.136 ms 2 optus.abc (10.1.1.12) 2.432 ms 1.511 ms 1.804 ms 3 serv.optus.abc (10.1.12.2) 3.265 ms 3.146 ms 3.307 ms at mpd server: # netstat -nrf inet Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.1.10.1 UGS 1 8284266 bge0 10.1.10/24 link#1 UC 00 bge0 10.1.10.1 00:04:23:bc:3a:d2 UHLW2 122249 bge0824 10.1.10.2 00:e0:81:31:3a:d8 UHLW14lo0 10.1.10.3 00:11:25:aa:19:ea UHLW156016 bge0924 10.1.20.3 10.1.20.3 UH 0 299393lo0 10.2.1.1 lo0UHS 00lo0 10.2.99.23 10.2.1.1 UH 03ng0 ^^ this is what it was assigned to my laptop. 10.128/9 10.1.20.1 UGS 00 bge0 10.152.34.75 10.152.34.75 UH 00lo0 127.0.0.1 127.0.0.1 UH 0 4186396lo0 Can anyone tell me how to reach 10.1.12.2 from my laptop 10.2.99.23? Thanks S ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel em receive hang and possible pr #72970
Jack Vogel wrote: > As a matter of fact I dont believe the STABLE tip will even build on > RELEASE (something that I take issue with). The latest RELENG_N version of the source definitely SHOULD build on a -RELEASE version of that same branch, so if you've tried this and it doesn't work, please report the problem on the freebsd-stable@ mailing list. Given that we're about to freeze RELENG_6 for the 6.2-RELEASE, this is the perfect time to bring up those kinds of issues. Doug -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel em receive hang and possible pr #72970
On Thu, 31 Aug 2006, Joe Holden wrote: Does it seem that we are encountering that bug? Is that bug fixed in 6.1-RELEASE, or is there an easy patch to 6.0-RELEASE (i.e. can we only patch the em driver). That fix is only just into the STABLE code, so no, not in 6.1-RELEASE. You could take the tip of STABLE, but if you have only a 6.0 based system I know you are going to run into some backward incompatabililties. As a matter of fact I dont believe the STABLE tip will even build on RELEASE (something that I take issue with). Sounds like its at least possible this is your problem, worth setting up a system to test with I would say. IF you want latest -STABLE you use stable, if you want code AS-IS when it was released, you use RELEASE There's also another possibility these days -- we support errata fixes going into release branches, as we do with security fixes. These changes must be low-impact (not affect API, ABI, etc), but are useful for critical stability fixes or to correct widely experienced problems. If there is a small tweak which could make a big difference, and has been well QA'd, then that approach can be taken. However, we're currently accepting errata fixes only for the most recent release, so expanding the scope to include older releases (i.e., 6.0 in addition to 6.1) then that would require some discussion and careful thinking. So far, we've been very conservative in accepting errata fixes on the basis that we want it to be a trickle, not a waterfall, for a great many good reasons :-). Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
