Re: Atheros Super G
On Saturday 07 February 2004 02:54 am, h0444lp6 wrote: Dear list, I would like to know if the Atheros Super G chipset is supported by 5.2-Release. According to Atheros.com its's the AR5004 and AR5003 chiops. In ath(4) I can only find reference to AR5210, AR5211, and AR5212. No support for SuperG. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IEEE 802.11 Wireless Multimedia Extension (WME) and raw sockets
Geir Egeland wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I've been playing around with WME to test various network performance,
and come across a problem that I can't quite understand.
I have an application that generates traffic with various TOS
(BACKGROUND, BEST EFFORT, VOICE, VIDEO). It uses raw sockets to transmit
the IP packets. This all works well if ip-ip_len is less than 192
bytes. If ip_ip_len is larger than 192, the call to ieee80211_classify
(/usr/src/sys/net80211/ieee80211_output.c) will classify the packet as
BEST EFFORT no matter what value my application set the TOS field as.
Debugging ieee80211_classify, I see that both ip-ip_tos and ip-ip_len
are set to zero when a I send a packet with ip-ip_len larger than 192
bytes.
Sniffing the network, I can see my packets have the correct TOS and
length, but they don't get the correct WME classification.
- -ieee80211_output.c(iee80211_classify)
if (eh-ether_type == htons(ETHERTYPE_IP)) {
const struct ip *ip = (struct ip *)
(mtod(m, u_int8_t *) + sizeof (*eh));
/*
* IP frame, map the TOS field.
*/
//added by myself
printf(IP_TOS: %d, IP_LEN: %d\n,ip-ip_tos,ntohl(ip-ip_len));
//end
switch (ip-ip_tos) {
case 0x08:
case 0x20:
d_wme_ac = WME_AC_BK; /* background */
break;
case 0x28:
case 0xa0:
d_wme_ac = WME_AC_VI; /* video */
break;
case 0x30: /* voice */
case 0xe0:
case 0x88: /* XXX UPSD */
case 0xb8:
d_wme_ac = WME_AC_VO;
break;
default:
d_wme_ac = WME_AC_BE;
break;
}
- -
When I use SOCK_DGRAM socket instead of raw, everything works fine.
I use FreeBSD 6.0-STABLE and my wireless NIC uses an atheros chipset.
Has anyone got an idea what is going on ?
I'll check but the raw socket path must not have the ip header in the
expected spot in the mbuf. Most of my testing has been done with a
modified version of netperf that slaps a TOS on the socket based on a
command line argument so only UDP and TCP (not raw) traffic.
Ideally the 802.11 layer should not be doing classification; packets
should be tagged and the 802.11 layer then does the mapping according to
the standard. Groveling around inside packets to extract stuff like
this is evil.
Sam
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient and wpa_supplicant
Eric Schuele wrote:
Sam Leffler wrote:
Sam Leffler wrote:
Brooks fixed a bunch of bugs in dhclient and I just committed an
important fix to wpa_supplicant to work right when wireless cards are
ejected (previously it would loop).
I also tested that dhclient does the right thing for roaming between
ap's--switching causes dhclient to immediately collect a new lease.
I just ran tests with wpa_supplicant and found that it does appear to
handle open ap's properly.
Everything except the wpa_supplicant changes have been MFC'd to
RELENG_6 for the 6.0RC2 build that's going to happen soon (I'm hoping
to get re to approve the wpa_supplicant changes).
FWIW I just MFC'd the wpa_supplicant fix.
So the question is what are the outstanding issues with dhclient and
wpa_supplicant? I'm mostly concerned with wireless devices but feel
free to talk about wired interfaces too. If something doesn't work
right please try to give steps to reproduce the problem. Otherwise
please provide detailed info include ifconfig output. Remember that
dhclient logs info to /var/log/messages and you should also see link
state change msgs there too.
s/6.0RC2/6.0BETA2/.
Sam
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
[EMAIL PROTECTED]
Hello,
I am very interested in getting wpa_supplicant dhclient to work.
Presently it does not work for me the way I would hope it would.
I would think that if it were setup properly on my machine I could turn
the machine on at home, and have it associate with my AP and then
acquire a lease. Then I could shut it down... go to the office... turn
it on and then have it associate with the AP there and acquire a lease.
However it does not seem to do this. It seems to only want to associate
with the last AP it ever associated with. I then have to down the
interface and manually ifconfig it.
I am fairly sure I do not have things setup properly, since others have
had much better results. Can you please point me to the most current
docs or a How To to push me in the right direction.
I have RELENG_6 as of last night. I have appended some conf files to
the bottom for your review.
Thanks,
rc.conf contains
===
network_interfaces=lo0 bfe0 ath0
ifconfig_ath0=WPA DHCP
ifconfig_bfe0=DHCP
dhclient.conf contains
===
interface ath0 {
#send option host-name myhost;
#send option domain-name nxdomain.org;
send dhcp-client-identifier myhost;
media
### Home
ssid home_ssid mode 11b channel 11 wepmode on weptxkey 1 wepkey
0xhome_wepkey,
### Office
ssid office_ssid mode 11b channel 6 wepmode on weptxkey 1 wepkey
0xoffice_wepkey;
request subnet-mask, broadcast-address, routers, domain-name-servers,
domain-name;
}
Do not use media statements to setup wireless parameters; this does not
work. You need to run wpa_supplicant and let it identify the network
and setup the key parameters.
wpa_supplicant.conf
=
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
# Home Network
network={
ssid=home_ssid
scan_ssid=1
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=home_wepkey
}
# Office Network
network={
ssid=office_ssid
scan_ssid=1
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=office_wepkey
}
Not sure you need scan_ssid set, I'd leave it out.
If you have problems try disabling auto-startup of ath0 and run
wpa_supplicant by hand with the -d flag to see what it's doing. Once
that's going then enable startup in rc.conf. If you continue to have
problems provide the output wpa_supplicant -d -i ath0 -c
/etc/wpa_supplicant.conf (or similar) when you have trouble. There is
also a pending issue with locating some ap's that are setup to hide
their ssid. If one of the ap's is configured in this way contact me
directly--I've been trying to collect the info I need to identify what's
going on.
Sam
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient and wpa_supplicant
Eric Schuele wrote:
Sam Leffler wrote:
Eric Schuele wrote:
big-snip
dhclient.conf contains
===
interface ath0 {
#send option host-name myhost;
#send option domain-name nxdomain.org;
send dhcp-client-identifier myhost;
media
### Home
ssid home_ssid mode 11b channel 11 wepmode on weptxkey 1 wepkey
0xhome_wepkey,
### Office
ssid office_ssid mode 11b channel 6 wepmode on weptxkey 1 wepkey
0xoffice_wepkey;
request subnet-mask, broadcast-address, routers,
domain-name-servers, domain-name;
}
Do not use media statements to setup wireless parameters; this does
not work. You need to run wpa_supplicant and let it identify the
network and setup the key parameters.
How do I tell wpa_supplicant about the network media? I had found an
older post of yours regarding NOT doing it in dhclient.conf but I've
found no other way to accomplish it.
The above dhclient.conf lists media settings that are all handled by
wpa_supplicant so you don't specify any of them. Specifically you set
ssid, band, channel, and wep parameters; all these are handled by
wpa_supplicant.
The intent is that dhclient deal only with the dhcp protocol and stop
being involved in the discovery and selection of wireless networks (a
job wpa_supplicant is better equipped to handle).
wpa_supplicant.conf
=
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
# Home Network
network={
ssid=home_ssid
scan_ssid=1
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=home_wepkey
}
# Office Network
network={
ssid=office_ssid
scan_ssid=1
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=office_wepkey
}
Not sure you need scan_ssid set, I'd leave it out.
If you have problems try disabling auto-startup of ath0 and run
wpa_supplicant by hand with the -d flag to see what it's doing. Once
that's going then enable startup in rc.conf. If you continue to have
problems provide the output wpa_supplicant -d -i ath0 -c
/etc/wpa_supplicant.conf (or similar) when you have trouble. There is
also a pending issue with locating some ap's that are setup to hide
their ssid. If one of the ap's is configured in this way contact me
directly--I've been trying to collect the info I need to identify
what's going on.
Both my APs (home and office) hide their ssids. One is a wrt54g (home),
the other is linksys as well... though I forget the model at the moment
(FWIW its a/b/g). What can I do to provide the info you need?
These should work; I've had reports of problems with certain Cisco ap's.
Note however that configuring an ap to hide it's ssid adds no real
security.
Sam
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient and wpa_supplicant
Eric Schuele wrote:
Sam Leffler wrote:
Eric Schuele wrote:
Sam Leffler wrote:
Eric Schuele wrote:
big-snip
dhclient.conf contains
===
interface ath0 {
#send option host-name myhost;
#send option domain-name nxdomain.org;
send dhcp-client-identifier myhost;
media
### Home
ssid home_ssid mode 11b channel 11 wepmode on weptxkey 1
wepkey 0xhome_wepkey,
### Office
ssid office_ssid mode 11b channel 6 wepmode on weptxkey 1
wepkey 0xoffice_wepkey;
request subnet-mask, broadcast-address, routers,
domain-name-servers, domain-name;
}
Do not use media statements to setup wireless parameters; this does
not work. You need to run wpa_supplicant and let it identify the
network and setup the key parameters.
How do I tell wpa_supplicant about the network media? I had found an
older post of yours regarding NOT doing it in dhclient.conf but
I've found no other way to accomplish it.
The above dhclient.conf lists media settings that are all handled by
wpa_supplicant so you don't specify any of them. Specifically you set
ssid, band, channel, and wep parameters; all these are handled by
wpa_supplicant.
ok... I removed the lines from dhclient.conf. I reboot, and run
wpa_supplicant manually with -d. The output is attached. My AP shows
up as , while my neighbors ssids are not hidden ('linksys' and
'default').
The intent is that dhclient deal only with the dhcp protocol and stop
being involved in the discovery and selection of wireless networks (a
job wpa_supplicant is better equipped to handle).
wpa_supplicant.conf
=
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
# Home Network
network={
ssid=home_ssid
scan_ssid=1
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=home_wepkey
}
# Office Network
network={
ssid=office_ssid
scan_ssid=1
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=office_wepkey
}
Not sure you need scan_ssid set, I'd leave it out.
If you have problems try disabling auto-startup of ath0 and run
wpa_supplicant by hand with the -d flag to see what it's doing.
Once that's going then enable startup in rc.conf. If you continue
to have problems provide the output wpa_supplicant -d -i ath0 -c
/etc/wpa_supplicant.conf (or similar) when you have trouble. There is
also a pending issue with locating some ap's that are setup to hide
their ssid. If one of the ap's is configured in this way contact me
directly--I've been trying to collect the info I need to identify
what's going on.
Both my APs (home and office) hide their ssids. One is a wrt54g
(home), the other is linksys as well... though I forget the model at
the moment (FWIW its a/b/g). What can I do to provide the info you
need?
These should work; I've had reports of problems with certain Cisco
ap's. Note however that configuring an ap to hide it's ssid adds no
real security.
I realize hidden ssids are of no real world use... but they keep *my*
neighbors out (you'll notice their ssids in the wpa_supp output).
Actually you can do just as well using mac acl's to restrict access.
Neither hidden ssid or mac acls are particularly useful except to keep
nuisance traffic out. Both can be trivially subverted; you need to go
to something like 802.1x or wpa for reasonable authentication of
stations (wpa-psk is inexpensive and easy to setup and is my preferred
method).
Understand that hidden ssid use comes at a price. Normally a station
will scan by sending a broadcast probe request frame on a channel and
listen for responses from all ap's. When an ap hides its ssid the
station must send a directed probe request frame for each ap that it
might be looking for. If you've got lots of ap's on the wire and/or
lots of ap's you're searching for your scan will take more time and soak
more air time. Given that it's trivial to passively monitor a network
and collect the ssid for an ap you can see why I suggest it's better to
use a mac acl if your intent is just to keep out naive users.
Sam
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
[EMAIL PROTECTED]
Any idea why my machine will never associate with my AP using
wpa_supplicant? Anything else I can provide that may shed some light? I
am using WEP... not WPA... could that part of the problem. Since WPA
was not previously supported I had been using WEP... and figured I'd
move up to WPA one step at a time.
All help is appreciated.
...stuff deleted...
The problem is that the current wpa_supplicant scanning code is pretty
simplistic. wpa_supplicant is a great bit of work but was written for
the least-common denominator device. When scanning it does not (yet)
handle ap's using hidden ssid except by deferring the work to the
operating system
Re: dhclient and wpa_supplicant
Eric Schuele wrote: Sam Leffler wrote: Eric Schuele wrote: Sam Leffler wrote: Eric Schuele wrote: big-snip Both my APs (home and office) hide their ssids. One is a wrt54g (home), the other is linksys as well... though I forget the model at the moment (FWIW its a/b/g). What can I do to provide the info you need? These should work; I've had reports of problems with certain Cisco ap's. Note however that configuring an ap to hide it's ssid adds no real security. FWIW... I set my AP to broadcast the ssid. It then quickly associated with it. But then dhclient 'broke the association' when it tried to acquire a lease (I have removed the media lines from dhclient.conf)? and subsequent wpa_supplicant attempts would no longer detect or associate with the AP... till I reboot. Attached is that log. What else can I provide to help. I'll look into this; thanks. Sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is there a laptop ?
5418 has worked for several years in HEAD. At this point the only ath chips not working in HEAD are those I haven't had access to (9280 and 9285) and 9280 support should go in shortly. About the only thing missing for ath is support for 11n (the 802.11 layer has supported 11n on other devices for several years and been used in various products). I can't comment on RELENG_7 support as I don't run it. Sam John Hendy wrote: For Atheros, the exact chipset is still important... my Macbook's Atheros AR5008 (aka AR5418) does not work with the FBSD ath driver. i386 works if I ndisgen a kernel module from a WinXP driver, but I have not been able to ndisgen a module successfully for amd64, which is what I'd like to run. The kernel panics every time I load it. I'm using FBSD-7.1-amd64, so I can't speak of the capabilities of 8.0, but the hardware notes do not seem to have changed re the ath driver ( http://www.freebsd.org/relnotes/CURRENT/hardware/support.html#WLAN)... Even though it only states that AR5005VL chips are unsupported, mine still is not picked up and it's definitely an AR5008. - John On Thu, Mar 12, 2009 at 8:46 AM, Ashish SHUKLA wahjava...@gmail.com wrote: Saifi Khan writes: [...] Do Atheros, Ralink, Realtek, Intel PRO/Wireless chipset work with FreeBSD ? Atheros chipsets work great with FreeBSD 8-CURRENT at least. And the driver is FOSS and blob free. No ideas about other chipsets. -- Ashish SHUKLA ___ freebsd-mob...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-mobile To unsubscribe, send any mail to freebsd-mobile-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: safe0 and kernel panic
Lowell Gilbert wrote: Rajkumar S [EMAIL PROTECTED] writes: Further to my previous mail. On 3/20/07, Rajkumar S [EMAIL PROTECTED] wrote: safe0 mem 0xf612-0xf6121fff irq 22 at device 10.0 on pci0 safe0: cannot allocate DMA tag device_attach: safe0 attach returned 6 While running cryptokeytest from /usr/src/tools/tools/crypto test 0 cryptokeytest: /dev/crypto: No such file or directory So it seems the driver is not really up. Seems like it. I can see where the safe(4) device might depend completely on DMA. I have no context. I see a device not attaching for some reason. Then /dev/crypto not being present (is cryptodev loaded in the kernel?). But a subject line about a panic. If you've submitted a PR please send me a pointer. Otherwise you might consider submitting one w/ details like what version of freebsd you're running. Sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: safe0 and kernel panic
Rajkumar S wrote: On 3/22/07, Sam Leffler [EMAIL PROTECTED] wrote: I have no context. I see a device not attaching for some reason. Then /dev/crypto not being present (is cryptodev loaded in the kernel?). But a subject line about a panic. The device is not attaching because bus_dma_tag_create function fails with the error ENOMEM. (in line 300, safe.c). I have changed BUS_DMA_ALLOCNOW flag in bus_dma_tag_create to BUS_DMA_COHERENT and the panic disappears. BUS_DMA_COHERENT was just taken randomly (as in some other flag) with no idea about it's use or purpose. Removing BUS_DMA_ALLOCNOW appears to just just hide the problem by deferring the allocation. Since other drivers are getting similar failures it's unlikely this is a safe bug. If you've submitted a PR please send me a pointer. Otherwise you might consider submitting one w/ details like what version of freebsd you're running. The PR Number is 110662. I have tried to put as much information as possible, I am always ready to provide additional details or do some testing/debugging. Thank you. I'll have to dig out one of my cards to test. Sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0: using obsoleted if_watchdog interface
Neil Short wrote: Recently cvsup'd. This is new and I'm not sure I understand it. dmesg... ... ath0: using obsoleted if_watchdog interface ignore it; it's just a reminder added when people decided to deprecate the api Sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD bind performance in FreeBSD 7
Ted Mittelstaedt wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kris Kennaway Sent: Monday, February 25, 2008 12:18 PM To: Oliver Herold; freebsd-questions@freebsd.org; [EMAIL PROTECTED] Subject: Re: FreeBSD bind performance in FreeBSD 7 Oliver Herold wrote: Hi, I saw this bind benchmarks just some minutes ago, http://new.isc.org/proj/dnsperf/OStest.html is this true for FreeBSD 7 (current state: RELENG_7/7.0R) too? Or is this something verified only for the state of development back in August 2007? I have been trying to replicate this. ISC have kindly given me access to their test data but I am seeing Linux performing much slower than FreeBSD with the same ISC workload. Kris, Every couple years we go through this with ISC. They come out with a new version of BIND then claim that nothing other than Linux can run it well. I've seen this nonsense before and it's tiresome. Incidentally, the query tool they used, queryperf, has been changed to dnsperf. Someone needs to look at that port - /usr/ports/dns/dnsperf - as it has a build depend of bind9 - well bind 9.3.4 is part of 6.3-RELEASE and I was rather irked when I ran the dnsperf port maker and the maker stupidly began the process of downloading and building the same version of BIND that I was already running on my server. * I am trying to understand what is different about the ISC configuration but have not yet found the cause. It's called Anti-FreeBSD bias. You won't find anything. e.g. NSD (ports/dns/nsd) is a much faster and more scalable DNS server than BIND (because it is better optimized for the smaller set of features it supports). When you make remarks like that it's no wonder ISC is in the business of slamming FreeBSD. People used to make the same claims about djbdns but I noticed over the last few years they don't seem to be doing that anymore. If nsd is so much better than yank bind out of the base FreeBSD and replace it with nsd. Of course that will make more work for me when I regen our nameservers here since nsd will be the first thing on the rm list. Please save your rhetoric for some other forum. The ISC folks have been working with us to understand what's going on. I'm not aware of any anit-FreeBSD slams going on; mostly uninformed comments. We believe FreeBSD does very well in any comparisons of the sort being discussed and there's still lots of room for improvement. As to nsd vs bind, understand they are very different applications w/ totally different goals. Comparing performance is not entirely fair and certainly is difficult. Kris investigated the performance of nsd mostly to understand how bind might scale if certain architectural changes were made to eliminate known bottlenecks in the application. Sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-RELEASE panic after ~4 hours
Alphons Fonz van Werven wrote: Matthias Apitz wrote: the main difference between home and work is: WEP at home and WPA2 at work; Which WiFi board are you using? Several drivers are known to cause panics when used with WPA. I am aware only of issues with USB adapters being removed while wpa_supplicant is running. This is a race in the usb code that I have worked around in the forthcoming vap code (not sure if the technique I used can be ported to RELENG_7). Regardless, for any issue to be pursued the usual info is required; the device identity, a stack trace, and if possible, debug msgs from the kernel prior to a problem (wlandebug enables net80211 msgs and every driver has a debug msg knob that may or may not require building a kernel w/ msgs enabled). iwi has most recently been tended by Andrew Thompson who is traveling so may not follow up for a bit (if sufficient info is provided). Sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OS throws away large packets
Yehonatan Yossef wrote: -Original Message- From: Tom Judge [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 8:21 PM To: Mr Y Cc: freebsd-questions@freebsd.org; [EMAIL PROTECTED] Subject: Re: OS throws away large packets Mr Y wrote: Hi all, I'm trying to implement Large Recieve Offload for an Ethernet driver on FreeBSD 6.3, but all my MTU packets are being thrown by the OS. I'm using mbuf chains in this imlpementation, each mbuf is a cluster of MCLBYTES bytes. They are linked by the m_next pointer. The first packet being thrown away is 2945 bytes long. Wireshark shows the packet that is being passed to the OS is correct. Do I need to set some OS parameter to make it recieve mbuf chains? Please help. Hi Yony, I seem to remember some discussion about this list last year see the following threads: http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm l http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm l From my limited reading of these threads just now and possibly bad memory. It would seem that the MRU to MTU relationship is defined in the nic driver rather than enforced further up the stack or at least that seamed to be the case with the bce driver. Hope this is helpful, Tom Hi Tom, From what I understand these threads are referring to the bce hardware configuration (bus configuration) and driver mbuf allocation size. Am I correct? In my case I'm not trying to receive packets MTU from the HW, but to chain mbuf clusters, each is MCLBYTES long, and pass the mbuf chain to the OS. Since tcpdump (analyzed by wireshark) catches the packets above the driver and reports a good packet (and 2945 bytes long), I assume my driver functionality is ok. From what I know tcpdump is supposed to immitate the way the stack sees the packet, yet it is discarded. My logic says there is an OS parameter handled by the driver (at net device init time for example) that will set the OS to receive large mbuf chains, or a kernel tcp parameter. Is the tcp stack submitted to the mtu somehow? I don't see where you've identified what version of the os you're working with. There's a check in the 802.3 input path on earlier systems to discard frames mtu. This was removed not too long ago with LRO in mind; check the history of sys/net/if_ethersubr.c. Sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
