Latest working kernel version:unknown Earliest failing kernel version:2.6.24 (Ubuntu 2.6.24-22-generic) Distribution:Ubuntu 8.04.1 Hardware Environment:PC104-based Via Centaur Ezra Software Environment:Ubuntu 8.04.1 Problem Description:serial.ko used by Sprint Sierra Wireless Compass 597 USB EVDO modem works properly except when running nsupdate, where it causes a TSIG error - BADKEY Steps to reproduce: 1. Use the aforementioned modem via ppp for Internet access. Observe normal user activities using http, https, DNS, and ssh work properly. 2. Configure nsupdate for TSIG secured dynamic DNS updates to a bind 9.x server using a HMAC-MD5 128 bit symmetric key. 3. Run nsupdate using the above key and watch as TSIG fails with a BADKEY error. 4. Connect same machine using either Ethernet or Verizon-based EVDO USB modem that still uses usbserial.ko instead of sierra.ko. Run nsupdate exactly as before and observe successful TSIG transaction. 5. Conclude that either
Created attachment 19127 [details] dmesg from affected machine
Created attachment 19128 [details] output of lspci -vnvn
Created attachment 19129 [details] uname -a from affected machine
Created attachment 19130 [details] lsusb -vvv from affected machine
I suspect that either there is a problem with the Sprint network itself or there is a problem in the sierra.ko module, as all other relevant factors remain the same - same nsupdate, same ppp daemon and similar configuration between the Sprint and Verizon connections (minor differences due to dialer differences between the two EVDO services). All other network traffic appears normal and fully functional. This bug report itself was filed through the Sierra Wireless connection.
http://www.sierrawireless.com/resources/support/Software/Linux/v1.3.1b_Kernel2.6.24.zip is the location of the more recent version of this driver. How do we get this code mainlined?
(In reply to comment #6) > > http://www.sierrawireless.com/resources/support/Software/Linux/v1.3.1b_Kernel2.6.24.zip > is the location of the more recent version of this driver. How do we get > this > code mainlined? That version is already in the mainline kernel, why do you think it isn't?
Can you try the 2.6.27 kernel release? It had a number of fixes in it for the sierra driver, and the 2.6.24 kernel is no longer supported by the community (rightfully so, it's quite old.)
"modinfo sierra" returns 1.2.5b, not the 1.3.1b that is currently available from Sierra. That's what led me to believe that the Sierra code wasn't necessarily mainlined. I understand now that it is, but for the 2.6.24 kernel that's provided for Ubuntu 8.04.1 Long Term Support, the older code is what was included. It seems that Sierra has backported the newer version and has made it available for older kernels. I can try the Ubuntu 8.10 kernel, which is 2.6.27-based. I'll test this and report back.
For ubuntu specific issues like their LTS kernels, please contact them, there is nothing that we can do about that here.
It seems that this closure was a bit premature. I just tested against 2.6.27 that has the 1.3.2 sierra code and have the same error.
I'm still not quite sure what the "error" is. Is it just the fact that the connection is dropped at times? Or something else?
I apologize for this erroneous bug report. Simple troubleshooting has led me to the wrong conclusion. It seems that Sprint transparently proxies all DNS requests (TCP and UDP port 53) to its own servers, regardless of any settings on the client computer. As nsupdate communicates over TCP or UDP to port 53 of the dynamic DNS server, it gets in the middle of an TSIG-encrypted DNS transaction, and subsequently fails. The insidious thing of it all is that Sprint spoofs the source address of the dynamic DNS server I've been trying to update. tcpdump at the DNS server confirms that the packets never reach it.