Date: Sat, 4 Jan 2003 10:43:29 -0500 From: David Magda <dmagda+fstable@magda.ca> To: Evren Yurtesen <eyurtese@turkuamk.fi> Cc: Sten Daniel S?rsdal <sten.daniel.sorsdal@wan.no>, "Wright, Michaelx L" <michaelx.l.wright@intel.com>, fkittred@gwi.net, Michael Sierchio <kudzu@tenebras.com>, freebsd-stable@FreeBSD.ORG, wpaul@ctr.columbia.edu Subject: Re: wi0 and mtu setting [bad idea] Message-ID: <20030104154328.GA266@number6.magda.ca> In-Reply-To: <Pine.A41.4.10.10301041436440.19242-100000@bessel.tekniikka.turkuamk.fi> References: <0AF1BBDF1218F14E9B4CCE414744E70F07DE29@exchange.wanglobal.net> <Pine.A41.4.10.10301041436440.19242-100000@bessel.tekniikka.turkuamk.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 04, 2003 at 02:41:38PM +0200, Evren Yurtesen wrote:
> I just dont understand why FreeBSD people have to make this wi driver so
> tight in standarts even though there are wireless cards which support
> non-standard(and sometimes nice) things which can be useful. I definetely
> disagree that something should be in standard so you will allow setting of
> it!
The wi(4) driver is treated as an Ethernet device, so it inherits many
of the characteristics of such devices. From /sys/dev/wi/if_wi.c:
[...]
ifp->if_softc = sc;
ifp->if_unit = sc->wi_unit;
ifp->if_name = "wi";
ifp->if_mtu = ETHERMTU;
ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
ifp->if_ioctl = wi_ioctl;
ifp->if_output = ether_output;
ifp->if_start = wi_start;
ifp->if_watchdog = wi_watchdog;
ifp->if_init = wi_init;
ifp->if_baudrate = 10000000;
ifp->if_snd.ifq_maxlen = IFQ_MAXLEN;
[...]
And if you look at /usr/include/net/ethernet.h:
[...]
#define ETHERMTU (ETHER_MAX_LEN-ETHER_HDR_LEN-ETHER_CRC_LEN)
#define ETHERMIN (ETHER_MIN_LEN-ETHER_HDR_LEN-ETHER_CRC_LEN)
[...]
If you want to change this you'll have to hack code. Since this is the
first I've heard about it, I don't think many people share your concern
regarding the issue. Is there any reason why you need this
functionality?
> For example in /etc/defaults/rc.conf it says
> -----------------------------------------------
> tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN
> # NOTE: this violates the TCP specification
> -----------------------------------------------
> So why do you let this to violate TCP specifications but you cant let user
> to violate ethernet specifications?
Perhaps because this does not necessarily break inter-operability
between different hosts, but changing the MTU could.
There are also issues with compatibility when talking about Ethernet
(though someone mentioned that "WiFi" isn't truly Ethernet). If the
number is less then 1536 most Ethernet drivers assume one type of
encapsulation is used (RFC 894, for "Ethernet" networks), while if it's
greater then 1536 another type is (RFC 1042, for "IEEE 802.3" networks).
Messing around with the MTU is fine if you can control all the hosts on
the network, but things can get real messy real quickly if any mistakes
are made.
--
David Magda <dmagda at ee.ryerson.ca>
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030104154328.GA266>