In/Out Packet Errors: mini-howto for find and fix issues.. my experience and advices.

  • Well (or maybe I found new bug, or cosmetic errors? lol)

    Prologue: About few days ago, I noticed some in/out errors just counting up under "Interface Statistic" (/status_interfaces.php)
    related to on-board mini pci-e card Compex WLE200NX , installed on older APU PcEngines box at home of my customer.

    Well this happen after new re-installation of pfsense because this box was corrupted (kernel fail) by long sequence of power loss, ups failure and so on, (Hurricane happen on my country and strike down all electrical high voltage lines between trees, also all trees is strike it down, no more woods here, but this is another off-topic story and I'm very sad for this)

    So, better return on topic. I just loaded new 2.4.4 release and restored old configuration, trough "installer config-xml recovery stuff", also works fine this time, I'm lucky man phew! :D This is easy job. We know.

    After I see around the web for a possible solution, (we know AR9280 Free BSD driver is not fully perfect and suffer few issue like "stuck beacon") , and well. my first match is to do some "System/Advanced/System Tunables" (/system_advanced_sysctl.php)
    with the hope to "fixup" packet errors, but at the ends not any tunable fixes can stopping the "errors out" counter from increasing.

    Some description of my current setup below:
    Tunable Name Description Value
    hw.ath.longcal AR9280 tuning 30
    hw.ath.shortcal AR9280 tuning 100
    hw.ath.resetcal AR9280 tuning 1200
    hw.ath.anical AR9280 tuning 100
    hw.ath.rxbuf AR9280 tuning 600
    hw.ath.txbuf AR9280 tuning 600
    hw.ath.txbuf_mgmt AR9280 tuning 16
    hw.ath.bstuck AR9280 tuning 16
    dev.ath.0.hal.force_full_reset AR9280 tuning 1

    And this looks great in APU anyway looks stable enough for not printing any "beacon stuck" errors, under Wireless log file ( at this time I write. (I guess because no client connected and generate traffic)
    Also I played around , ssh it , when under shell, with sysctl. I see all "hw.ath" and "dev.ath.0" variables , and I activate some "stuff" on the fly, by set proper numeric value, well setting like:
    dev.ath.0.tpc: 1
    dev.ath.0.tpscale: 1
    dev.ath.0.hal.debug: 1
    and swapping defaults dev.ath.0.rxantenna and dev.ath.0.txantenna from 0:1 to 1:0 .
    (If you have atleast two physical antennas connected, value "2" if set, can allow rx or tx enabled to all two, this is well know stuff.)

    Also I notice when look at all variables of the ath bsd driver from sysctl query command : # sysctl dev.ath
    a LOT of data, some interesting related to beacon control, for example:
    dev.ath.0.hangcheck: 0 (I like to want understand what is its)
    dev.ath.0.forcebstuck: 0 (what work this?)

    So now I guess ath driver user manual explain all? "var's" effect and/or task, hopefully I trust ;) but I'm too lazy for check official documentation for "find" an answer lol. I'm not a lucky man ๐Ÿฆ†

    Anyway I will explain a little method for "debugging" any kind of in/out packet error with wireless interfaces, may also be applicable on ethernet interfaces too.

    First thing I set my Media type to autoselect mode 11g <hostap> because I know FreeBSD wireless not like much other standards... or maybe under 11.1 and greater release, ath driver is improved?
    (I too lazy for check changelog of course)
    |-Of coure packet out errors still alive..grr. >-<-|
    So for investigate the in/out errors the simply way I'm try is to check "Packet Capture" feature!
    This is enough for good start.
    Menu "Diagnostics/Packet Capture" ( /diag_packet_capture.php)
    Notice: I run this test with no client connected at all except for one range extender configured as "Universal repeater" for this wireless network. (Yes also we known... for WDS bridging support, this is not available trough web interface unfortunately even if driver ath capability reports for supporting for my hardware AR9280 (check with ifconfig ath0_wlan0 show)

    Well basically you can select you right "OPT" wireless interface from drop down menu, and FULL "Level of debug" and starting packet capturing , leaving all defaults for others options. After a while you can stopping it and pfsense web gui will print out the result.

    In my case, I get high amount of OUT packet errors and pfsense grab packet like this example below:

    00:28:39.534576 04:f0:21:1e:59:1a > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 447: (tos 0x0, ttl 2, id 42965, offset 0, flags [none], proto UDP (17), length 433) > [udp sum ok] UDP, length 405

    and many others messages same as above, and others like this:

    00:42:24.598850 04:f0:21:1e:59:1a > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 125: (tos 0x0, ttl 255, id 51001, offset 0, flags [none], proto UDP (17), length 111) > [udp sum ok] 0 [3q] PTR (QM)? _companion-link._tcp.local. PTR (QM)? _sleep-proxy._udp.local. PTR (QM)? _homekit._tcp.local. (83)

    ๐ŸฆŒ Whoa! ๐Ÿ•

    This seem'looks like broadcast O_0
    -- Upnp SSDP discovery?! (from UDP port:1900) and
    -- mDNS Avahi service?! (from UDP port:5353)

    When I got this info's next step is go to check my Upnp and Avahi service tab.
    (already installed before on pfsense APU)
    So, under Interfaces of both, I set or better , I UN set my OPT wireless interface from list. After save and restarting services,with my great surprise , all OUT packet errors is GONE! ๐ŸŽฏ โญ

    Very cool for me this discovery ;)

    For now I understand some bad relations with Upnp / Avahi service running on pfsense AND wireless selected interface, result:
    ๐Ÿ› Pull out "bad"? packets and the system mark this like "errors out"? ๐Ÿ›
    Well I guess a bug? ๐Ÿ› I dont'know.
    My hope is keeping this topic for tracking any kind of related issue with wireless in/out packet errors and possible solutions/fix/digging out/workaround.
    Feel free to write your own experiments same I do on this thread!
    Thanks for reading, sorry for my weak English and greetings from Dolomiti.

Log in to reply