No NET with 2.6.27: No buffer space available

[Luigi Maselli]

With kernel 2.6.27-x the network doesn't work anymore, last working kernel is 2.6.26-5

ubuntu@ubuntu:~$ sudo ifconfig eth0 192.168.1.10 netmask 255.255.255.0
SIOCSIFADDR: No buffer space available
SIOCSIFNETMASK: Cannot assign requested address

dmesg
Code:

[ 225.434919] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 225.435343] ATL1E 0000:02:00.0: ATL1E: eth0 NIC Link is Up<100 Mbps Full Duplex>
[ 225.435811] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 229.644016] usb 1-3: device descriptor read/64, error -110
[ 240.232015] usb 1-3: device descriptor read/64, error -110
[ 240.448013] usb 1-3: new high speed USB device using ehci_hcd and address 7
[ 246.736012] usb 1-3: device not accepting address 7, error -71
[ 246.848009] usb 1-3: new high speed USB device using ehci_hcd and address 8
[ 252.776011] usb 1-3: device not accepting address 8, error -71
[ 252.776028] hub 1-0:1.0: unable to enumerate USB device on port 3
[ 253.044010] usb 3-1: new full speed USB device using uhci_hcd and address 2
[ 265.163122] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 265.163259] ATL1E 0000:02:00.0: ATL1E: eth0 NIC Link is Up<100 Mbps Full Duplex>
[ 265.163363] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[cedric.b (bouchet-cedric)]

I have the same problem with my network card (product BCM4401, vendor Broadcom Corp.) since I install Intrepid version.
I have no access to internet, and I cannot get an IP address.
When I tried the command "sudo dhclient eth0" it's return "SIOCSIFADDR: No buffer space available and send_packet: Message too long"

[Markus Gonaus (magonaus)]

Same at my Hardware.
Neither RTL-8169 nor Atheros Wlan work while network-manager is running.
logs of my system attached.
http://ubuntuforums.org/showthread.php?t=963335&page=1 for lots of reports

[Markus Gonaus (magonaus)]

What I should add: This is a Network-manager problem. Not a kernel problem. As it is with every kernel from 2.6.22-14 to 2.6.27-7
and booting without Network-manager is a workaround for everyone who can manualy configure the network.
But shuting down Network-manager is not sufficient.

[Dustin Kirkland  (kirkland)]

I can confirm this issue too, but it's unique to the access point.

I have connected successfully to dozens of other access points, but I'm trying to connect to an SMC Barricade SMC7004AWBR. The wireless connection is established, and persists (802.11b, no encryption). But I cannot draw an ipaddress.

If I try to manually configure the ip address via `ifconfig ath0 192.168.2.50`, I get this error message:
SIOCSIFADDR: No buffer space available

One thing I noticed... This access point only supports 11mbps 802.11b. The iwconfig output, though, thinks it's connected to 802.11g. Could this be part of the problem?

ath0 IEEE 802.11g ESSID:"default" Nickname:""
          Mode:Managed Frequency:2.437 GHz Access Point: 00:11:22:33:44:55
          Bit Rate:11 Mb/s Tx-Power:8 dBm Sensitivity=1/1
          Retry:off RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=60/70 Signal level=-37 dBm Noise level=-97 dBm
          Rx invalid nwid:6168 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

ath0 Link encap:Ethernet HWaddr 00:55:44:33:22:11
          UP BROADCAST RUNNING MULTICAST MTU:64 Metric:1
          RX packets:51 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8215 (8.2 KB) TX bytes:2631 (2.6 KB)

:-Dustin

[IItiaII (r-mattia)]

Same problem with Intrepid and an ethernet controller by Broadcom (BCM5787M) trying to connect to a LAN.
Same solution, removing the Network Manager.
In Dustin's particular case the problem may be related with the 802.11b/g misunderstanding, but in general Ii seems to be a Network Manager problem and related to wired interfaces too..

[dcam (david-pastornet)]

I'm seeing similar with fully up-to-date Intrepid an a wired network (Davicom DM9601 controller), and it happens even when NetworkManager is completely shut down.

root@vostro:~# ifconfig eth1 192.168.2.2 netmask 255.255.255.0
SIOCSIFADDR: No buffer space available
SIOCSIFNETMASK: Cannot assign requested address

root@vostro:/big/Downloads# ifconfig eth1 192.168.2.2 netmask 255.255.255.0
SIOCSIFADDR: No buffer space available
SIOCSIFNETMASK: Cannot assign requested address

[dcam (david-pastornet)]

Could this issue be related to these kernel posts:

http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-06/msg02829.html

http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-06/msg02878.html

http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-06/msg03111.html

There's a patch provided there...wonder if the patch made it into the trunk?

[Martin Erik Werner (arand)]

Same issue.

Using latest jaunty daily livecd 9th march.

[Luigi Maselli (grigio)]

Hi, I tested Fedora with kernel 2.6.29 and this issue is fixed

[Martin Erik Werner (arand)]

When is a solution for this going to make it into ubuntu?

[TJ (tj)]

In reply to dcam, the patch in

http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-06/msg02958.html

from Björn Steinbrink to __inet_del_ifa() is included in Hardy, Intrepid and Jaunty.

commit 6363097cc4d182f93788131b5d8f72aa91d950a0
Author: Herbert Xu <email address hidden>
Date: Thu Jun 7 18:35:38 2007 -0700

[TJ (tj)]

Has anyone been able to test this on an IPv6 network so we could determine the scope of the cause to help hunting it down?

It does look like an IPv4 issue. Could you boot the kernel with "debug" mode, provoke the error, and then check the end of /var/log/kern.log for any relevant kernel errors (This will help to determine if the kernel is seeing the same thing as the userspace applications) ?

[TJ (tj)]

I'm going to maintain a stream-of-investigation commentary to help narrow down the area where myself or others can look for this issue.

Here's one place the Error No Buffer Space is being fired - the IOCTL handler:

net/ipv4/devinit.c::devinet_ioctl()

 case SIOCSIFADDR: /* Set interface address (and family) */
  ret = -EINVAL;
  if (inet_abc_len(sin->sin_addr.s_addr) < 0)
   break;

  if (!ifa) {
   ret = -ENOBUFS;
   if ((ifa = inet_alloc_ifa()) == NULL)
    break;

The call to inet_alloc_ifa() is simply this:

static struct in_ifaddr *inet_alloc_ifa(void)
{
 struct in_ifaddr *ifa = kzalloc(sizeof(*ifa), GFP_KERNEL);

 if (ifa) {
  INIT_RCU_HEAD(&ifa->rcu_head);
 }

 return ifa;
}
----------

I will look at the ipconfig tool to ensure the code-path is the one that calls this IOCTL.

Dustin's report suggests some linkage to the type/make of network device and type of connection so please report the precise device IDs that are exhibiting the issue using:

 lspci --vvnn -s $BUS:$SLOT.$FUNCTION

(determine the values of BUS SLOT FUNCTION first using lspci -nn)

For the sake of accuracy please also state if the device is wired or wireless, and if wireless, the precise type of connection it is trying to establish (802.11b, 802.11g, 802.11a, 802.11n, etc.).

Also report the actual standard(s) the Wireless access point is operating with, including the encryption method. (E.g. 802.11g WPA2 AES+TKIP).

[TJ (tj)]

Based on Dustin's report of manually using ifconfig (probably the simplest scenario that can cause -ENOBUFS), I've looked at the source-code for ifconfig in the net-tools package.

Would it be possible for one or more of you to single-step through a simple ifconfig scenario using gdb to pin-point which code-path is issuing the error?

There are only two instances of perror("SIOCSIFADDR") - one is in the IPv6 code-path which should only get triggered when a colon is found in the address string. This should get you started:

apt-get source net-tools
cd net-tools-1.60

# copy the build configuration files
cp debian/config.h config.h
cp debian/config.make config.make

# enable debug symbols, disable optimisations
sed -i '/^COPTS/ s/# -g/ -g #/' -e '/^COPTS/ s/-O2//' Makefile

# build
make ifconfig

# switch to root
sudo -s

# set IFACE here to the one having problems
IFACE=eth0

# debug
gdb --args ifconfig $IFACE 10.0.0.1

At this point the gdb command prompt appears, and gdb commands are active. Use "help" to learn more.

(gdb) break 997
Breakpoint 1 at 0x4047b4: file ifconfig.c, line 997.
(gdb) run
Starting program: /home/all/SourceCode/net-tools-1.60/ifconfig wlan0 10.254.251.51

Breakpoint 1, main (argc=2, argv=0x7fff13b3f1f0) at ifconfig.c:998
998 fd = get_socket_for_af(AF_INET);
(gdb) display r
1: r = 0
(gdb) next
999 if (fd < 0) {
1: r = 0
(gdb) next
1003 r = ioctl(fd, SIOCSIFADDR, &ifr);
1: r = 0
(gdb) next
1021 if (r < 0) {
1: r = 0
(gdb)

At this point, if "r" is less than 0 there has been an IOCTL error. The value of -ENOBUFS is -105 and comes from the kernel:

include/asm-generic/errno.h:78:#define ENOBUFS 105 /* No buffer space available */

Assuming it is this code-path the code-fragment is:

#if HAVE_AFINET
     case AF_INET:
  fd = get_socket_for_af(AF_INET);
  if (fd < 0) {
      fprintf(stderr, _("No support for INET on this system.\n"));
      exit(1);
  }
  r = ioctl(fd, SIOCSIFADDR, &ifr);
  break;

If it is, this will confirm my earlier report that the error comes from the kernel's IOCTL handler net/ipv4/devinit.c::devinet_ioctl()

Quit gdb with:

(gdb) quit

# back to shell and regular user log-in privileges
exit

[Martin Erik Werner (arand)]

Sorry, but I'm having some trouble following these steps, the sed command given is not working for me, using livecd:

ubuntu@ubuntu:~/Desktop/net-tools-1.60$ sed -i '/^COPTS/ s/# -g/ -g #/' -e '/^COPTS/ s/-O2//' /home/ubuntu/Desktop/net-tools-1.60/Makefile

sed: can't read /^COPTS/ s/# -g/ -g #/: No such file or directory

ubuntu@ubuntu:~/Desktop/net-tools-1.60$ sed -i '/^COPTS/ s/# -g/ -g #/' -e '/^COPTS/ s/-O2//' -f /home/ubuntu/Desktop/net-tools-1.60/Makefile

sed: file /home/ubuntu/Desktop/net-tools-1.60/Makefile line 76: extra characters after command

I have no experience using sed and is somewhat clueless here.

I have however, attached output from lspci

[Kow (kow)]

There is a problem with that sed command. -e needs a file not an expression.

Do the "# enable debug symbols, disable optimisations" as two parts:
a. sed -i '/^COPTS/ s/# -g/-g #/' Makefile
b. sed -i '/^COPTS/ s/ -O2//' Makefile

Make sure you copy and paste these commands. There is a space in s/ -O2// (an option is being removed hence a space needs to be removed also.)

[Martin Erik Werner (arand)]

Okay, I have gone through the debug procedure (correctly I hope, using Kow's sed commands), and the last bit indeed reads:

(gdb) next
1021 if (r < 0) {
1: r = -1
(gdb)

So this would confirm your suspicions TJ?

Attaching full debug procedure

[TJ (tj)]

On Thu, 2009-03-26 at 19:59 +0000, arand wrote:
> Sorry, but I'm having some trouble following these steps, the sed
> command given is not working for me, using livecd:

Sorry about that - there's a missing -e! When multiple expressions are
used each must be prefixed by -e (which can be optionally omitted when
there's only one expression). It should read:

sed -i -e '/^COPTS/ s/# -g/ -g #/' -e '/^COPTS/ s/-O2//' Makefile

> There is a problem with that sed command. -e needs a file not an
> expression.

No. -e expects an inline script. -f expects a script file.

[TJ (tj)]

On Thu, 2009-03-26 at 23:04 +0000, arand wrote:
> Okay, I have gone through the debug procedure (correctly I hope, using
> Kow's sed commands), and the last bit indeed reads:
>
> (gdb) next
> 1021 if (r < 0) {
> 1: r = -1
> (gdb)
>
> So this would confirm your suspicions TJ?

Thank-you. Yes, it does indeed. The issue stems from a failed attempt by
the kernel to allocate memory. I'll repeat what I outlined earlier for
clarity since the original has a typo that gives a non-existent
file-name:

net/ipv4/devinet.c::devinet_ioctl()

 case SIOCSIFADDR: /* Set interface address (and family) */
  ret = -EINVAL;
  if (inet_abc_len(sin->sin_addr.s_addr) < 0)
   break;

  if (!ifa) {
   ret = -ENOBUFS;
   if ((ifa = inet_alloc_ifa()) == NULL)
    break;

The call to inet_alloc_ifa() is simply this:

static struct in_ifaddr *inet_alloc_ifa(void)
{
 struct in_ifaddr *ifa = kzalloc(sizeof(*ifa), GFP_KERNEL);

 if (ifa) {
  INIT_RCU_HEAD(&ifa->rcu_head);
 }

 return ifa;
}

So on the face of it this is a failure of kzalloc() to allocate a block
of zero-ed memory for the in_ifaddr structure although I can't see how
that would fail.

arand:

What kernel version did you do the test on? If possible, could you do
the same test with the latest Jaunty kernel? I want to be sure I'm
looking at the correct source-code whilst trying to figure this out.

Does the system have plenty of free memory (I know, long shot, but best
to be sure!) ?

[TJ (tj)]

There appears to be a change to the 2.6.29 code that changes the way the
allocation is handled:

commit 93adcc80f3288f1827baf6f821af818f6eeef7f9
Author: Alexey Dobriyan <email address hidden>
Date: Tue Oct 28 13:25:09 2008 -0700

    net: don't use INIT_RCU_HEAD

    call_rcu() will unconditionally rewrite RCU head anyway.
    Applies to
        struct neigh_parms
        struct neigh_table
        struct net
        struct cipso_v4_doi
        struct in_ifaddr
        struct in_device
        rt->u.dst

    Signed-off-by: Alexey Dobriyan <email address hidden>
    Acked-by: Paul E. McKenney <email address hidden>
    Signed-off-by: David S. Miller <email address hidden>

It applies cleanly onto the Jaunty tree and with one slight adjustment,
to the Intrepid tree. If I don't find anything else that might cause
this we can try custom kernel builds including these changes.

[Martin Erik Werner (arand)]

For the debug I used kernel 2.6.28-11 (daily livecd march 25). And this I think is latest as of now.

This on a Dell XPS 1530 laptop with 4GB physical memory present, so I don't think there should be any trouble with that.

[TJ (tj)]

I stepped back a bit and re-considered. Realised I'd missed something
important.

The -ENOBUFS in devinit_ioctl() isn't the only place this error value
could be set.

If the allocation in devinet_ioctl() succeeds execution continues
through to:

  ret = inet_set_ifa(dev, ifa);
  break;

That calls:

net/ipv4/devinet.c::inet_set_ifa()
{
 struct in_device *in_dev = __in_dev_get_rtnl(dev);

 ASSERT_RTNL();

 if (!in_dev) {
  inet_free_ifa(ifa);
  return -ENOBUFS;
 }

-ENOBUFS will happen if __in_dev_get_rtnl(dev) fails.

include/linux/inetdevice.h::__in_dev_get_rtnl():

static __inline__ struct in_device *
__in_dev_get_rtnl(const struct net_device *dev)
{
 return (struct in_device*)dev->ip_ptr;
}

So if dev->ip_ptr is NULL the -ENOBUFS could be fired.

There aren't many places where this will be set. One of them is

net/ipv4/devinet.c::inetdev_init()

...
 /* Account for reference dev->ip_ptr (below) */
 in_dev_hold(in_dev);
...
 /* we can receive as soon as ip_ptr is set -- do this last */
 rcu_assign_pointer(dev->ip_ptr, in_dev);

which is only ever called from

net/ipv4/devinit.c::inetdev_event()

 if (!in_dev) {
  if (event == NETDEV_REGISTER) {
   in_dev = inetdev_init(dev);
...
  } else if (event == NETDEV_CHANGEMTU) {
   /* Re-enabling IP */
   if (inetdev_valid_mtu(dev->mtu))
    in_dev = inetdev_init(dev);

I'm wondering if this is an obscure RCU issue. Having read up on other
changes to similar code it could be that inet_set_ifa() should be:

static int inet_set_ifa(struct net_device *dev, struct in_ifaddr *ifa)
{
 struct in_device *in_dev;
 rcu_read_lock();
 in_dev = __in_dev_get_rcu(dev);

 ASSERT_RTNL();

[TJ (tj)]

arand:

Am I correct in guessing you're using a 64-bit -generic kernel?

I'm about to build some kernel packages for testing so I'll give the amd64 -generic package priority if so.

[Martin Erik Werner (arand)]

No, it's a 32 bit, (although it may be a bit of a waste).

[Martin Erik Werner (arand)]

By the way, will I need to install to HD to be able to apply kernel packages? Up 'till now I've only been using livecds... I'll gladly go through with installing and testing but would be happy if there was a way to test without having to start partitioning...?

[TJ (tj)]

he userOn Fri, 2009-03-27 at 16:21 +0000, arand wrote:
> By the way, will I need to install to HD to be able to apply kernel
> packages? Up 'till now I've only been using livecds... I'll gladly go
> through with installing and testing but would be happy if there was a
> way to test without having to start partitioning...?

I've been told by cjwatson that, provided the custom kernel doesn't
change the ABI (Application Binary Interface), it is okay to simply
replace the kernel images in the live-CD ISO images.

I use exploded live-CD images here for PXE/netboot testing anyway so
I'll build a 32-bit kernel and try it. If that works I'll make an ISO
available for you to download.

It would be easier if the system had Ubuntu installed (even if on USB
device) because you'd just need to replace the kernel image - about
3.5MB - as opposed to an entire CD (700MB).

[Martin Erik Werner (arand)]

Sorry if it's already been done but I sat down and installed on a usb drive (wasn't aware that it was that simple a procedure), so if it's more convenient I'll be able to test with just the custom kernel image.

[TJ (tj)]

The x86 32-bit package is now available from:

http://tjworld.net/ubuntu/bugs/lp284377/

Download the .deb packages and then install using:

sudo dpkg -i linux-image-2.6.28-11-generic_2.6.28-11.38lp284377v1_i386.deb
sudo dpkg -i linux-headers-2.6.28-11-generic_2.6.28-11.38lp284377v1_i386.deb

[Martin Erik Werner (arand)]

Hmm, it seems the modified kernel made no difference:

mw@Mell:~$ uname -a
Linux Mell 2.6.28-11-generic #38lp284377v1 SMP Fri Mar 27 17:22:00 GMT 2009 i686 GNU/Linux
mw@Mell:~$ sudo ifconfig eth0 10.0.0.1
SIOCSIFADDR: No buffer space available
mw@Mell:~$

[Martin Erik Werner (arand)]

I think we might be looking at the wrong place, unfortunately: I tried the suggestion by Markus Gonaus (3rd comment) to disable network-manager (uninstalling), and now I don't get the error at all, and after manual configuation the network is fine... (So I'm guessing this implies the error resides wholly in network-manager) Feel a bit stupid now.

[Martin Erik Werner (arand)]

Ok, it seems this might a duplicate of bug 291449, I've tested with Intrepid livecd and I get no net there as well.

Would it be better to mark that one as a duplicate of this, since we have more info here? (and workarounds):

This thread concerning intrepid also seems relevant http://ubuntuforums.org/showthread.php?t=963335 , and (at least) two of the fixes described there works for me; as far as I know both means not letting N-M join in the game at all:

# EITHER
$ update-rc.d -f NetworkManager remove
# RESTART
$ dhclient eth0
#
# OR
$ echo -e "auto eth0\niface eth0 inet dhcp" >> /etc/network/interfaces
# RESTART

I am really interested in getting a fix for this in jaunty so if there is anything more I could do in terms of poking and broking let me know.

[Martin Erik Werner (arand)]

OK, booting on the 10/April livecd this issue is completely solved for me.

I am clueless as to how or where it was fixed, but I think it would be a change somewhere between the 6th and 10th...

[TJ (tj)]

Arand, are you able to give us the exact kernel (uname -a) and network-manager (apt-cache policy network-manager) versions on those two live-CDs you've tested?
I don't have them to hand but it would make it easier to identify the change that fixed it - whether in linux or network-manager.

[Martin Erik Werner (arand)]

Here are the outputs (& attached):

N-M not working: 0.7.1~rc3.2.gitb8fc83a7-0ubuntu
N-M working: 0.7.1~rc4.1.cf199a964-0ubuntu1

kernel not working: 2.6.28-11-generic #38-Ubuntu
kernel working: 2.6.28-11-generic #41-Ubuntu

These I tested just now.

[TJ (tj)]

On Sat, 2009-04-11 at 12:44 +0000, arand wrote:
> Here are the outputs (& attached):

Thanks! I've started in the easy bit: looking fore any possible kernel
changes that would solve it. Here's the list of changes between .38
and .41 with the 'noise' filtered out.
>From a brief look at most of these I can't see any that would seem to
solve the issue so it looks more like a Network Manager change. If we
can find it it may be possible to back-port it:

git log --pretty=format:"%h %ci %s" Ubuntu-2.6.28-11.38..Ubuntu-2.6.28-11.41 | grep -v 'USB' | grep -vi 'LPIA' \
 | grep -v 'ARM' | grep -v 'Bluetooth' | grep -v 'mx51' | grep -v 'Start new release'
b5d8108 2009-04-07 22:25:57 -0600 UBUNTU: Ubuntu-2.6.28-11.41
c7e9104 2009-04-07 17:42:57 -0600 Revert "e1000e: add support for 82574 device ID 0x10F6"
6fdb18e 2009-04-07 15:47:52 -0700 Revert "UBUNTU: SAUCE: [i915] allocate MCHBAR space & enable if necessary"
bacedaa 2009-04-07 14:40:13 -0700 UBUNTU: SAUCE: Added quirk to recognize GE0301 3G modem as an interface.
26e0bd0 2009-04-07 14:22:42 -0700 UBUNTU: SAUCE: driver core: allow non-root users to listen to uevents
7314100 2009-04-07 14:08:52 -0700 UBUNTU: ixp4xx: Enabled TCP SYN_COOKIES
f304d82 2009-04-07 15:15:40 +0100 UBUNTU: SAUCE: NFS: Fix the notifications when renaming onto an existing file
334b875 2009-04-07 15:08:05 +0100 e1000e: add support for 82574 device ID 0x10F6
585806e 2009-04-04 09:00:50 -0600 hwmon: (abituguru3) Match partial DMI board name strings
b63e88b 2009-04-03 10:08:00 -0600 UBUNTU: Ubuntu-2.6.28-11.40
49cb4b4 2009-04-03 10:36:45 -0400 UBUNTU: Disable DEVKMEM for all archs on Jaunty
c4a450b 2009-04-03 14:45:57 +0100 UBUNTU: SAUCE: md: wait for possible pending deletes after stopping an array
f9ca66f 2009-04-02 23:03:08 -0400 UBUNTU: SAUCE: [i915] allocate MCHBAR space & enable if necessary
da84f1c 2009-04-02 14:36:46 -0400 hpilo: open/close fix
8ec710b 2009-04-01 17:47:38 -0600 UBUNTU: Ubuntu-2.6.28-11.39
ee83026 2009-04-01 19:38:07 +0100 UBUNTU: SAUCE: acer: rfkill disable quirk for ACER Aspire One
857feca 2009-04-01 09:37:43 -0400 UBUNTU: build CRAMFS into kernel to support mounting CRAMFS initrd on iop32x machine
091981a 2009-04-01 08:27:06 -0400 UBUNTU: SAUCE: Revert ENGR00103870 FEC reopening causes network wdog timeout

[Brandon Sandrowicz (bsandrow)]

I had this issue with wireless in two hotels I was staying at back in July. One was Radisson in Manchest, NH (http://www.radisson.com/hotels/nhmanch) and the other was a Rodeway near Boston Airport. Both were using the same company to provide their wireless access Safety Net Access (http://www.safetynetaccess.com/). I don't know if this helps any though.

Luckily for me I was dual-booting Windows, and was able to get on wireless through Windows to troubleshoot the issue. They offered ethernet through a wireless-ethernet bridge, but they wanted a $150 deposit to use it, which I wasn't about to do. I hope this might help, as someone may be able to contact Safety Net Access to see what hardware they are using, which may give clues to sort this out. I was running Ubuntu 8.10 at the time, so I cannot confirm if their network took issue with 9.04 or not.

I can confirm that I was able to access the network with iwconfig (and using kismet to view the available networks), but only when I rebooted with NetworkManager disabled. If I even so much as started NetworkManager, nothing short of a reboot -- with NM disabled -- would allow me to connect to that network (shutting NetworkManager back down didn't work, reloading modules didn't work, etc).

[Tony Espy (awe)]

Brandon, unless you were seeing the "No buffer space available" errors when running ifconfig, my gut tells me you ran into a separate problem. My suggestion to you would be to upgrade your machine to 9.04 at minimum, or if you're brave try the Karmic Beta ( or just wait two weeks for the final release ). At that point, if you run into the same connection problem again, please use the command:

ubuntu-bug network-manager

..to report the problem, as that will give us more information ( like driver type, NM log messages, etc... ) to help determine your problem.

[Tony Espy (awe)]

I'm also going to mark the network-manager portion of this bug "Incomplete". If someone is able to reproduce the original problem with Karmic Beta, and provide details on how to reproduce, then we consider looking at this again. I'll let someone else make the determination on the kernel side...

[penalvch (penalvch)]

Luigi Masselli, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.]