#26 TI acx100 chip based products and DUP! packets

closed-out-of-date
nobody
None
1
2005-02-25
2003-11-21
Dean Stoeff
No

From one side(A) on 10km Link is GL2422VP with 24dB HI-gian
antena on another side(B) is TEW310APBX with same antena

SIDE A:

wlan0 v0.2.0pre3 ESSID:"ESSID3"
Mode:Managed Channel:5 Access Point: 00:03:2F:0E:0D:B6
Bit Rate=5.5Mb/s Tx-Power:18 dBm
Encryption key:off
Link Quality:88/0 Signal level:-230 dBm Noise level:-244 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
root@galata1:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:50:FC:BA:43:2A
inet addr:10.0.3.2 Bcast:10.255.255.255 Mask:255.255.255.
255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:50059 errors:1546 dropped:0 overruns:0 frame:0
TX packets:8295 errors:8308 dropped:0 overruns:0 carrier:
8308
collisions:0 txqueuelen:100
RX bytes:47363537 (45.1 Mb) TX bytes:1630633 (1.5 Mb)
Interrupt:5 Base address:0xd000

lets piniging AP :-)
root@galata1:~# ping 10.0.3.248
PING 10.0.3.248 (10.0.3.248) 56(84) bytes of data.
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=19.2 ms
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=19.9 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=20.5 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=21.3 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=35.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=37.4 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=41.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=44.2 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=45.0 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=46.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=47.5 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=61.3 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=65.0 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=65.9 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=66.7 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=71.6 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=72.3 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=74.0 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=74.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=75.4 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=76.2 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=85.6 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=1 ttl=127 time=86.2 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=5.13 ms
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=12.2 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=13.0 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=14.4 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=15.3 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=19.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=20.6 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=25.1 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=40.4 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=41.1 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=45.6 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=46.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=49.7 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=50.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=51.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=55.3 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=60.1 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=64.0 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=64.7 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=65.4 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=2 ttl=127 time=66.7 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=2.22 ms
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=3.05 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=4.09 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=13.5 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=19.7 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=22.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=23.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=24.9 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=27.6 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=28.4 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=30.2 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=37.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=38.9 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=39.8 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=46.9 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=48.1 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=48.9 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=53.4 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=54.2 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=55.4 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=57.6 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=58.9 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=60.5 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=73.0 ms (DUP!)
64 bytes from 10.0.3.248: icmp_seq=3 ttl=127 time=75.8 ms (DUP!)

--- 10.0.3.248 ping statistics ---
3 packets transmitted, 3 received, +66 duplicates, 0% packet loss,
time 2024ms
rtt min/avg/max/mdev = 2.228/43.991/86.288/22.061 ms

Discussion

  • Andreas Mohr

    Andreas Mohr - 2003-12-15
    • priority: 5 --> 2
     
  • Andreas Mohr

    Andreas Mohr - 2003-12-15

    Logged In: YES
    user_id=132674

    Less important for now, so better adjust priority.

     
  • Dean Stoeff

    Dean Stoeff - 2003-12-16
    • priority: 2 --> 1
     
  • Hugo Mildenberger

    Logged In: YES
    user_id=991952

    This observation may be well related to multipath signal
    receiving conditions.

    I noted the same behavior, if my AP was not in line of
    sight with my notebook. I had even the impression, that
    such duped packet arrived more frequently, if my left hand
    was in close range with the antenna of my pcmcia card
    (which is mounted left), and reached a high rate, when my
    hand enclosed the antenna completely. Duped packets were
    corelated with low (<20) signal level values as shown by
    "iwconfig wlan0"

    Following the TI-supplied bulletin on acx100 and
    TNET1100W, the acx100 has a somewhat limited compensation
    for signals received on different path, which is specified
    to be greater than 250 nanoseconds for acx100 and greater
    than 500 nanoseconds in case of TNET1100W ( the low power
    version of acx100)

    As far as I understand this matter, greater does not mean
    better here: the chip can suppress duplicated received
    signals, if they are at minimum 250 or 500 nanoseconds
    apart from each other, respectively.

    At the given frequency of 2.4 GigaHz this timely
    difference translates (via s = c * delta t) to a minimum
    difference in spatial spreading path of about 75 or 150
    meters -- which in turn means, that the suppression of
    duplicates will not work very well under the conditions
    usually met at home, where I would expect the path
    difference to be below 30 meters.

    But ... Also my DWL-650+ pcmcia version has two antennas,
    which are printed on the board itself, with an horizontal
    angle of 90 between them. (The current version of this
    driver initialises antenna setting with a value of 0x8f,
    while the firmware default is 0x8b, whatever this means,
    may be influential.)

    Thinking about these construction details I wonder if the
    pcmcia version could detect multipath signals at all. To
    accomplish this task, one needs -- according to a golden
    radio engineering rule -- two antennas mounted in a
    distance of 3 .. 4 lambda away from each other, resulting
    in about 0.4 meters spatial distance in our case. My
    DI-614+ (revision B1) accesspoint mounts two antennas (one
    internal, one external) about 17 cm away from each other,
    which appears to be a suboptimal decision.

    Anyway, duped packets are not of great impact if any kind
    of reliant transmission protocols are used, which are
    inherently able to diregard such packets.

    hm

     
  • Andreas Mohr

    Andreas Mohr - 2004-03-07

    Logged In: YES
    user_id=132674

    Thanks for that very insightful comment!
    The current testing version already had the antenna value fix.
    Dupes might very well be due to reflection/multipath issues,
    but I'm afraid the 20th-fold dup display above is still a
    bit hard to explain, even when taking into account
    reflection. Or maybe it isn't (...and I simply don't have
    the insight to give a good explanation) ?

     
  • Nobody/Anonymous

    Logged In: NO

    That's what I thought immediately after I hit the submit
    button. To my knowledge, the 802.11 implements besides
    RTS/CTS also MAC-level retransmissions.

    Thus the problem may simply consist therein, that ACKs
    transmitted by the receiving sides MAC layer are not
    received by the partner station or accesspoint
    respectively, which is therefore retransmitting the same
    frame after a certain intervall.

    So the alternative explanation could be, that the machine
    issuing that ping command is equipped with a somewhat
    lossy tx-antenna? My observation, that I see dups when the
    rx signal drops below 20/100 would somehow complete this
    picture.

    The question is: who does handle MAC-level retransmits?
    The firmware? I think so. But does the firmware really
    recognize such situations? Perhaps the firmware has to be
    instructed in doing so.

    Anyway, the driver could filter these duplicate packets
    eventually.

    Are the frames received from firmware somehow numbered or
    flagged, so that the driver could detect the situation
    inspecting the frames more closely?

    Maybe WLAN_GET_SEQ_SEQNUM() from p80211hdr.h could make
    use of the .seq field? As far as I see it is used nowhere
    outside of authentication.

    Alas, a dump of the value of p80211_hdr->a3.seq within
    acx100_process_data_frame_client and ..._master showed a
    constant switch between only three values, while there
    were no ping - related dups.

    Regards

    hm

     
  • Hugo Mildenberger

    Logged In: YES
    user_id=991952

    In contrast to my previous comment, packet numbers and
    retry flag are well available at driver level. However,
    the retry flag is currently ignored.

    Therefore any retransmitted frame will be received
    several times, if the precedent copy was received
    correctly, but the packet ACK was for some reasons not
    seen by the sender.

    If the received packets represents a ping reply, we will
    see DUP! messages from ping output.

    Just until I realized that network load will increase the
    incidence of such duped packets, I faced difficulties to
    reproduce this error - running netio -t will reproduce it
    in a reliable way.

    Below is an excerpt of debug output. The two lines
    beginning with "cfoffset" prove my hypothesis.

    Filtering these packets would require a backlog of
    appropriate depth, say 10, but maybe one backlog for each
    transmitting bssid involved, since FCS should be different
    on retry and sequence numbers are unique (modulo 0x4096)
    only for each transmitting station.

    Regards

    hm

    IRQTYPE: 8, irq_mask: DBB5, entry count: 1
    ==> acx100_process_rx_desc
    ==> acx100_log_rxbuffer
    rxbuf 5 full
    <== acx100_log_rxbuffer
    acx100_process_rx_desc: using curr_idx 5, rx_tail is now
    6
    ==> acx100_get_packet_type_string
    <== acx100_get_packet_type_string: d112aaa0
    Rx pkt 05 (DATA/DataOnly): time 171503357, len 1096,
    signal 73, SNR 1, mode 2, status 4
    ==> acx100_rx_ieee802_11_frame
    hw->status=4(ASSOCIATED)
    ==> acx100_process_data_frame_client
    acx100_process_data_frame_client: UNVERIFIED.

    *** first transmission of packet with sequence no 1239

    cfoffset a4.seq: 22, seq.frag=1239.0 no retry
    no more frags no more data

    to_ds 0, from_ds 1
    da <4>00.0D.88.A2.6D.E6<4>,bssid
    <4>00.40.05.53.7A.C5<4>,hw->bssid
    <4>00.40.05.53.7A.C5<4>,dev_addr
    <4>00.0D.88.A2.6D.E6<4>,bcast_addr <4>FF.FF.FF.FF.FF.FF<4>
    ==> acx100_rx
    ==> acx100_rxdesc_to_ether
    It's a WEP packet, chopping off IV and ICV.
    payload_offset 28, payload_length 1060
    Frame info: llc.dsap AA, llc.ssap AA, llc.ctl 3, snap.oui
    000, snap.type 8
    802.1h/RFC1042 len: 1060
    <== acx100_rxdesc_to_ether
    <== acx100_rx
    <== acx100_process_data_frame_client: 00000001
    <== acx100_rx_ieee802_11_frame: 00000001
    <== acx100_process_rx_desc
    <== acx100_interrupt
    ==> acx100_interrupt
    IRQTYPE: 8, irq_mask: DBB5, entry count: 1
    ==> acx100_process_rx_desc
    ==> acx100_log_rxbuffer
    rxbuf 6 full
    <== acx100_log_rxbuffer
    acx100_process_rx_desc: using curr_idx 6, rx_tail is now
    7
    ==> acx100_get_packet_type_string
    <== acx100_get_packet_type_string: d112aaa0
    Rx pkt 06 (DATA/DataOnly): time 171504816, len 1096,
    signal 53, SNR 0, mode 2, status 4
    ==> acx100_rx_ieee802_11_frame
    hw->status=4(ASSOCIATED)
    ==> acx100_process_data_frame_client
    acx100_process_data_frame_client: UNVERIFIED.

    *** Second transmission (retry of packet with sequence no
    1239)

    cfoffset a4.seq: 22, seq.frag=1239.0 RETRY!
    no more frags no more data
    to_ds 0, from_ds 1
    da <4>00.0D.88.A2.6D.E6<4>,bssid
    <4>00.40.05.53.7A.C5<4>,hw->bssid
    <4>00.40.05.53.7A.C5<4>,dev_addr
    <4>00.0D.88.A2.6D.E6<4>,bcast_addr <4>FF.FF.FF.FF.FF.FF<4>
    ==> acx100_rx
    ==> acx100_rxdesc_to_ether
    It's a WEP packet, chopping off IV and ICV.
    payload_offset 28, payload_length 1060
    Frame info: llc.dsap AA, llc.ssap AA, llc.ctl 3, snap.oui
    000, snap.type 8
    802.1h/RFC1042 len: 1060
    <== acx100_rxdesc_to_ether
    <== acx100_rx
    <== acx100_process_data_frame_client: 00000001
    <==ta_frame_client: 00000001
    <== acx100_rx_ieee802_11_frame: 00000001
    <== acx100_process_rx_desc
    <== acx100_interrupt
    ==> acx100_interrupt

     
  • Christian Kirbach

    • status: open --> closed-out-of-date
     
  • Christian Kirbach

    Logged In: YES
    user_id=889123

    Closing due to no activity within the last 6 months.

    If you want to reopen the bug please make sure you have checked
    that the problem persists even with the latest driver.
    You can get the driver from http://lisas.de/~andi/acx100/

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks