Skip to contentSkip to conversation

Ieee802154 socket problem with SIOCGIFADDR

DISCUSSION Matteo Petracca 2 participants 12 messages May 9, 2015 – May 12, 2015

Subsystems (2)
Networking IEEE 802.15.4
lore
Share & tools
lore

Matteo Petracca

author
#0 lore raw

Dear all,
I am working on a BeagleboneBlack with transceiver at86rf233.

When using ieee802154 sockets in my code I have:

ret = ioctl(socketfd, SIOCGIFADDR, &ifr);

and everything works fine with kernel 3.8.13.

In kernel 4.0.1 the request fails with the following kernel messages:

[  846.038365] RTNL: assertion failed at net/mac802154/iface.c (65)
[  846.044629] CPU: 0 PID: 2350 Comm: test Not tainted 4.0.1-bone1 #1
[  846.044653] Hardware name: Generic AM33XX (Flattened Device Tree)
[  846.044747] [<c0011f35>] (unwind_backtrace) from [<c00101b5>] (show_stack+0x11/0x14)
[  846.044876] [<c00101b5>] (show_stack) from [<bf8502f3>] (mac802154_wpan_ioctl+0xb6/0x100 [mac802154])
[  846.044972] [<bf8502f3>] (mac802154_wpan_ioctl [mac802154]) from [<bf8b738f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[  846.045044] [<bf8b738f>] (ieee802154_sock_ioctl [ieee802154_socket]) from [<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[  846.045094] [<c05195fb>] (sock_ioctl) from [<c00fca4d>] (do_vfs_ioctl+0x2cd/0x400)
[  846.045133] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>] (SyS_ioctl+0x4d/0x58)
[  846.045172] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>] (ret_fast_syscall+0x1/0x44)

Do you have any idea how to solve the problem?

Best,
Matteo

maintainer
#1 lore raw

Hi,

Quoted 27 lines · Matteo Petracca

Dear all,
I am working on a BeagleboneBlack with transceiver at86rf233.

When using ieee802154 sockets in my code I have:

ret = ioctl(socketfd, SIOCGIFADDR, &ifr);

and everything works fine with kernel 3.8.13.

In kernel 4.0.1 the request fails with the following kernel messages:

[  846.038365] RTNL: assertion failed at net/mac802154/iface.c (65)
[  846.044629] CPU: 0 PID: 2350 Comm: test Not tainted 4.0.1-bone1 #1
[  846.044653] Hardware name: Generic AM33XX (Flattened Device Tree)
[  846.044747] [<c0011f35>] (unwind_backtrace) from [<c00101b5>]
(show_stack+0x11/0x14)
[  846.044876] [<c00101b5>] (show_stack) from [<bf8502f3>]
(mac802154_wpan_ioctl+0xb6/0x100 [mac802154])
[  846.044972] [<bf8502f3>] (mac802154_wpan_ioctl [mac802154]) from
[<bf8b738f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[  846.045044] [<bf8b738f>] (ieee802154_sock_ioctl [ieee802154_socket]) from
[<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[  846.045094] [<c05195fb>] (sock_ioctl) from [<c00fca4d>]
(do_vfs_ioctl+0x2cd/0x400)
[  846.045133] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>]
(SyS_ioctl+0x4d/0x58)
[  846.045172] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>]
Quoted 4 lines

(ret_fast_syscall+0x1/0x44)

Do you have any idea how to solve the problem?

I did this assertion there because I supposed that the rtnl lock is hold while calling this callback. Now I see it isn't...

We need to hold the rtnl lock there because we accessing the mib values.

Try this:

net/mac802154/iface.c +3 -2
index 91b75ab..2a58788 100644
@@ -62,8 +62,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
                (struct sockaddr_ieee802154 *)&ifr->ifr_addr;
        int err = -ENOIOCTLCMD;
 
-       ASSERT_RTNL();
-
+       rtnl_lock();
        spin_lock_bh(&sdata->mib_lock);
 
        switch (cmd) {

@@ -90,6 +89,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
        case SIOCSIFADDR:
                if (netif_running(dev)) {
                        spin_unlock_bh(&sdata->mib_lock);
+                       rtnl_unlock();
                        return -EBUSY;
                }
 

@@ -112,6 +112,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
        }
 
        spin_unlock_bh(&sdata->mib_lock);
+       rtnl_unlock();
        return err;
 }

I will put it in my queue for next patch series to remove the mib/pib spinlocks. We have only the rtnl lock now.

- Alex

author
#2 lore raw

Hi,
I've applied your patch, but I ma still getting error:

.353646] Hardware name: Generic AM33XX (Flattened Device Tree)

[   88.353742] [<c0011f35>] (unwind_backtrace) from [<c00101b5>] (show_stack+0x11/0x14)
[   88.353870] [<c00101b5>] (show_stack) from [<bf8292fb>] (mac802154_wpan_ioctl+0xbe/0x10c [mac802154])
[   88.353974] [<bf8292fb>] (mac802154_wpan_ioctl [mac802154]) from [<bf8a138f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[   88.354059] [<bf8a138f>] (ieee802154_sock_ioctl [ieee802154_socket]) from [<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[   88.354109] [<c05195fb>] (sock_ioctl) from [<c00fca4d>] (do_vfs_ioctl+0x2cd/0x400)
[   88.354148] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>] (SyS_ioctl+0x4d/0x58)
[   88.354188] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>] (ret_fast_syscall+0x1/0x44)

Matteo

Quoted 76 lines · Alexander Aring

Hi,

Quoted 27 lines · Matteo Petracca

Dear all,
I am working on a BeagleboneBlack with transceiver at86rf233.

When using ieee802154 sockets in my code I have:

ret = ioctl(socketfd, SIOCGIFADDR, &ifr);

and everything works fine with kernel 3.8.13.

In kernel 4.0.1 the request fails with the following kernel messages:

[  846.038365] RTNL: assertion failed at net/mac802154/iface.c (65)
[  846.044629] CPU: 0 PID: 2350 Comm: test Not tainted 4.0.1-bone1 #1
[  846.044653] Hardware name: Generic AM33XX (Flattened Device Tree)
[  846.044747] [<c0011f35>] (unwind_backtrace) from [<c00101b5>]
(show_stack+0x11/0x14)
[  846.044876] [<c00101b5>] (show_stack) from [<bf8502f3>]
(mac802154_wpan_ioctl+0xb6/0x100 [mac802154])
[  846.044972] [<bf8502f3>] (mac802154_wpan_ioctl [mac802154]) from
[<bf8b738f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[  846.045044] [<bf8b738f>] (ieee802154_sock_ioctl [ieee802154_socket]) from
[<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[  846.045094] [<c05195fb>] (sock_ioctl) from [<c00fca4d>]
(do_vfs_ioctl+0x2cd/0x400)
[  846.045133] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>]
(SyS_ioctl+0x4d/0x58)
[  846.045172] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>]
Quoted 4 lines

(ret_fast_syscall+0x1/0x44)

Do you have any idea how to solve the problem?

I did this assertion there because I supposed that the rtnl lock is hold while calling this callback. Now I see it isn't...

We need to hold the rtnl lock there because we accessing the mib values.

Try this:

net/mac802154/iface.c +3 -2
index 91b75ab..2a58788 100644
@@ -62,8 +62,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
                 (struct sockaddr_ieee802154 *)&ifr->ifr_addr;
         int err = -ENOIOCTLCMD;
 
-       ASSERT_RTNL();
-
+       rtnl_lock();
         spin_lock_bh(&sdata->mib_lock);
 
         switch (cmd) {

@@ -90,6 +89,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
         case SIOCSIFADDR:
                 if (netif_running(dev)) {
                         spin_unlock_bh(&sdata->mib_lock);
+                       rtnl_unlock();
                         return -EBUSY;
                 }
 

@@ -112,6 +112,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
         }
 
         spin_unlock_bh(&sdata->mib_lock);
+       rtnl_unlock();
         return err;
  }

I will put it in my queue for next patch series to remove the mib/pib spinlocks. We have only the rtnl lock now.

- Alex

maintainer
#3 lore raw
Quoted 17 lines · Matteo Petracca

Hi,
I've applied your patch, but I ma still getting error:

.353646] Hardware name: Generic AM33XX (Flattened Device Tree)

[   88.353742] [<c0011f35>] (unwind_backtrace) from [<c00101b5>]
(show_stack+0x11/0x14)
[   88.353870] [<c00101b5>] (show_stack) from [<bf8292fb>]
(mac802154_wpan_ioctl+0xbe/0x10c [mac802154])
[   88.353974] [<bf8292fb>] (mac802154_wpan_ioctl [mac802154]) from
[<bf8a138f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[   88.354059] [<bf8a138f>] (ieee802154_sock_ioctl [ieee802154_socket]) from
[<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[   88.354109] [<c05195fb>] (sock_ioctl) from [<c00fca4d>]
(do_vfs_ioctl+0x2cd/0x400)
[   88.354148] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>]
(SyS_ioctl+0x4d/0x58)
[   88.354188] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>]
Quoted 2 lines

(ret_fast_syscall+0x1/0x44)

mhh, this sounds like another issue.

1. What's your exactly ioctl call, then I can maybe reproduce your issue.

2. There are some information missing at you stacktrace, can you provide more information?

- Alex

author
#4 lore raw

This is basically what I have in my program:

  int socketfd = 0;
  struct ifreq ifr;
  static const char *wpandevs[] = {
       "wpan0"
  };

socket_config_wpan = wpandevs[0];
socketfd = socket(PF_IEEE802154, SOCK_RAW, 0);

strncpy(ifr.ifr_name, socket_config_wpan, IF_NAMESIZE);
ret = ioctl(socketfd, SIOCGIFADDR, &ifr);

  if (ret < 0) {
      fprintf(stderr,"ioctl: SIOCGIFADDR error\n");
      return;

}

In can say that in kernel 3.8.13 it works with no problems.

Matteo

Quoted 28 lines · Alexander Aring
Quoted 17 lines · Matteo Petracca

Hi,
I've applied your patch, but I ma still getting error:

.353646] Hardware name: Generic AM33XX (Flattened Device Tree)

[   88.353742] [<c0011f35>] (unwind_backtrace) from [<c00101b5>]
(show_stack+0x11/0x14)
[   88.353870] [<c00101b5>] (show_stack) from [<bf8292fb>]
(mac802154_wpan_ioctl+0xbe/0x10c [mac802154])
[   88.353974] [<bf8292fb>] (mac802154_wpan_ioctl [mac802154]) from
[<bf8a138f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[   88.354059] [<bf8a138f>] (ieee802154_sock_ioctl [ieee802154_socket]) from
[<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[   88.354109] [<c05195fb>] (sock_ioctl) from [<c00fca4d>]
(do_vfs_ioctl+0x2cd/0x400)
[   88.354148] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>]
(SyS_ioctl+0x4d/0x58)
[   88.354188] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>]
Quoted 2 lines

(ret_fast_syscall+0x1/0x44)

mhh, this sounds like another issue.

1. What's your exactly ioctl call, then I can maybe reproduce your issue.

2. There are some information missing at you stacktrace, can you provide more information?

- Alex

maintainer
#5 lore raw
Quoted 12 lines · Matteo Petracca

This is basically what I have in my program:

  int socketfd = 0;
  struct ifreq ifr;
  static const char *wpandevs[] = {
       "wpan0"
  };

socket_config_wpan = wpandevs[0];
socketfd = socket(PF_IEEE802154, SOCK_RAW, 0);

Quoted 9 lines

strncpy(ifr.ifr_name, socket_config_wpan, IF_NAMESIZE);
ret = ioctl(socketfd, SIOCGIFADDR, &ifr);

  if (ret < 0) {
      fprintf(stderr,"ioctl: SIOCGIFADDR error\n");
      return;

}

In can say that in kernel 3.8.13 it works with no problems.

I wrote a dirty hack [0]. Run it on my side and detected no issue.

The output is:

pan_id 0xabcd
short_addr 0x2

and that's my current pan_id and short_addr setting.

- Alex

[0] http://pastebin.com/EE5wGZ5Q

maintainer
#6 lore raw
In reply to Alexander Aring
Quoted 21 lines · Alexander Aring
Quoted 17 lines · Matteo Petracca

Hi,
I've applied your patch, but I ma still getting error:

.353646] Hardware name: Generic AM33XX (Flattened Device Tree)

[   88.353742] [<c0011f35>] (unwind_backtrace) from [<c00101b5>]
(show_stack+0x11/0x14)
[   88.353870] [<c00101b5>] (show_stack) from [<bf8292fb>]
(mac802154_wpan_ioctl+0xbe/0x10c [mac802154])
[   88.353974] [<bf8292fb>] (mac802154_wpan_ioctl [mac802154]) from
[<bf8a138f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[   88.354059] [<bf8a138f>] (ieee802154_sock_ioctl [ieee802154_socket]) from
[<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[   88.354109] [<c05195fb>] (sock_ioctl) from [<c00fca4d>]
(do_vfs_ioctl+0x2cd/0x400)
[   88.354148] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>]
(SyS_ioctl+0x4d/0x58)
[   88.354188] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>]
Quoted 2 lines

(ret_fast_syscall+0x1/0x44)

Quoted 6 lines

mhh, this sounds like another issue.

1. What's your exactly ioctl call, then I can maybe reproduce your issue.

2. There are some information missing at you stacktrace, can you provide more information?

Maybe you can give me really the full output of the above stacktrace... Very important is the first line.

- Alex

maintainer
#7 lore raw
In reply to Matteo Petracca
Quoted 17 lines · Matteo Petracca

Hi,
I've applied your patch, but I ma still getting error:

.353646] Hardware name: Generic AM33XX (Flattened Device Tree)

[   88.353742] [<c0011f35>] (unwind_backtrace) from [<c00101b5>]
(show_stack+0x11/0x14)
[   88.353870] [<c00101b5>] (show_stack) from [<bf8292fb>]
(mac802154_wpan_ioctl+0xbe/0x10c [mac802154])
[   88.353974] [<bf8292fb>] (mac802154_wpan_ioctl [mac802154]) from
[<bf8a138f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[   88.354059] [<bf8a138f>] (ieee802154_sock_ioctl [ieee802154_socket]) from
[<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[   88.354109] [<c05195fb>] (sock_ioctl) from [<c00fca4d>]
(do_vfs_ioctl+0x2cd/0x400)
[   88.354148] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>]
(SyS_ioctl+0x4d/0x58)
[   88.354188] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>]
Quoted 1 line

(ret_fast_syscall+0x1/0x44)

maybe you did the wrong order and call rtnl_lock() after spin_lock_bh(&sdata->mib_lock). When I do that then I get the following:

[   35.581616] ------------[ cut here ]------------
[   35.586553] WARNING: CPU: 0 PID: 1236 at kernel/locking/mutex.c:734 __mutex_unlock_slowpath+0x180/0x1a4()
[   35.596767] DEBUG_LOCKS_WARN_ON(in_interrupt())
[   35.601392] Modules linked in:
[   35.604814] CPU: 0 PID: 1236 Comm: a.out Not tainted 4.1.0-rc1-00069-g1add156-dirty #856
[   35.613322] Hardware name: Generic AM33XX (Flattened Device Tree)
[   35.619777] [<c0016534>] (unwind_backtrace) from [<c001308c>] (show_stack+0x10/0x14)
[   35.627906] [<c001308c>] (show_stack) from [<c0638800>] (dump_stack+0x84/0x9c)
[   35.635542] [<c0638800>] (dump_stack) from [<c003ffc4>] (warn_slowpath_common+0x7c/0xb8)
[   35.644069] [<c003ffc4>] (warn_slowpath_common) from [<c0040030>] (warn_slowpath_fmt+0x30/0x40)
[   35.653237] [<c0040030>] (warn_slowpath_fmt) from [<c063d6d4>] (__mutex_unlock_slowpath+0x180/0x1a4)
[   35.662867] [<c063d6d4>] (__mutex_unlock_slowpath) from [<c04ec874>] (netdev_run_todo+0x38/0x2a0)
[   35.672243] [<c04ec874>] (netdev_run_todo) from [<c062c5f4>] (mac802154_wpan_ioctl+0x70/0x13c)
[   35.681324] [<c062c5f4>] (mac802154_wpan_ioctl) from [<c0628ecc>] (ieee802154_sock_ioctl+0x194/0x204)
[   35.691047] [<c0628ecc>] (ieee802154_sock_ioctl) from [<c04ccc54>] (sock_ioctl+0x1c8/0x2a4)
[   35.699856] [<c04ccc54>] (sock_ioctl) from [<c0159988>] (do_vfs_ioctl+0x408/0x670)
[   35.707799] [<c0159988>] (do_vfs_ioctl) from [<c0159c5c>] (SyS_ioctl+0x6c/0x7c)
[   35.715527] [<c0159c5c>] (SyS_ioctl) from [<c000f520>] (ret_fast_syscall+0x0/0x4c)
[   35.723507] ---[ end trace eba2e6f7e74c5074 ]---

So please check that your rtnl_lock() is before spin_lock_bh(&sdata->mib_lock).

I recently send patches to remove the pib/mib lock it's enough to locking everything is locked over rtnl (which is fix behaviour when somebody tries to ifup and set addresses at the same time) and the most mib values are readonly while ifup. I hope this will reduce the current locking complexity a lot.

- Alex

author
#8 lore raw

I've applied your patch properly.

By using your example this is what I have with kernel 4.0.2 for beagleboneblack

[   44.362497] NET: Registered protocol family 36
[   44.369646] RTNL: assertion failed at net/mac802154/iface.c (65)
[   44.375894] CPU: 0 PID: 1166 Comm: a.out Not tainted 4.0.2-bone1 #1
[   44.375917] Hardware name: Generic AM33XX (Flattened Device Tree)
[   44.376010] [<c0011f55>] (unwind_backtrace) from [<c00101c9>] (show_stack+0x11/0x14)
[   44.376126] [<c00101c9>] (show_stack) from [<bf8982fb>] (mac802154_wpan_ioctl+0xbe/0x10c [mac802154])
[   44.376237] [<bf8982fb>] (mac802154_wpan_ioctl [mac802154]) from [<bf8ac38f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[   44.376311] [<bf8ac38f>] (ieee802154_sock_ioctl [ieee802154_socket]) from [<c051996b>] (sock_ioctl+0xd3/0x1bc)
[   44.376360] [<c051996b>] (sock_ioctl) from [<c00fcad9>] (do_vfs_ioctl+0x2cd/0x400)
[   44.376398] [<c00fcad9>] (do_vfs_ioctl) from [<c00fcc59>] (SyS_ioctl+0x4d/0x58)
[   44.376436] [<c00fcc59>] (SyS_ioctl) from [<c000d641>] (ret_fast_syscall+0x1/0x44)

It is just using the code that you sent me yesterday.

Matteo

Quoted 52 lines · Alexander Aring
Quoted 17 lines · Matteo Petracca

Hi,
I've applied your patch, but I ma still getting error:

.353646] Hardware name: Generic AM33XX (Flattened Device Tree)

[   88.353742] [<c0011f35>] (unwind_backtrace) from [<c00101b5>]
(show_stack+0x11/0x14)
[   88.353870] [<c00101b5>] (show_stack) from [<bf8292fb>]
(mac802154_wpan_ioctl+0xbe/0x10c [mac802154])
[   88.353974] [<bf8292fb>] (mac802154_wpan_ioctl [mac802154]) from
[<bf8a138f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[   88.354059] [<bf8a138f>] (ieee802154_sock_ioctl [ieee802154_socket]) from
[<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[   88.354109] [<c05195fb>] (sock_ioctl) from [<c00fca4d>]
(do_vfs_ioctl+0x2cd/0x400)
[   88.354148] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>]
(SyS_ioctl+0x4d/0x58)
[   88.354188] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>]
Quoted 1 line

(ret_fast_syscall+0x1/0x44)

maybe you did the wrong order and call rtnl_lock() after spin_lock_bh(&sdata->mib_lock). When I do that then I get the following:

[   35.581616] ------------[ cut here ]------------
[   35.586553] WARNING: CPU: 0 PID: 1236 at kernel/locking/mutex.c:734 __mutex_unlock_slowpath+0x180/0x1a4()
[   35.596767] DEBUG_LOCKS_WARN_ON(in_interrupt())
[   35.601392] Modules linked in:
[   35.604814] CPU: 0 PID: 1236 Comm: a.out Not tainted 4.1.0-rc1-00069-g1add156-dirty #856
[   35.613322] Hardware name: Generic AM33XX (Flattened Device Tree)
[   35.619777] [<c0016534>] (unwind_backtrace) from [<c001308c>] (show_stack+0x10/0x14)
[   35.627906] [<c001308c>] (show_stack) from [<c0638800>] (dump_stack+0x84/0x9c)
[   35.635542] [<c0638800>] (dump_stack) from [<c003ffc4>] (warn_slowpath_common+0x7c/0xb8)
[   35.644069] [<c003ffc4>] (warn_slowpath_common) from [<c0040030>] (warn_slowpath_fmt+0x30/0x40)
[   35.653237] [<c0040030>] (warn_slowpath_fmt) from [<c063d6d4>] (__mutex_unlock_slowpath+0x180/0x1a4)
[   35.662867] [<c063d6d4>] (__mutex_unlock_slowpath) from [<c04ec874>] (netdev_run_todo+0x38/0x2a0)
[   35.672243] [<c04ec874>] (netdev_run_todo) from [<c062c5f4>] (mac802154_wpan_ioctl+0x70/0x13c)
[   35.681324] [<c062c5f4>] (mac802154_wpan_ioctl) from [<c0628ecc>] (ieee802154_sock_ioctl+0x194/0x204)
[   35.691047] [<c0628ecc>] (ieee802154_sock_ioctl) from [<c04ccc54>] (sock_ioctl+0x1c8/0x2a4)
[   35.699856] [<c04ccc54>] (sock_ioctl) from [<c0159988>] (do_vfs_ioctl+0x408/0x670)
[   35.707799] [<c0159988>] (do_vfs_ioctl) from [<c0159c5c>] (SyS_ioctl+0x6c/0x7c)
[   35.715527] [<c0159c5c>] (SyS_ioctl) from [<c000f520>] (ret_fast_syscall+0x0/0x4c)
[   35.723507] ---[ end trace eba2e6f7e74c5074 ]---

So please check that your rtnl_lock() is before spin_lock_bh(&sdata->mib_lock).

I recently send patches to remove the pib/mib lock it's enough to locking everything is locked over rtnl (which is fix behaviour when somebody tries to ifup and set addresses at the same time) and the most mib values are readonly while ifup. I hope this will reduce the current locking complexity a lot.

- Alex

maintainer
#9 lore raw
Quoted 7 lines · Matteo Petracca

I've applied your patch properly.

By using your example this is what I have with kernel 4.0.2 for beagleboneblack

[   44.362497] NET: Registered protocol family 36
[   44.369646] RTNL: assertion failed at net/mac802154/iface.c (65)

can't be. The patch removes the RTNL assertion. Please check if you really rebuild and update your kernel/modules.

Maybe try uname -a and check kernels build date/git HEAD id/whatever.

- Alex

author
#10 lore raw

You were right, I did not remove the Assertion.

Now the patch is all there and the modules are updated.

What happens now is a strange behaviour, booting the system I just turn on the wpan interface putting as panid 0xaaaa:

ifconfig wpan0 up

the device starts to read from the network, and this is what I have in output with dmesg is:

[  131.445285] ieee802154: bad frame received (type = 3)
[  133.777933] ieee802154: bad frame received (type = 3)
[  136.110635] ieee802154: bad frame received (type = 3)
[  148.318471] ieee802154: bad frame received (type = 3)
[  150.651288] ieee802154: bad frame received (type = 3)
[  152.984910] ieee802154: bad frame received (type = 3)
[  165.195277] ieee802154: bad frame received (type = 3)
[  167.527936] ieee802154: bad frame received (type = 3)
[  169.860422] ieee802154: bad frame received (type = 3)
[  182.071635] ieee802154: bad frame received (type = 3)
[  184.406857] ieee802154: bad frame received (type = 3)
[  186.739487] ieee802154: bad frame received (type = 3)
[  198.947054] ieee802154: bad frame received (type = 3)
[  201.279710] ieee802154: bad frame received (type = 3)
[  203.612262] ieee802154: bad frame received (type = 3)
[  215.819843] ieee802154: bad frame received (type = 3)
[  218.155852] ieee802154: bad frame received (type = 3)
[  220.488465] ieee802154: bad frame received (type = 3)

Moreover SIOCGIFADDR still does not work.

Sorry for bothering you.

I don't know what to think.

Matteo

Quoted 18 lines · Alexander Aring
Quoted 7 lines · Matteo Petracca

I've applied your patch properly.

By using your example this is what I have with kernel 4.0.2 for beagleboneblack

[   44.362497] NET: Registered protocol family 36
[   44.369646] RTNL: assertion failed at net/mac802154/iface.c (65)

can't be. The patch removes the RTNL assertion. Please check if you really rebuild and update your kernel/modules.

Maybe try uname -a and check kernels build date/git HEAD id/whatever.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

maintainer
#11 lore raw
Quoted 33 lines · Matteo Petracca

You were right, I did not remove the Assertion.

Now the patch is all there and the modules are updated.

What happens now is a strange behaviour, booting the system I just turn on the wpan interface putting as panid 0xaaaa:

ifconfig wpan0 up

the device starts to read from the network, and this is what I have in output with dmesg is:

[  131.445285] ieee802154: bad frame received (type = 3)
[  133.777933] ieee802154: bad frame received (type = 3)
[  136.110635] ieee802154: bad frame received (type = 3)
[  148.318471] ieee802154: bad frame received (type = 3)
[  150.651288] ieee802154: bad frame received (type = 3)
[  152.984910] ieee802154: bad frame received (type = 3)
[  165.195277] ieee802154: bad frame received (type = 3)
[  167.527936] ieee802154: bad frame received (type = 3)
[  169.860422] ieee802154: bad frame received (type = 3)
[  182.071635] ieee802154: bad frame received (type = 3)
[  184.406857] ieee802154: bad frame received (type = 3)
[  186.739487] ieee802154: bad frame received (type = 3)
[  198.947054] ieee802154: bad frame received (type = 3)
[  201.279710] ieee802154: bad frame received (type = 3)
[  203.612262] ieee802154: bad frame received (type = 3)
[  215.819843] ieee802154: bad frame received (type = 3)
[  218.155852] ieee802154: bad frame received (type = 3)
[  220.488465] ieee802154: bad frame received (type = 3)
Quoted 2 lines

Moreover SIOCGIFADDR still does not work.

This is a behaviour because we have lack of support to parse mac_cmd frames [0]. And I see now I already told you that! [1]

The current parsing mechanism is very dataframes specfic there is an draft for reworking this frame parsing style and do it like mac80211 (which have a lot of more frametypes than 802.15.4). See [2]:
"new frame parsing style in mac802154 and ieee802154 based on mac80211 frame parsing design. Draft is mac802154 rx and 6LoWPAN. Crypto need to be done at first, otherwise I can’t test it."

Nevertheless it needs time to supporting it, you could simple add a case that the frame is delivered to userspace, but then this frame could not valid 802.15.4 frametype and you need to check that again in userspace.

I also noticed that the raw socket don't put the mac header into payload (which should it do), see [3] (that's something which already told you).

and yes, the 802.15.4 sockets needs a complete rework/cleanup. This is an opentask section at [4], we should orient us at bluetooth socket code.

- Alex

[0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/mac802154/rx.c#n104
[1] http://www.spinics.net/lists/linux-wpan/msg01623.html
[2] http://wpan.cakelab.org/
[3] http://www.spinics.net/lists/linux-wpan/msg01623.html
[4] http://wpan.cakelab.org/