* Re: [PATCH] via-velocity: allow MTU size less than 1500 bytes
From: Jeff Garzik @ 2006-05-28 20:36 UTC (permalink / raw)
To: Francois Romieu; +Cc: Jay Cliburn, netdev
In-Reply-To: <20060527193118.GA7998@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Jeff Garzik <jgarzik@pobox.com> :
> [...]
>> ACK, but patch won't apply:
>
> I have regenerated it against mainline. It can be pulled from the repository
>
> git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git velocity
pulled, thanks
^ permalink raw reply
* Re: e1000 poor network performance - 2.6.17-rc5-g705af309
From: Aravind Gottipati @ 2006-05-28 17:49 UTC (permalink / raw)
To: netdev
In-Reply-To: <20060528090409.08a9bce8@localhost.localdomain>
On Sun, May 28, 2006 at 09:04:09AM -0700, Stephen Hemminger wrote:
> What is the interrupt assignment on this machine?
> cat /proc/interrupts
root@dogmatrix:~# cat /proc/interrupts
CPU0
0: 250325 IO-APIC-edge timer
1: 386 IO-APIC-edge i8042
8: 1 IO-APIC-edge rtc
9: 208 IO-APIC-level acpi
12: 3000 IO-APIC-edge i8042
14: 38 IO-APIC-edge ide0
20: 3815 IO-APIC-level libata, yenta, uhci_hcd:usb2, eth0, i915@pci:0000:00:02.0
21: 2 IO-APIC-level ohci1394, uhci_hcd:usb3
22: 0 IO-APIC-level sdhci:slot0, uhci_hcd:usb4
23: 78 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb5
NMI: 0
LOC: 242918
ERR: 0
MIS: 0
root@dogmatrix:~#
^ permalink raw reply
* Re: e1000 poor network performance - 2.6.17-rc5-g705af309
From: Stephen Hemminger @ 2006-05-28 16:04 UTC (permalink / raw)
To: Aravind Gottipati; +Cc: netdev
In-Reply-To: <20060528074310.GA16499@SDF.LONESTAR.ORG>
On Sun, 28 May 2006 07:43:10 +0000
Aravind Gottipati <aravind@freeshell.org> wrote:
> On Sat, May 27, 2006 at 02:10:17PM -0700, Jesse Brandeburg wrote:
> > What kind of poor performance? what test? please send the output of
> > ethtool -e ethX and ethtool -S ethX after you've been having problems.
>
> I first noticed the problem (slow speed) when pinging sites. I then
> noticed that the problem occured on normal ssh sessions and ftp/http
> downloads as well. I have a spare pcmcia card that I am using on the
> same laptop so I have something to compare it against. In all the
> readings below, eth0 is the builtin Intel 82573L (PCI-Express) card and
> eth2 is a pcmcia D-link card (8139too driver).
>
> You can see below the ping times varying randomly through eth0. Compare
> these with the ping times through eth2 (at the bottom). Also there are
> some collisions in the ethtool -S output here (I am on a 10/100 hub), I
> see the same performance using a switch as well.
>
> I am not subscribed to the list, so please cc me on your responses.
>
> Thank you,
>
> Aravind.
What is the interrupt assignment on this machine?
cat /proc/interrupts
^ permalink raw reply
* Re: Refactor Netlink connector?
From: Evgeniy Polyakov @ 2006-05-28 15:33 UTC (permalink / raw)
To: James Morris; +Cc: netdev, David S. Miller, tgraf, Stephen Smalley
In-Reply-To: <Pine.LNX.4.64.0605271303050.13104@d.namei>
On Sat, May 27, 2006 at 01:21:05PM -0400, James Morris (jmorris@namei.org) wrote:
> On Sat, 27 May 2006, James Morris wrote:
>
> > One of the problems is that different Netlink protocols bury their
> > commands at different levels, so the SELinux code has to know how how deep
> > to dig (and then do the digging) to determine exactly which command is
> > being called.
>
> Actually, a possible solution here is to completely remove all internal
> knowledge of netlink messages from SELinux and have the netfilter
> framework and protocols provide methods to determine message types and
> permissions.
>
> One of the issues still to resolve for SELinux and generic netlink is that
> we don't know what the netlink protocol for the socket really is until
> messages are sent over it, so some socket-level perms for NETLINK_GENERIC
> will have to be handed out to all potential users (although actual
> transfer of data can be mediated at a finer granularity).
Does SELinux have security handlers for each type of possible ioctls
over the world? Each ioctl number is like each netlink type of message,
but instead there is only one check per ioctl syscall as long as lsm
hook for socket's send/recv syscall.
It could be interesting and quite challenging to force all ioctl users
to have the same structure under each ioctl number so SELinux could
control for example disk geometry or time and date requests...
And, btw, what is the purpose of controlling netlink messages?
Does it prevent malicious userspace application to receive events from
malicious kernel module?
> - James
> --
> James Morris
> <jmorris@namei.org>
--
Evgeniy Polyakov
^ permalink raw reply
* Re: Management packet 0x70 -> connection broken
From: Guennadi Liakhovetski @ 2006-05-28 11:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <Pine.LNX.4.60.0605281328470.4491@poirot.grange>
On Sun, 28 May 2006, Guennadi Liakhovetski wrote:
> ieee80211: eth1: Unknown management packet: 112
a small addendum: below is the function from the original driver, where
they process management packets. Although they don't have special
processing for 0x70, they seem to be doing lots of stuff for
"unrecognised" packets. Complete sources are at
http://zd1211.ath.cx/download/, the new (rewrite) driver, that uses the
ieee80211 layer is at http://www.deine-taler.de/zd1211/snapshots/
Thanks
Guennadi
---
Guennadi Liakhovetski
__inline unsigned long
Cfg_CtrlSetting(
struct zd1205_private *macp,
zd1205_SwTcb_t *pSwTcb,
wla_Header_t *pWlaHdr,
ctrl_Set_parm_t *pSetParms
)
{
zd1205_Ctrl_Set_t *pCtrlSet = pSwTcb->pHwCtrlPtr;
u8 tmp;
u16 Len = 0;
u16 NextLen = 0;
u16 LenInUs = 0;
u16 NextLenInUs = 0;
u8 Service;
u8 TxRate;
u8 Rate = pSetParms->Rate;
u8 Preamble = pSetParms->Preamble;
u32 CurrFragLen = pSetParms->CurrFragLen;
u32 NextFragLen = pSetParms->NextFragLen;
u8 encryType = pSetParms->encryType;
//u8 vapId = pSetParms->vapId;
u8 bMgtFrame = 0;
u8 bGroupAddr = 0;
u8 EnCipher = ((pWlaHdr->FrameCtrl[1] & ENCRY_BIT) ? 1 : 0);
u16 FragNum = (pWlaHdr->SeqCtrl[0] & 0x0F);
card_Setting_t *pCardSettting = &macp->cardSetting;
u16 FrameType = pWlaHdr->FrameCtrl[0];
u8 bBusrt = 0;
#ifdef ZD1211B
u8 LengthDiff=0;
#endif
memset(pCtrlSet,0,sizeof(zd1205_Ctrl_Set_t));
if (Rate > macp->AdapterMaxRate)
Rate = macp->AdapterMaxRate;
if ((FrameType & 0x0c) == MANAGEMENT)
{
bMgtFrame = 1;
Rate = dot11Obj.BasicRate;
}
if ((FrameType & 0x0c) == DATA)
{
write_str(DbgStr101, EnCipher);
}
if (bMgtFrame)
{
if ((FrameType == PROBE_RSP) || (FrameType == PROBE_REQ)) {
// Ensure Site-Survey smooth
Rate = RATE_1M;
Preamble = 0;
}
}
if (FrameType == PS_POLL)
{
// For compatibility with D-Link AP
Rate = RATE_1M;
Preamble = 0;
}
if ((Rate == RATE_1M) && (Preamble == 1))
{ //1M && short preamble
Rate = RATE_2M;
}
if (macp->bFixedRate)
{
if (!bMgtFrame)
Rate = pCardSettting->FixedRate;
}
pSwTcb->Rate = Rate;
//FPRINT_V("zdinline Rate", Rate);
#if !defined(OFDM)
pCtrlSet->CtrlSetting[0] = (Rate | (Preamble << 5));
#else
if (Rate < RATE_6M)
{ //CCK frame
pCtrlSet->CtrlSetting[0] = (Rate | (Preamble << 5));
//``JWEI 2003/12/22
#if fTX_PWR_CTRL
if ((macp->TxOFDMCnt > 0) && (macp->TxOFDMCnt < cTX_SENT_LEN))
macp->TxOFDMCnt --;
macp->TxPwrCCK ++;
#endif
} else
{
#if fTX_PWR_CTRL
macp->TxPwrOFDM ++;
macp->TxOFDMCnt ++;
if (Rate == RATE_48M) {
if (macp->TxOFDMType != cTX_48M)
macp->TxOFDMCnt = 0;
macp->TxOFDMType = cTX_48M;
} else if (Rate == RATE_54M) {
if (macp->TxOFDMType != cTX_54M)
macp->TxOFDMCnt = 0;
macp->TxOFDMType = cTX_54M;
} else {
if (macp->TxOFDMType != cTX_OFDM)
macp->TxOFDMCnt = 0;
macp->TxOFDMType = cTX_OFDM;
}
#endif
pCtrlSet->CtrlSetting[0] = OfdmRateTbl[Rate];
}
#endif
TxRate = Rate;
//keep current Tx rate
pCardSettting->CurrTxRate = TxRate;
/* Length in byte */
if (EnCipher)
{
if (!pCardSettting->SwCipher) {
write_str(DbgStr102, encryType);
switch(encryType) {
case WEP64:
case WEP128:
case WEP256:
Len = CurrFragLen + 36; /* Header(24) + CRC32(4) + IV(4) + ICV(4) */
NextLen = NextFragLen + 36;
#ifdef ZD1211B
LengthDiff=17;
#endif
break;
case TKIP:
write_str(DbgStr100, CurrFragLen);
Len = CurrFragLen + 40; /* Header(24) + CRC32(4) + IV(4) + EIV(4) + ICV(4) */
NextLen = NextFragLen + 40;
#ifdef ZD1211B
LengthDiff=17;
#endif
break;
case AES:
Len = CurrFragLen + 44; /* Header(24) + CRC32(4) + IV(4) + ExtendedIV(4) + MIC(8) */
NextLen = NextFragLen + 44;
#ifdef ZD1211B
LengthDiff=13;
#endif
//FPRINT_V("Len", Len);
break;
default:
printk(KERN_DEBUG "error encryType = %x\n", encryType);
break;
}
} else { //use software encryption
if (pCardSettting->DynKeyMode == DYN_KEY_TKIP) {
if ((pWlaHdr->DA[0] & BIT_0) && (pCardSettting->WpaBcKeyLen != 32)) { //multicast
Len = CurrFragLen + 32; // Header(24) + CRC32(4) + IV(4), ICV was packed under payload
NextLen = NextFragLen + 32;
} else {
Len = CurrFragLen + 36; // Header(24) + CRC32(4) + IV(4) + ExtendIV(4), ICV was packed under payload
NextLen = NextFragLen + 36;
}
} else {
Len = CurrFragLen + 32; // Header(24) + CRC32(4) + IV(4), ICV was packed under payload
NextLen = NextFragLen + 32;
}
}
} else
{ // no cipher
Len = CurrFragLen + 28; /* Header(24) + CRC32(4) */
NextLen = NextFragLen + 28;
#ifdef ZD1211B
LengthDiff=21;
#endif
}
/* Corret some exceptions */
if (FrameType == PS_POLL)
{
Len = CurrFragLen + 20; // Header(16) + CRC32(4)
}
/* Corret some exceptions */
if (NextFragLen == 0)
NextLen = 0;
pCtrlSet->CtrlSetting[1] = (u8)Len; /* low byte */
pCtrlSet->CtrlSetting[2] = (u8)(Len >> 8); /* high byte */
/* TCB physical address */
pCtrlSet->CtrlSetting[3] = (u8)(pSwTcb->TcbPhys);
pCtrlSet->CtrlSetting[4] = (u8)(pSwTcb->TcbPhys >> 8);
pCtrlSet->CtrlSetting[5] = (u8)(pSwTcb->TcbPhys >> 16);
pCtrlSet->CtrlSetting[6] = (u8)(pSwTcb->TcbPhys >> 24);
pCtrlSet->CtrlSetting[7] = 0x00;
pCtrlSet->CtrlSetting[8] = 0x00;
pCtrlSet->CtrlSetting[9] = 0x00;
pCtrlSet->CtrlSetting[10] = 0x00;
/* Misc */
tmp = 0;
if (!FragNum)
{
tmp |= BIT_0;
if (macp->bTxBurstEnable) {
if (macp->activeTxQ->count > 0) {
// AT LEAST one packet in ActiveChainList
macp->TxBurstCount++;
if (macp->TxBurstCount == 3) // only 3 packets
macp->TxBurstCount = 0;
} else {
// recount again, next packet will back off
macp->TxBurstCount = 0;
}
// burst mode
if (macp->TxBurstCount == 0) {
tmp |= BIT_0; //need back off
} else {
tmp &= ~BIT_0; //burst, no need back off
bBusrt = 1;
pCtrlSet->CtrlSetting[0] |= BIT_7;
}
}
}
if (pWlaHdr->DA[0] & BIT_0)
{ /* Multicast */
bGroupAddr = 1;
tmp |= BIT_1;
}
//if (bMgtFrame){
// tmp |= BIT_3;
//}
if (FrameType == PS_POLL) //AP don't send PS_POLL
tmp |= BIT_2;
#ifndef HOST_IF_USB
if ((pCardSettting->BssType == INDEPENDENT_BSS) && (!bMgtFrame))
{
if (zd1205_DestPowerSave(macp, &pWlaHdr->DA[0])) {
tmp |= BIT_4;
}
}
#endif
if (Len > pCardSettting->RTSThreshold)
{
if ((!bMgtFrame) && (!bGroupAddr))
tmp |= BIT_5;
}
#if (defined(GCCK) && defined(OFDM))
if (TxRate > RATE_11M)
{
if (tmp & BIT_5) {
// need to send RTS or CTS, in OFDM only send CTS, in CCK send RTS
tmp &= ~BIT_5;
tmp |= BIT_7;
} else if (dot11Obj.ConfigFlag & ENABLE_PROTECTION_SET) {
// id SelfCTS on, force send CTS when OFDM
tmp |= BIT_7;
}
}
#endif
if ((EnCipher) && (!pCardSettting->SwCipher))
{
tmp |= BIT_6;
}
if ((macp->bTxBurstEnable))
{
if (!bBusrt)
// bBusrt off, this is the first one, force send CTS
tmp |= BIT_7;
else
// bBusrt on, this is the burst one, no need CTS
tmp &= ~BIT_7;
}
pCtrlSet->CtrlSetting[11] = tmp;
/* Address1 */
pCtrlSet->CtrlSetting[12] = pWlaHdr->DA[0];
pCtrlSet->CtrlSetting[13] = pWlaHdr->DA[1];
pCtrlSet->CtrlSetting[14] = pWlaHdr->DA[2];
pCtrlSet->CtrlSetting[15] = pWlaHdr->DA[3];
pCtrlSet->CtrlSetting[16] = pWlaHdr->DA[4];
pCtrlSet->CtrlSetting[17] = pWlaHdr->DA[5];
if (FrameType == DATA)
{
macp->TotalTxDataFrmBytes += Len;
if (pCtrlSet->CtrlSetting[12] & BIT_0) {
macp->txMulticastFrm ++;
macp->txMulticastOctets += CurrFragLen;
} else {
macp->txUnicastFrm ++;
macp->txUnicastOctets += CurrFragLen;
macp->txDataPerSec += CurrFragLen;
}
}
/* NextLen */
#ifdef ZD1211
if (NextLen)
{
pCtrlSet->CtrlSetting[18] = (u8)NextLen;
pCtrlSet->CtrlSetting[19] = (u8)(NextLen >> 8);
}
#elif defined(ZD1211B)
pSwTcb->LengthDiff = LengthDiff;
#endif
/* LenInUs */
Cal_Us_Service(TxRate, Len, &LenInUs, &Service);
if (macp->bTxBurstEnable)
if (!bBusrt)
LenInUs = LenInUs * 4;
pCtrlSet->CtrlSetting[20] = (u8)LenInUs;
pCtrlSet->CtrlSetting[21] = (u8)(LenInUs >> 8);
/* Service */
#if !(defined(GCCK) && defined(OFDM))
pCtrlSet->CtrlSetting[22] = Service;
#else
if (Rate < RATE_6M)
{
pCtrlSet->CtrlSetting[22] = Service;
} else
{
pCtrlSet->CtrlSetting[22] = 0;
}
#endif
if (NextLen == 0)
{
NextLenInUs = 0;
} else
{
Cal_Us_Service(TxRate, NextLen, &NextLenInUs, &Service);
pCtrlSet->CtrlSetting[23] = (u8)NextLenInUs;
pCtrlSet->CtrlSetting[24] = (u8)(NextLenInUs >> 8);
#ifdef OFDM
// NextLen
// backup NextLen, because OFDM use these 2 bytes as total length,
// so we backup here for Retry fail use.
pCtrlSet->CtrlSetting[26] = (u8)NextLen;
pCtrlSet->CtrlSetting[27] = (u8)(NextLen >> 8);
#endif
}
return(CTRL_SIZE);
}
^ permalink raw reply
* Management packet 0x70 -> connection broken
From: Guennadi Liakhovetski @ 2006-05-28 11:33 UTC (permalink / raw)
To: netdev
Hi all
Using the zd1211rw driver on a ppc under Sarge, 2.6.17-rc2 with some
ieee80211 / softmac patches I get
ieee80211: eth1: Unknown management packet: 112
and then the connection was broken:-( What is the 0x70 packet? Have been
using the original zd1211 vendor-based driver before, probably, these
packets also were seen, but the connection didn't break. I can put a debug
in the original driver to see what happens when these packets arrive.
Basically they just ignore them as well as ieee80211 now, but without
fatal consequences... Using openvpn over eth1 if it matters.
Not subscribed, please cc.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [1/4] [IPSEC] xfrm: Undo afinfo lock proliferation
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-05-28 9:35 UTC (permalink / raw)
To: davem; +Cc: herbert, netdev, yoshfuji
In-Reply-To: <20060527.230302.85071200.davem@davemloft.net>
In article <20060527.230302.85071200.davem@davemloft.net> (at Sat, 27 May 2006 23:03:02 -0700 (PDT)), David Miller <davem@davemloft.net> says:
> > Please don't get me wrong. What I removed here doesn't work at all to
> > begin with. I was just pointing out the possible reason why this code
> > existed in the first place.
>
> Right the existing code didn't work at all. Herbert is not
> making things any worse or less functional. The task for
> making ipv6 unloadable as a module remains equally arduous
> both before and after Herbert's changes :-)
Okay.
--yoshfuji
^ permalink raw reply
* Re: e1000 poor network performance - 2.6.17-rc5-g705af309
From: Aravind Gottipati @ 2006-05-28 7:43 UTC (permalink / raw)
To: netdev
In-Reply-To: <4807377b0605271410j39532f44j2cafd3239d40bf31@mail.gmail.com>
On Sat, May 27, 2006 at 02:10:17PM -0700, Jesse Brandeburg wrote:
> What kind of poor performance? what test? please send the output of
> ethtool -e ethX and ethtool -S ethX after you've been having problems.
I first noticed the problem (slow speed) when pinging sites. I then
noticed that the problem occured on normal ssh sessions and ftp/http
downloads as well. I have a spare pcmcia card that I am using on the
same laptop so I have something to compare it against. In all the
readings below, eth0 is the builtin Intel 82573L (PCI-Express) card and
eth2 is a pcmcia D-link card (8139too driver).
You can see below the ping times varying randomly through eth0. Compare
these with the ping times through eth2 (at the bottom). Also there are
some collisions in the ethtool -S output here (I am on a 10/100 hub), I
see the same performance using a switch as well.
I am not subscribed to the list, so please cc me on your responses.
Thank you,
Aravind.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ping via eth0
root@dogmatrix:~# ping www.google.com
PING www.l.google.com (66.102.7.99): 56 data bytes
64 bytes from 66.102.7.99: icmp_seq=0 ttl=239 time=135.0 ms
64 bytes from 66.102.7.99: icmp_seq=1 ttl=239 time=601.3 ms
64 bytes from 66.102.7.99: icmp_seq=2 ttl=239 time=133.2 ms
64 bytes from 66.102.7.99: icmp_seq=3 ttl=239 time=904.8 ms
64 bytes from 66.102.7.99: icmp_seq=4 ttl=239 time=131.3 ms
64 bytes from 66.102.7.99: icmp_seq=5 ttl=239 time=1001.3 ms
64 bytes from 66.102.7.99: icmp_seq=6 ttl=239 time=129.4 ms
64 bytes from 66.102.7.99: icmp_seq=7 ttl=239 time=1001.5 ms
64 bytes from 66.102.7.99: icmp_seq=8 ttl=239 time=127.5 ms
64 bytes from 66.102.7.99: icmp_seq=9 ttl=239 time=1001.0 ms
64 bytes from 66.102.7.99: icmp_seq=10 ttl=239 time=125.2 ms
64 bytes from 66.102.7.99: icmp_seq=11 ttl=239 time=19.8 ms
64 bytes from 66.102.7.99: icmp_seq=12 ttl=239 time=123.2 ms
64 bytes from 66.102.7.99: icmp_seq=13 ttl=239 time=1001.3 ms
64 bytes from 66.102.7.99: icmp_seq=14 ttl=239 time=121.4 ms
64 bytes from 66.102.7.99: icmp_seq=15 ttl=239 time=1001.4 ms
64 bytes from 66.102.7.99: icmp_seq=16 ttl=239 time=119.5 ms
--- www.l.google.com ping statistics ---
17 packets transmitted, 17 packets received, 0% packet loss
round-trip min/avg/max = 19.8/451.6/1001.5 ms
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
root@dogmatrix:~# ethtool -e eth0
Offset Values
------ ------
0x0000 00 0a e4 3f a5 da 30 0b b2 ff 51 00 ff ff ff ff
0x0010 53 00 03 02 6b 02 7e 20 aa 17 9a 10 86 80 df 80
0x0020 00 00 00 20 54 7e 00 00 14 00 da 00 04 00 00 27
0x0030 c9 6c 50 31 3e 07 0b 04 8b 29 00 00 00 f0 02 0f
0x0040 08 10 00 00 04 0f ff 7f 01 4d ff ff ff ff ff ff
0x0050 14 00 1d 00 14 00 1d 00 af aa 1e 00 00 00 1d 00
0x0060 00 01 00 40 1f 12 07 40 ff ff ff ff ff ff ff ff
0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 73 79
root@dogmatrix:~# ethtool -S eth0
NIC statistics:
rx_packets: 1757
tx_packets: 1995
rx_bytes: 657421
tx_bytes: 228828
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 0
collisions: 13
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 27
tx_single_coll_ok: 2
tx_multi_coll_ok: 5
tx_timeout_count: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 0
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 657421
rx_csum_offload_good: 1709
rx_csum_offload_errors: 0
rx_header_split: 1433
alloc_rx_buff_failed: 0
root@dogmatrix:~#
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The same ping using eth2
root@dogmatrix:~# ping www.google.com
PING www.l.google.com (66.102.7.99): 56 data bytes
64 bytes from 66.102.7.99: icmp_seq=0 ttl=239 time=16.3 ms
64 bytes from 66.102.7.99: icmp_seq=1 ttl=239 time=15.2 ms
64 bytes from 66.102.7.99: icmp_seq=2 ttl=239 time=14.8 ms
64 bytes from 66.102.7.99: icmp_seq=3 ttl=239 time=15.1 ms
64 bytes from 66.102.7.99: icmp_seq=4 ttl=239 time=16.6 ms
64 bytes from 66.102.7.99: icmp_seq=5 ttl=239 time=15.8 ms
64 bytes from 66.102.7.99: icmp_seq=6 ttl=239 time=14.9 ms
64 bytes from 66.102.7.99: icmp_seq=7 ttl=239 time=14.7 ms
64 bytes from 66.102.7.99: icmp_seq=8 ttl=239 time=14.6 ms
--- www.l.google.com ping statistics ---
9 packets transmitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 14.6/15.3/16.6 ms
^ permalink raw reply
* Re: Wireless patches to push for 2.6.18?
From: Stefano Brivio @ 2006-05-28 7:37 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev
In-Reply-To: <20060526195855.GD32487@tuxdriver.com>
On Fri, 26 May 2006 15:59:00 -0400
"John W. Linville" <linville@tuxdriver.com> wrote:
> Anyone have anything else they are holding-back for 2.6.18?
We would like to get PCI-E support patchset into bcm43xx driver as well,
but we are still testing it. I hope we'll be ready in a few days.
--
Ciao
Stefano
^ permalink raw reply
* Re: [0/4] [IPSEC]: Add xfrm_mode support
From: David Miller @ 2006-05-28 6:03 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20060527113236.GA4203@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 27 May 2006 21:32:36 +1000
> These patches abstract out the protocol-specific encapsulation parts of
> IPsec into what I've termed xfrm_mode objects. This allows us to share
> a little bit more code. But more importantly, it allows us to add new
> encapsulation modes such as BEET or v4/v6 and v6/v4 without polluting
> the generic xfrm_input/xfrm_output paths.
This is the second time I've reviewed this so I already know
it's good stuff :-)
I'll toss this into net-2.6.18, thanks a lot!
^ permalink raw reply
* Re: [1/4] [IPSEC] xfrm: Undo afinfo lock proliferation
From: David Miller @ 2006-05-28 6:03 UTC (permalink / raw)
To: herbert; +Cc: yoshfuji, netdev
In-Reply-To: <E1FjxaL-0002Gv-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 27 May 2006 22:08:01 +1000
> YOSHIFUJI Hideaki / ???? <yoshfuji@linux-ipv6.org> wrote:
> > In article <20060527113345.GA4737@gondor.apana.org.au> (at Sat, 27 May 2006 21:33:45 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:
> >
> >> As far as I can gather it's an attempt to guard against the removal of
> >> the corresponding modules. Since neither module can be unloaded at all
> >> we can leave it to whoever fixes up IPv6 unloading :)
> >
> > I disagree. Please do not add another mess.
>
> Please don't get me wrong. What I removed here doesn't work at all to
> begin with. I was just pointing out the possible reason why this code
> existed in the first place.
Right the existing code didn't work at all. Herbert is not
making things any worse or less functional. The task for
making ipv6 unloadable as a module remains equally arduous
both before and after Herbert's changes :-)
^ permalink raw reply
* [PATCH] unsigned long => __be32 in icmp_redirect()
From: Alexey Dobriyan @ 2006-05-27 21:29 UTC (permalink / raw)
To: netdev
ip_rt_redirect() expects __be32 as second arg, so...
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
--- a/net/ipv4/icmp.c
+++ 1/net/ipv4/icmp.c
@@ -730,7 +730,7 @@ out_err:
static void icmp_redirect(struct sk_buff *skb)
{
struct iphdr *iph;
- unsigned long ip;
+ __be32 ip;
if (skb->len < sizeof(struct iphdr))
goto out_err;
^ permalink raw reply
* Re: e1000 poor network performance - 2.6.17-rc5-g705af309
From: Jesse Brandeburg @ 2006-05-27 21:10 UTC (permalink / raw)
To: Aravind Gottipati; +Cc: linux-kernel, NetDEV list
In-Reply-To: <20060526212243.GA19250@SDF.LONESTAR.ORG>
On 5/26/06, Aravind Gottipati <aravind@freeshell.org> wrote:
> Hi,
>
> I recently started running linux on a new x60 thinkpad and started
> noticing really poor network performance with this kernel. I saw some
> archived threads from a while back saying this could be related to
> conntracking. Disabled that (rmmod ip_conntrack) did not fix the
> problem. I also tried disabling tso but that didn't have any effect
> either. I can reproduce the problem when connected to a 100Mbps switch
> (I don't have a GigE network to test this with).
First, lets move this over to netdev (see CC)
> This laptop uses the Intel 82573L (PCI-Express) chip. I'd be glad to
> assist with any toubleshooting/testing w.r.t this. I am not subscribed
> to the list, so please cc me on any replies.
What kind of poor performance? what test? please send the output of
ethtool -e ethX and ethtool -S ethX after you've been having problems.
please provide more details and we can see if we can help.
Jesse
^ permalink raw reply
* [PATCH] Right prototype of __raw_v4_lookup()
From: Alexey Dobriyan @ 2006-05-27 21:09 UTC (permalink / raw)
To: netdev
All users pass 32-bit values as addresses and internally they're compared with
32-bit entities. So, change "laddr" and "raddr" types to __be32.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
include/net/raw.h | 2 +-
net/ipv4/raw.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/include/net/raw.h
+++ 1/include/net/raw.h
@@ -36,7 +36,7 @@ extern rwlock_t raw_v4_lock;
extern struct sock *__raw_v4_lookup(struct sock *sk, unsigned short num,
- unsigned long raddr, unsigned long laddr,
+ __be32 raddr, __be32 laddr,
int dif);
extern int raw_v4_input(struct sk_buff *skb, struct iphdr *iph, int hash);
--- linux-vanilla/net/ipv4/raw.c
+++ linux-1/net/ipv4/raw.c
@@ -103,7 +103,7 @@ static void raw_v4_unhash(struct sock *s
}
struct sock *__raw_v4_lookup(struct sock *sk, unsigned short num,
- unsigned long raddr, unsigned long laddr,
+ __be32 raddr, __be32 laddr,
int dif)
{
struct hlist_node *node;
^ permalink raw reply
* Re: CRC16 in rt2x00
From: Ivo van Doorn @ 2006-05-27 20:46 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: netdev
In-Reply-To: <20060527163059.GB14973@procyon.home>
[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]
On Saturday 27 May 2006 18:30, Sergey Vlasov wrote:
> On Sat, May 27, 2006 at 04:24:07PM +0200, Ivo van Doorn wrote:
> > On Saturday 27 May 2006 15:55, Sergey Vlasov wrote:
> [skip]
> > > However, fs/udf/crc.c has exactly the same CRC table as rt2x00:
> [skip]
> > > This is a bit-reversed form of CRC-CCITT supported by lib/crc-ccitt.c.
> > > Unfortunately, this does not help much, because converting one form to
> > > the other is too expensive (you would need to reverse bits in all data
> > > bytes, and then reverse bits in the 16-bit result).
> > >
> > > BTW, there is more CRC code duplication in drivers/bluetooth/hci_bcsp.c
> > > (bcsp_crc_update() seems to give the same result as crc_ccitt_byte()).
> > >
> > > In drivers/media/dvb/frontends/nxt200x.c, nxt200x_crc() seems to give
> > > the same result as rt2x00crc_byte() (but without using a table).
> > >
> > > drivers/net/wan/cycx_drv.c:checksum() is also some mutated version of
> > > CRC-CCITT (adding two additional zero bytes at the end of data makes it
> > > return the same result as rt2x00crc()).
>
> More stealth CRC implementations:
>
> - drivers/ieee1394/csr.c:csr_crc16() - the same as rt2x00crc();
>
> - drivers/ieee1394/csr1212.c:csr1212_crc16() - again the same as
> rt2x00crc(), except the final byteswap;
>
> - drivers/net/wireless/wavelan.c:psa_crc() is plain crc16(); it is
> duplicated in drivers/net/wireless/wavelan_cs.c;
>
> - drivers/scsi/FlashPoint.c:FPT_CalcCrc16() is also crc16();
>
> > Interesting, so it would actually be usefull to move the nxt200x
> > crc16 implemetation into the crc16 library (Is not using a table
> > preferred over using a table?)
>
> Using a table is probably faster, but consumes more memory.
>
> > And make rt2x00 and fs/udf/crc.c make use of this library?
> >
> > And perhaps hci_bcsp could be updated to use crc_ccitt_byte() instead?
Thanks,
I will take another look at the drivers as well and see which drivers
could best be udpated to use the kernel library instead of using
its own implementation.
This will take a couple of days, but then I should have a couple of
patches ready to add some crc libs and update the drivers to make
use of these labs.
Ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] via-velocity: allow MTU size less than 1500 bytes
From: Francois Romieu @ 2006-05-27 19:31 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jay Cliburn, netdev
In-Reply-To: <4477B76B.70700@pobox.com>
Jeff Garzik <jgarzik@pobox.com> :
[...]
> ACK, but patch won't apply:
I have regenerated it against mainline. It can be pulled from the repository
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git velocity
--
Ueimor
^ permalink raw reply
* Re: Refactor Netlink connector?
From: James Morris @ 2006-05-27 17:21 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev, David S. Miller, tgraf, Stephen Smalley
In-Reply-To: <Pine.LNX.4.64.0605271223390.12872@d.namei>
On Sat, 27 May 2006, James Morris wrote:
> One of the problems is that different Netlink protocols bury their
> commands at different levels, so the SELinux code has to know how how deep
> to dig (and then do the digging) to determine exactly which command is
> being called.
Actually, a possible solution here is to completely remove all internal
knowledge of netlink messages from SELinux and have the netfilter
framework and protocols provide methods to determine message types and
permissions.
One of the issues still to resolve for SELinux and generic netlink is that
we don't know what the netlink protocol for the socket really is until
messages are sent over it, so some socket-level perms for NETLINK_GENERIC
will have to be handed out to all potential users (although actual
transfer of data can be mediated at a finer granularity).
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH v3] bridge: fix locking and memory leak in br_add_bridge
From: Stephen Hemminger @ 2006-05-27 16:45 UTC (permalink / raw)
To: David Miller; +Cc: jbenc, netdev
In-Reply-To: <20060526.192611.109883073.davem@davemloft.net>
There are several bugs in error handling in br_add_bridge:
- when dev_alloc_name fails, allocated net_device is not freed
- unregister_netdev is called when rtnl lock is held
- free_netdev is called before netdev_run_todo has a chance to be run after
unregistering net_device
Signed-off-by: Jiri Benc <jbenc@suse.cz>
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- br.orig/net/bridge/br_if.c
+++ br/net/bridge/br_if.c
@@ -300,25 +300,20 @@ int br_add_bridge(const char *name)
rtnl_lock();
if (strchr(dev->name, '%')) {
ret = dev_alloc_name(dev, dev->name);
- if (ret < 0)
- goto err1;
+ if (ret < 0) {
+ free_netdev(dev);
+ goto out;
+ }
}
ret = register_netdevice(dev);
if (ret)
- goto err2;
+ goto out;
ret = br_sysfs_addbr(dev);
if (ret)
- goto err3;
- rtnl_unlock();
- return 0;
-
- err3:
- unregister_netdev(dev);
- err2:
- free_netdev(dev);
- err1:
+ unregister_netdevice(dev);
+ out:
rtnl_unlock();
return ret;
}
^ permalink raw reply
* Re: Refactor Netlink connector?
From: James Morris @ 2006-05-27 16:45 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev, David S. Miller, tgraf
In-Reply-To: <20060527134629.GA16306@2ka.mipt.ru>
On Sat, 27 May 2006, Evgeniy Polyakov wrote:
> > connector (the w1 driver) to use generic Netlink?
>
> Process accounting, CIFS and OFS netfilter module use it too.
w1 is the only in-tree thing I can see using any of the exported connector
symbols. I can see that cifs has included a connector header but not how
it's using the API.
> As long as quite a lot of out of the tree projects.
Out of tree code does not count.
>
> > I suspect that some of the nfnetlink infrastructure can be used more
> > generically, and that a simple API for the common case of kernel->user
> > event notifications could be also be provided.
> >
> > Thoughts?
>
> I would like to ask, how LSM labeling supposed to work with encapsulated
> netlink traffic.
This is the problem I'm trying to solve in the general case.
Have a look at security/selinux/nlmsgtab.c, which includes lookups table
for Netlink messages vs. permissions.
Currently this only covers plain netlink families, and should eventually
work ok for encapsulated protocols as long as we know about them and can
identify them (e.g. the genl->family field).
A further possibility is allowing netfilter protocols to register their
own permission tables.
One of the problems is that different Netlink protocols bury their
commands at different levels, so the SELinux code has to know how how deep
to dig (and then do the digging) to determine exactly which command is
being called.
e.g. TIPC only registers one genl_ops and embeds all commands inside
TIPC_GENL_CMD, while unencapsulated netlink protocols use the nlmsg_type
field of the actual netlink header.
It's inconsistent.
Actually, if people are going to use genl this way, perhaps we can get rid
of dynamic genl_ops registration. Alternatively, require that modules use
a different genl_ops for each type of command (not possible now for TIPC
as it's already in-tree).
> Will SELinux (for example) have some rules to allow w1 packets and block
> other for the same socket type?
Yes, once userspace policy is updated to include support for the w1
netlink socket, otherwise it will fall through to generic netlink perms.
> And what happens when the same socket start to send packets with
> different strucutre or some new protocol will be added?
> Should it consult with SELinux so it updated it's security processing code?
This is where allowing protocols to register their own message perms would
make things work automatically: add a new message type and then signify
whether it's read, write or readpriv.
> Or LSM supposed to work only on top of socket numbers (which could be
> the best) and just control "raw" netlink messages?
It can work at that level, too, by falling back to generic netlink perms.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH] eth1394: endian fixes
From: Stephen Hemminger @ 2006-05-27 16:40 UTC (permalink / raw)
To: Stefan Richter; +Cc: Alexey Dobriyan, netdev, linux1394-devel
In-Reply-To: <44782474.9050304@s5r6.in-berlin.de>
On Sat, 27 May 2006 12:05:40 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Alexey Dobriyan wrote on 2006-05-16:
> > Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ...
> > @@ -935,7 +935,7 @@ static inline u16 ether1394_parse_encap(
> > *(u32*)arp_ptr = arp1394->sip; /* move sender IP addr */
> > arp_ptr += arp->ar_pln; /* skip over sender IP addr */
> >
> > - if (arp->ar_op == 1)
> > + if (arp->ar_op == htons(1))
> > /* just set ARP req target unique ID to 0 */
> > *((u64*)arp_ptr) = 0;
> > else
>
> I suggest __constant_htons(ARPOP_REQUEST).
No. That is only for initializers and switch cases. Otherwise, it
adds unnecessary verbosity. The htons() does the right thing automatically.
>
> > @@ -1395,7 +1395,7 @@ static inline void ether1394_arp_to_1394
> > /* We need to encapsulate the standard header with our own. We use the
> > * ethernet header's proto for our own. */
> > static inline unsigned int ether1394_encapsulate_prep(unsigned int max_payload,
> > - int proto,
> > + __be16 proto,
> > union eth1394_hdr *hdr,
> > u16 dg_size, u16 dgl)
> > {
> > @@ -1626,7 +1626,7 @@ static int ether1394_tx (struct sk_buff
> > gfp_t kmflags = in_interrupt() ? GFP_ATOMIC : GFP_KERNEL;
> > struct eth1394hdr *eth;
> > struct eth1394_priv *priv = netdev_priv(dev);
> > - int proto;
> > + __be16 proto;
> > unsigned long flags;
> > nodeid_t dest_node;
> > eth1394_tx_type tx_type;
>
> Alexey, I am afraid none of the current 1394 developers is actively
> using eth1394. Did you have the chance to test your patch on different
> platforms and with different peer OSs/platforms?
>
> Also, did someone of the netdev guys already forward the patch (since we
> 1394 people are slow and eth1394 is marked unmaintained)? If not, I
> could send it along with a few other 1394 patches to akpm soon.
> --
> Stefan Richter
> -=====-=-==- -=-= ==-==
> http://arcgraph.de/sr/
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: CRC16 in rt2x00
From: Sergey Vlasov @ 2006-05-27 16:30 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: netdev
In-Reply-To: <200605271624.11062.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]
On Sat, May 27, 2006 at 04:24:07PM +0200, Ivo van Doorn wrote:
> On Saturday 27 May 2006 15:55, Sergey Vlasov wrote:
[skip]
> > However, fs/udf/crc.c has exactly the same CRC table as rt2x00:
[skip]
> > This is a bit-reversed form of CRC-CCITT supported by lib/crc-ccitt.c.
> > Unfortunately, this does not help much, because converting one form to
> > the other is too expensive (you would need to reverse bits in all data
> > bytes, and then reverse bits in the 16-bit result).
> >
> > BTW, there is more CRC code duplication in drivers/bluetooth/hci_bcsp.c
> > (bcsp_crc_update() seems to give the same result as crc_ccitt_byte()).
> >
> > In drivers/media/dvb/frontends/nxt200x.c, nxt200x_crc() seems to give
> > the same result as rt2x00crc_byte() (but without using a table).
> >
> > drivers/net/wan/cycx_drv.c:checksum() is also some mutated version of
> > CRC-CCITT (adding two additional zero bytes at the end of data makes it
> > return the same result as rt2x00crc()).
More stealth CRC implementations:
- drivers/ieee1394/csr.c:csr_crc16() - the same as rt2x00crc();
- drivers/ieee1394/csr1212.c:csr1212_crc16() - again the same as
rt2x00crc(), except the final byteswap;
- drivers/net/wireless/wavelan.c:psa_crc() is plain crc16(); it is
duplicated in drivers/net/wireless/wavelan_cs.c;
- drivers/scsi/FlashPoint.c:FPT_CalcCrc16() is also crc16();
> Interesting, so it would actually be usefull to move the nxt200x
> crc16 implemetation into the crc16 library (Is not using a table
> preferred over using a table?)
Using a table is probably faster, but consumes more memory.
> And make rt2x00 and fs/udf/crc.c make use of this library?
>
> And perhaps hci_bcsp could be updated to use crc_ccitt_byte() instead?
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] eth1394: endian fixes
From: Alexey Dobriyan @ 2006-05-27 16:12 UTC (permalink / raw)
To: Stefan Richter; +Cc: netdev, linux1394-devel
In-Reply-To: <44782474.9050304@s5r6.in-berlin.de>
On Sat, May 27, 2006 at 12:05:40PM +0200, Stefan Richter wrote:
> Alexey Dobriyan wrote on 2006-05-16:
> >Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ...
> >@@ -935,7 +935,7 @@ static inline u16 ether1394_parse_encap(
> > *(u32*)arp_ptr = arp1394->sip; /* move sender IP addr */
> > arp_ptr += arp->ar_pln; /* skip over sender IP addr
> > */
> >
> >- if (arp->ar_op == 1)
> >+ if (arp->ar_op == htons(1))
> > /* just set ARP req target unique ID to 0 */
> > *((u64*)arp_ptr) = 0;
> > else
>
> I suggest __constant_htons(ARPOP_REQUEST).
OK. htons(ARPOP_REQUEST) should be enough. __constant_* really needed in
initializators. Updated patch below.
> Alexey, I am afraid none of the current 1394 developers is actively
> using eth1394. Did you have the chance to test your patch on different
> platforms and with different peer OSs/platforms?
Unfortunately not.
> Also, did someone of the netdev guys already forward the patch (since we
> 1394 people are slow and eth1394 is marked unmaintained)? If not, I
> could send it along with a few other 1394 patches to akpm soon.
[PATCH] eth1394: endian fixes
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/ieee1394/eth1394.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/ieee1394/eth1394.c
+++ 1/drivers/ieee1394/eth1394.c
@@ -935,7 +935,7 @@ static inline u16 ether1394_parse_encap(
*(u32*)arp_ptr = arp1394->sip; /* move sender IP addr */
arp_ptr += arp->ar_pln; /* skip over sender IP addr */
- if (arp->ar_op == 1)
+ if (arp->ar_op == htons(ARPOP_REQUEST))
/* just set ARP req target unique ID to 0 */
*((u64*)arp_ptr) = 0;
else
@@ -1395,7 +1395,7 @@ static inline void ether1394_arp_to_1394
/* We need to encapsulate the standard header with our own. We use the
* ethernet header's proto for our own. */
static inline unsigned int ether1394_encapsulate_prep(unsigned int max_payload,
- int proto,
+ __be16 proto,
union eth1394_hdr *hdr,
u16 dg_size, u16 dgl)
{
@@ -1626,7 +1626,7 @@ static int ether1394_tx (struct sk_buff
gfp_t kmflags = in_interrupt() ? GFP_ATOMIC : GFP_KERNEL;
struct eth1394hdr *eth;
struct eth1394_priv *priv = netdev_priv(dev);
- int proto;
+ __be16 proto;
unsigned long flags;
nodeid_t dest_node;
eth1394_tx_type tx_type;
^ permalink raw reply
* Re: CRC16 in rt2x00
From: Ivo van Doorn @ 2006-05-27 14:24 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: netdev
In-Reply-To: <20060527175516.600f450c.vsu@altlinux.ru>
[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]
On Saturday 27 May 2006 15:55, Sergey Vlasov wrote:
> On Sat, 27 May 2006 13:27:15 +0200 Ivo van Doorn wrote:
>
> > I have a small question about the CRC16 usage in rt2x00
> > and what the netdev preferred method is for this.
> >
> > At the moment the rt2x00 drivers in wireless-dev use
> > its own CRC16 table and calculation inside the driver.
> > There already is a CRC16 library in the kernel
> > which uses the 0x8005 table, while rt2x00 uses the
> > 0x1021 polynomial table.
> >
> > Is keeping this version of CRC16 inside rt2x00 the most
> > sensible thing to do? Or should it be moved to the lib
> > folder of the kernel so other drivers could make use of it as well?
> > (So far I have not found a driver which makes use
> > of the same CRC16 table)
>
> However, fs/udf/crc.c has exactly the same CRC table as rt2x00:
>
> static uint16_t crc_table[256] = {
> 0x0000U, 0x1021U, 0x2042U, 0x3063U, 0x4084U, 0x50a5U, 0x60c6U, 0x70e7U,
> ...
> 0x6e17U, 0x7e36U, 0x4e55U, 0x5e74U, 0x2e93U, 0x3eb2U, 0x0ed1U, 0x1ef0U
> };
>
> /*
> * udf_crc
> *
> * PURPOSE
> * Calculate a 16-bit CRC checksum using ITU-T V.41 polynomial.
> *
> * DESCRIPTION
> * The OSTA-UDF(tm) 1.50 standard states that using CRCs is mandatory.
> * The polynomial used is: x^16 + x^12 + x^15 + 1
> *
> * PRE-CONDITIONS
> * data Pointer to the data block.
> * size Size of the data block.
> *
> * POST-CONDITIONS
> * <return> CRC of the data block.
> *
> * HISTORY
> * July 21, 1997 - Andrew E. Mileski
> * Adapted from OSTA-UDF(tm) 1.50 standard.
> */
>
> This is a bit-reversed form of CRC-CCITT supported by lib/crc-ccitt.c.
> Unfortunately, this does not help much, because converting one form to
> the other is too expensive (you would need to reverse bits in all data
> bytes, and then reverse bits in the 16-bit result).
>
> BTW, there is more CRC code duplication in drivers/bluetooth/hci_bcsp.c
> (bcsp_crc_update() seems to give the same result as crc_ccitt_byte()).
>
> In drivers/media/dvb/frontends/nxt200x.c, nxt200x_crc() seems to give
> the same result as rt2x00crc_byte() (but without using a table).
>
> drivers/net/wan/cycx_drv.c:checksum() is also some mutated version of
> CRC-CCITT (adding two additional zero bytes at the end of data makes it
> return the same result as rt2x00crc()).
Interesting, so it would actually be usefull to move the nxt200x crc16 implemetation
into the crc16 library (Is not using a table preferred over using a table?)
And make rt2x00 and fs/udf/crc.c make use of this library?
And perhaps hci_bcsp could be updated to use crc_ccitt_byte() instead?
Regards,
ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [2/4] [IPSEC] xfrm: Abstract out encapsulation modes
From: Diego Beltrami @ 2006-05-27 14:20 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev
In-Reply-To: <20060527113425.GB4737@gondor.apana.org.au>
Quoting Herbert Xu <herbert@gondor.apana.org.au>:
> [IPSEC] xfrm: Abstract out encapsulation modes
>
> This patch adds the structure xfrm_mode. It is meant to represent
> the operations carried out by transport/tunnel modes.
>
> By doing this we allow additional encapsulation modes to be added
> without clogging up the xfrm_input/xfrm_output paths.
>
> Candidate modes include 4-to-6 tunnel mode, 6-to-4 tunnel mode, and
> BEET modes.
Herbert,
this is a very good patch, indeed!
Well done!
--
Diego
^ permalink raw reply
* Re: CRC16 in rt2x00
From: Sergey Vlasov @ 2006-05-27 13:55 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: netdev
In-Reply-To: <200605271327.18879.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2298 bytes --]
On Sat, 27 May 2006 13:27:15 +0200 Ivo van Doorn wrote:
> I have a small question about the CRC16 usage in rt2x00
> and what the netdev preferred method is for this.
>
> At the moment the rt2x00 drivers in wireless-dev use
> its own CRC16 table and calculation inside the driver.
> There already is a CRC16 library in the kernel
> which uses the 0x8005 table, while rt2x00 uses the
> 0x1021 polynomial table.
>
> Is keeping this version of CRC16 inside rt2x00 the most
> sensible thing to do? Or should it be moved to the lib
> folder of the kernel so other drivers could make use of it as well?
> (So far I have not found a driver which makes use
> of the same CRC16 table)
However, fs/udf/crc.c has exactly the same CRC table as rt2x00:
static uint16_t crc_table[256] = {
0x0000U, 0x1021U, 0x2042U, 0x3063U, 0x4084U, 0x50a5U, 0x60c6U, 0x70e7U,
...
0x6e17U, 0x7e36U, 0x4e55U, 0x5e74U, 0x2e93U, 0x3eb2U, 0x0ed1U, 0x1ef0U
};
/*
* udf_crc
*
* PURPOSE
* Calculate a 16-bit CRC checksum using ITU-T V.41 polynomial.
*
* DESCRIPTION
* The OSTA-UDF(tm) 1.50 standard states that using CRCs is mandatory.
* The polynomial used is: x^16 + x^12 + x^15 + 1
*
* PRE-CONDITIONS
* data Pointer to the data block.
* size Size of the data block.
*
* POST-CONDITIONS
* <return> CRC of the data block.
*
* HISTORY
* July 21, 1997 - Andrew E. Mileski
* Adapted from OSTA-UDF(tm) 1.50 standard.
*/
This is a bit-reversed form of CRC-CCITT supported by lib/crc-ccitt.c.
Unfortunately, this does not help much, because converting one form to
the other is too expensive (you would need to reverse bits in all data
bytes, and then reverse bits in the 16-bit result).
BTW, there is more CRC code duplication in drivers/bluetooth/hci_bcsp.c
(bcsp_crc_update() seems to give the same result as crc_ccitt_byte()).
In drivers/media/dvb/frontends/nxt200x.c, nxt200x_crc() seems to give
the same result as rt2x00crc_byte() (but without using a table).
drivers/net/wan/cycx_drv.c:checksum() is also some mutated version of
CRC-CCITT (adding two additional zero bytes at the end of data makes it
return the same result as rt2x00crc()).
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox