1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Entware libpcap bug -- Entware users should read

Discussion in 'Tomato Firmware' started by koitsu, May 21, 2013.

  1. koitsu

    koitsu Network Guru Member

    ...may want to avoid doing opkg update && opkg upgrade. (For the TL;DR version see last line)

    I've found what appears to be a pretty major bug (for Tomato users anyway, given our kernel age and all that) in libpcap 1.3.0:

    Code:
    root@gw:/tmp/home/root# tcpdump -i vlan2 "tcp and port 80"
    tcpdump: vlan2: SIOETHTOOL(ETHTOOL_GTSO) ioctl failed: Invalid argument
    Details are in the below Entware ticket. Please start at comment #3 (the previous comments are about the fact that someone rebuilt tcpdump to link to libpcap 1.3.0 but didn't increase the tcpdump package number, which is irrelevant to the issue I'm talking about here):

    http://code.google.com/p/wl500g-repo/issues/detail?id=180

    The bug appears to be a regression/broken logic decision in libpcap 1.3.0, which has since been fixed in 1.4.0 (which is not available on Entware yet). Previous versions of libpcap do not have this problem.

    I am absolutely certain ryzhov_al will look at it and fix it/work with me on getting it fixed.

    TL;DR -- if you run Entware and have software that uses libpcap (opkg list-installed | grep libpcap, and if there's results, opkg whatdepends libpcap to get a list of Entware programs installed which would be impacted), you may want to avoid upgrading your Entware tools until this can get worked out. If you already are using libpcap 1.3.0 and things using it are working fine for you, then great (that just means the programs you're using aren't trying to make use of the libpcap API that issues the ETHTOOL_GTSO ioctl).

    P.S. -- I'm still on hiatus, but this was major enough that I wanted to make a post and let folks know.
     
    philess likes this.
  2. lancethepants

    lancethepants Network Guru Member

    I was wondering why that wasn't working for vlan2. Thanks for the information.
    I've compiled a static binary (with ipv6 support) from the latest sources and placed it on my website for anyone needing an alternative for the time.
    http://lancethepants.com/files
     
    philess likes this.
  3. ryzhov_al

    ryzhov_al Networkin' Nut Member

    Thank you for a bug report.
    As I said earlier, this is a kernel API malfunction in et driver. Better to fix it.

    Toastman? Shibby?
     
  4. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    Fix it in branch KDB-RT-N-et (based on Toastman) - will merge into KDB-RT-N after your approval.
     
  5. jerrm

    jerrm Network Guru Member

    Agree in principle, but even if fixed in the Tomato source, there could be a lot of folks impacted and surprised. Some maybe with reasons they can't upgrade to the latest Tomato. Is this a Tomato specific issue, or are there other K24/K26 platforms that will be impacted, perhaps with less responsive devs?

    If a fix is already in the libpcap 1.4 and won't require custom patches, it's probably worthwhile to go ahead and "accelerate" adoption of 1.4.
     
  6. ryzhov_al

    ryzhov_al Networkin' Nut Member

    Sure, jerrm. I'm not saying I will not gonna fix that, I'm pointing to the source of problem. Better to fix that both in Entware and Tomato's kernel, isn't it?
     
  7. jerrm

    jerrm Network Guru Member

    Without a doubt. Didn't mean to imply otherwise.
     
  8. RMerlin

    RMerlin Network Guru Member

    Personally, my fear is that if this gets fixed at the driver level, other software that were working around that bug might suddenly break (such as older versions of libcap, for example).
     
  9. koitsu

    koitsu Network Guru Member

    FWIW, my concern is the same as RMerlin's. I would rather start by testing a libpcap 1.4.0 package + tcpdump linked to libpcap 1.4.0 and see if that works.

    Otherwise I would need to somehow get a list of all the programs which call et_eththool() and examine their behaviour. There may be some that depend on -EINVAL being returned rather than -EOPNOTSUP.

    Also, ryzhov_al: the commit message says "brcm sdk: et: Driver must return -EOPNOTSUPP for unsupported ethtool commands" -- does this comment mean the bugfix comes officially from the Broadcom SDK? If so, then yes I agree we should fix this in the kernel. If there are userland applications which expect et_ethtool() returning -EINVAL then those will need to be rebuilt (and I can take the heat for that + make sure updated binaries are made available if needed, as long as source code is available for them).
     
  10. ryzhov_al

    ryzhov_al Networkin' Nut Member

    I've made a workaround for buggy brcm kernel, tcpdump is working again.

    libpcap is still 1.3.0, too many packages depends on it:
    Code:
    # grep ^Depends /opt/var/opkg-lists/openwrt | grep libpcap | wc -l
    25
    libpcap will be updated after it happens in upsteam — the OpenWRT trunk.

    Regards, Alexander Ryzhov.
     
    Monk E. Boy likes this.
  11. koitsu

    koitsu Network Guru Member

    I can confirm your workaround (in package libpcap 1.3.0-1a) works. That'll suffice for the time being.

    Большое спасибо!
     

Share This Page