Hi!
I'm trying to get the latest p54 wireless drivers (ad-hoc mode)
to work on a Nokia N810... So far, without any success.
Some words about my scenario:
- Nokia N810 running a custom omap1 kernel
(linux-omap-2.6.git / tag: "v2.6.29-omap1")
Patched keyboard (board-n800.c) and usb driver (usb-tusb6010.c)
to get it working...
- Installed Mer (Ubuntu 9.04) on an external mmc 4GB card
Patched the bootmenu stuff to get rid of static /dev/ nodes problem
which come up with the new kernel...
- compiled compat wireless drivers 2009-07-09
disabled CONFIG_RFKILL_BACKPORT_LEDS because it didn't compile
- A second N810 running debian and nokias 2.6.21er kernel
Ad-hoc mode is active. (ad-hoc is working, tested with some
other N810 devices)
After all these preparations, patching and workaround stuff,
i finally inserted the wireless modules into the kernel
(rfkill_backport, cfg80211, mac80211, p54common, p54spi)
dmesg looks fine so far:
[ 3671.237365] cfg80211: Using static regulatory domain info
[ 3671.237396] cfg80211: Regulatory domain: US
[ 3671.237426] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 3671.237457] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[ 3671.237487] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 3671.237518] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 3671.237548] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 3671.237579] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 3671.237609] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[ 3671.238555] cfg80211: Calling CRDA for country: US
[ 3685.186523] cx3110x spi2.0: firmware: requesting 3826.arm
[ 3685.265045] phy0: p54 detected a LM20 firmware
[ 3685.265106] p54: rx_mtu reduced from 3240 to 2376
[ 3685.265106] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6
[ 3685.265136] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
[ 3685.265197] cx3110x spi2.0: firmware: requesting 3826.eeprom
[ 3685.320800] cx3110x spi2.0: loading default eeprom...
[ 3685.320922] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow
[ 3685.455108] phy0: Selected rate control algorithm 'minstrel'
[ 3685.456787] Registered led device: p54-phy0::assoc
[ 3685.457031] Registered led device: p54-phy0::tx
[ 3685.457275] Registered led device: p54-phy0::rx
[ 3685.457489] Registered led device: p54-phy0::radio
[ 3685.457550] cx3110x spi2.0: is registered as 'phy0'
Monitor mode is also working. Here are some beacons from my second device:
00:01:37.463744 51669459us tsft 1.0 Mb/s 2462 MHz (0x00a0) 30dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
00:01:37.566100 51771860us tsft 1.0 Mb/s 2462 MHz (0x00a0) 29dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
00:01:37.668517 51874300us tsft 1.0 Mb/s 2462 MHz (0x00a0) 30dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
After this short test, i switched the driver into ad-hoc mode,
setup the essid, channel and assigned an ip address... I tried
to ping, tcpdump, whatsoever... nothing happens. Driver statistics
are also frozen (in monitor mode the rx stats incr.).
The only hints to the problem are:
- this repeating kernel msg:
[...cut...]
[ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
[ 3905.535186] Modules linked in: p54spi p54common mac80211 cfg80211 rfkill_backport
[ 3905.535247] [<c02b73a0>] (dump_stack+0x0/0x14) from [<c00541cc>] (warn_slowpath+0x70/0x8c)
[ 3905.535308] [<c005415c>] (warn_slowpath+0x0/0x8c) from [<bf02af40>] (sta_info_insert+0x7c/0x15c [mac80211])
[ 3905.535522] r3:00000000 r2:00000000
[ 3905.535552] r7:c53a4200 r6:c7e65800 r5:0000c0ee r4:c5303b60
[ 3905.535583] [<bf02aec4>] (sta_info_insert+0x0/0x15c [mac80211]) from [<bf02f220>] (ieee80211_ibss_add_sta+0x114/0x130 [mac80211])
[ 3905.535919] r7:c7d9442e r6:c7e65800 r5:c53a4200 r4:c7e65800
[ 3905.535949] [<bf02f10c>] (ieee80211_ibss_add_sta+0x0/0x130 [mac80211]) from [<bf02f35c>] (ieee80211_rx_bss_info+0x120/0x160 [mac80211])
[ 3905.536407] [<bf02f23c>] (ieee80211_rx_bss_info+0x0/0x160 [mac80211]) from [<bf02f590>] (ieee80211_ibss_rx_queued_mgmt+0x1f4/0x274 [mac80211])
[ 3905.536743] [<bf02f39c>] (ieee80211_ibss_rx_queued_mgmt+0x0/0x274 [mac80211]) from [<bf02f684>] (ieee80211_ibss_work+0x74/0x198 [mac80211])
[ 3905.537048] [<bf02f610>] (ieee80211_ibss_work+0x0/0x198 [mac80211]) from [<c0064318>] (run_workqueue+0xac/0x124)
[ 3905.537261] r5:c53ac000 r4:c53a7a80
[ 3905.537292] [<c006426c>] (run_workqueue+0x0/0x124) from [<c00649dc>] (worker_thread+0x104/0x118)
[ 3905.537353] r7:c53a7a88 r6:c53adfa4 r5:c53ac000 r4:c53a7a80
[ 3905.537384] [<c00648d8>] (worker_thread+0x0/0x118) from [<c0067fe4>] (kthread+0x58/0x94)
[ 3905.537475] r7:00000000 r6:c53a7a80 r5:c00648d8 r4:c53ac000
[ 3905.537506] [<c0067f8c>] (kthread+0x0/0x94) from [<c0057054>] (do_exit+0x0/0x67c)
[ 3905.537567] r7:00000000 r6:00000000 r5:00000000 r4:00000000
[ 3905.537597] ---[ end trace 09523b411832988b ]---
[...cut...]
- and the fact, that the device is up, but not "running"
# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:02:ee:c0:ff:ee
inet addr:10.0.59.34 Bcast:10.0.59.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:550 errors:0 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:58779 (58.7 KB) TX bytes:1080 (1.0 KB)
# iwconfig wlan0
wlan0 IEEE 802.11bg ESSID:"rita"
Mode:Ad-Hoc Frequency:2.462 GHz Cell: 1A:7E:4B:A7:14:45
Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
If you have any ideas, or patches or infos,
i'll be happy to try these and give some feedback :)
Regards,
AleX
ps: If you need further infos, just let me know...
--
**********************************************
Dipl.-Inform. (FH) Alexander Wenzel
Forschungsgesellschaft fuer
Angewandte Naturwissenschaften e. V. (FGAN)
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel. : 0049 (0)228 9435-263
Fax : 0049 (0)228 9435-685
E-Mail: [email protected]
Web : http://www.fgan.de/
**********************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. Maurus Tacke (komm. Vors.)
Prof. Dr. Joachim Ender (Stellv.)
В сообщении от Thursday 09 July 2009 Kalle Valo написал(a):
> Christian Lamparter <[email protected]> writes:
>
> >> These data for sure must reside on /dev/mtdblk1 partition, but
> >> they're probably somehow coded/obfuscated. I couldn't find anything
> >> similar to MAC of my own n810 there.
> >
> > well, this is c0ffee comes from nokia's stlc45xx-driver.
> > Unfortunately, they don't say how to get the device eeprom from the
> > mtdblk1 partition. However, they certainly provide a tool stlc45xx-cal
> > (available at: http://stlc45xx.garage.maemo.org/ ) which can be used
> > to locate the eeprom's calibration data.
>
> stlc45xx-cal pushes the device specific calibration data and sets the
> MAC address. It's recommended to run it to get optimal performance.
>
IIRC stlc45xx-cal pushes these data into sysfs entries, which stlc45xx used to create.
There's no such interface in p54spi.
Thanks.
-- Max
Christian Lamparter <[email protected]> writes:
>> These data for sure must reside on /dev/mtdblk1 partition, but
>> they're probably somehow coded/obfuscated. I couldn't find anything
>> similar to MAC of my own n810 there.
>
> well, this is c0ffee comes from nokia's stlc45xx-driver.
> Unfortunately, they don't say how to get the device eeprom from the
> mtdblk1 partition. However, they certainly provide a tool stlc45xx-cal
> (available at: http://stlc45xx.garage.maemo.org/ ) which can be used
> to locate the eeprom's calibration data.
stlc45xx-cal pushes the device specific calibration data and sets the
MAC address. It's recommended to run it to get optimal performance.
--
Kalle Valo
On Fri, 2009-07-10 at 01:43 +0400, Max Filippov wrote:
> В сообщении от Thursday 09 July 2009 Kalle Valo написал(a):
> > Christian Lamparter <[email protected]> writes:
> >
> > >> These data for sure must reside on /dev/mtdblk1 partition, but
> > >> they're probably somehow coded/obfuscated. I couldn't find anything
> > >> similar to MAC of my own n810 there.
> > >
> > > well, this is c0ffee comes from nokia's stlc45xx-driver.
> > > Unfortunately, they don't say how to get the device eeprom from the
> > > mtdblk1 partition. However, they certainly provide a tool stlc45xx-cal
> > > (available at: http://stlc45xx.garage.maemo.org/ ) which can be used
> > > to locate the eeprom's calibration data.
> >
> > stlc45xx-cal pushes the device specific calibration data and sets the
> > MAC address. It's recommended to run it to get optimal performance.
> >
> IIRC stlc45xx-cal pushes these data into sysfs entries, which stlc45xx used to create.
> There's no such interface in p54spi.
Should be easy to copy the code into p54spi, we just never did, hoping
Kalle would come up with a better way, maybe request_firmware() :)
johannes
Johannes Berg <[email protected]> writes:
>> > stlc45xx-cal pushes the device specific calibration data and sets the
>> > MAC address. It's recommended to run it to get optimal performance.
>> >
>> IIRC stlc45xx-cal pushes these data into sysfs entries, which
>> stlc45xx used to create. There's no such interface in p54spi.
Oh yeah, I forgot that.
> Should be easy to copy the code into p54spi, we just never did, hoping
> Kalle would come up with a better way, maybe request_firmware() :)
I agree with you, better not to copy the sysfs interface to p54spi. I'm
planning to experiment with the firmware interface at some point, but it
would be great if someone else could take a look at it first.
--
Kalle Valo
В сообщении от Thursday 09 July 2009 Alexander Wenzel написал(a):
> Hi!
> >> I'm trying to get the latest p54 wireless drivers (ad-hoc mode)
> >> to work on a Nokia N810... So far, without any success.
> >> [ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
> > As far as I can see, this is check that incoming STA and your STA have
> > different MAC addresses. If you don't set up MAC manually on both
> > devices and make it unique, chances high that they are equal.
>
> You saved my day :D Finally it works...! Thanks for the hint.
>
> [ 214.478668] wlan0: Selected IBSS BSSID 56:97:1a:24:11:6c based on configured SSID
>
> # iw dev wlan0 station dump
> Station 00:02:ee:c0:ff:ee (on wlan0)
> inactive time: 429 ms
> rx bytes: 8964
> tx bytes: 408
> signal: 55 dBm
> tx bitrate: 1.0 MBit/s
>
> I just checked the other N810 devices and every device has
> the same mac address. And here we go... [p54spi_eeprom.h:39]
> 0x00, 0x02, 0xee, 0xc0, 0xff, 0xee,
>
> The original kernel with default os shows the correct address.
> When booting a different os with the with the original or custom
> kernel it shows the 'coffee' address.
> So is there a way to let the kernel receive and set the
> correct mac address of the wlan device?
> I guess my problem is this line:
> [ 3685.320800] cx3110x spi2.0: loading default eeprom...
You're right. I guess that easiest way to deal with it is to save blob from p54spi_eeprom.h into a file
3826.eeprom in the same directory as 3826.arm and fix MAC address in it, according to comments in p54spi_eeprom.h
These data for sure must reside on /dev/mtdblk1 partition, but they're probably somehow coded/obfuscated.
I couldn't find anything similar to MAC of my own n810 there.
Thanks.
-- Max
On Thu, Jul 9, 2009 at 3:59 PM, Alexander Wenzel<[email protected]> wrote:
> Hi!
> I'm trying to get the latest p54 wireless drivers (ad-hoc mode)
> to work on a Nokia N810... So far, without any success.
>
> Some words about my scenario:
> - Nokia N810 running a custom omap1 kernel
> ?(linux-omap-2.6.git / tag: "v2.6.29-omap1")
> ?Patched keyboard (board-n800.c) and usb driver (usb-tusb6010.c)
> ?to get it working...
>
> - Installed Mer (Ubuntu 9.04) on an external mmc 4GB card
> ?Patched the bootmenu stuff to get rid of static /dev/ nodes problem
> ?which come up with the new kernel...
>
> - compiled compat wireless drivers 2009-07-09
> ?disabled CONFIG_RFKILL_BACKPORT_LEDS because it didn't compile
>
> - A second N810 running debian and nokias 2.6.21er kernel
> ?Ad-hoc mode is active. (ad-hoc is working, tested with some
> ?other N810 devices)
>
> After all these preparations, patching and workaround stuff,
> i finally inserted the wireless modules into the kernel
> (rfkill_backport, cfg80211, mac80211, p54common, p54spi)
> dmesg looks fine so far:
> [ 3671.237365] cfg80211: Using static regulatory domain info
> [ 3671.237396] cfg80211: Regulatory domain: US
> [ 3671.237426] ?(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> [ 3671.237457] ?(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
> [ 3671.237487] ?(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 3671.237518] ?(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 3671.237548] ?(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 3671.237579] ?(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 3671.237609] ?(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
> [ 3671.238555] cfg80211: Calling CRDA for country: US
> [ 3685.186523] cx3110x spi2.0: firmware: requesting 3826.arm
> [ 3685.265045] phy0: p54 detected a LM20 firmware
> [ 3685.265106] p54: rx_mtu reduced from 3240 to 2376
> [ 3685.265106] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6
> [ 3685.265136] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
> [ 3685.265197] cx3110x spi2.0: firmware: requesting 3826.eeprom
> [ 3685.320800] cx3110x spi2.0: loading default eeprom...
> [ 3685.320922] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow
> [ 3685.455108] phy0: Selected rate control algorithm 'minstrel'
> [ 3685.456787] Registered led device: p54-phy0::assoc
> [ 3685.457031] Registered led device: p54-phy0::tx
> [ 3685.457275] Registered led device: p54-phy0::rx
> [ 3685.457489] Registered led device: p54-phy0::radio
> [ 3685.457550] cx3110x spi2.0: is registered as 'phy0'
>
> Monitor mode is also working. Here are some beacons from my second device:
> 00:01:37.463744 51669459us tsft 1.0 Mb/s 2462 MHz (0x00a0) 30dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
> 00:01:37.566100 51771860us tsft 1.0 Mb/s 2462 MHz (0x00a0) 29dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
> 00:01:37.668517 51874300us tsft 1.0 Mb/s 2462 MHz (0x00a0) 30dB signal -63dB noise antenna 0 [0x0000000e] Beacon (rita) [1.0* 2.0* 5.5 11.0 Mbit] IBSS CH: 11
>
> After this short test, i switched the driver into ad-hoc mode,
> setup the essid, channel and assigned an ip address... I tried
> to ping, tcpdump, whatsoever... nothing happens. Driver statistics
> are also frozen (in monitor mode the rx stats incr.).
> The only hints to the problem are:
> - this repeating kernel msg:
> [...cut...]
> [ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
> [ 3905.535186] Modules linked in: p54spi p54common mac80211 cfg80211 rfkill_backport
> [ 3905.535247] [<c02b73a0>] (dump_stack+0x0/0x14) from [<c00541cc>] (warn_slowpath+0x70/0x8c)
> [ 3905.535308] [<c005415c>] (warn_slowpath+0x0/0x8c) from [<bf02af40>] (sta_info_insert+0x7c/0x15c [mac80211])
> [ 3905.535522] ?r3:00000000 r2:00000000
> [ 3905.535552] ?r7:c53a4200 r6:c7e65800 r5:0000c0ee r4:c5303b60
> [ 3905.535583] [<bf02aec4>] (sta_info_insert+0x0/0x15c [mac80211]) from [<bf02f220>] (ieee80211_ibss_add_sta+0x114/0x130 [mac80211])
> [ 3905.535919] ?r7:c7d9442e r6:c7e65800 r5:c53a4200 r4:c7e65800
> [ 3905.535949] [<bf02f10c>] (ieee80211_ibss_add_sta+0x0/0x130 [mac80211]) from [<bf02f35c>] (ieee80211_rx_bss_info+0x120/0x160 [mac80211])
> [ 3905.536407] [<bf02f23c>] (ieee80211_rx_bss_info+0x0/0x160 [mac80211]) from [<bf02f590>] (ieee80211_ibss_rx_queued_mgmt+0x1f4/0x274 [mac80211])
> [ 3905.536743] [<bf02f39c>] (ieee80211_ibss_rx_queued_mgmt+0x0/0x274 [mac80211]) from [<bf02f684>] (ieee80211_ibss_work+0x74/0x198 [mac80211])
> [ 3905.537048] [<bf02f610>] (ieee80211_ibss_work+0x0/0x198 [mac80211]) from [<c0064318>] (run_workqueue+0xac/0x124)
> [ 3905.537261] ?r5:c53ac000 r4:c53a7a80
> [ 3905.537292] [<c006426c>] (run_workqueue+0x0/0x124) from [<c00649dc>] (worker_thread+0x104/0x118)
> [ 3905.537353] ?r7:c53a7a88 r6:c53adfa4 r5:c53ac000 r4:c53a7a80
> [ 3905.537384] [<c00648d8>] (worker_thread+0x0/0x118) from [<c0067fe4>] (kthread+0x58/0x94)
> [ 3905.537475] ?r7:00000000 r6:c53a7a80 r5:c00648d8 r4:c53ac000
> [ 3905.537506] [<c0067f8c>] (kthread+0x0/0x94) from [<c0057054>] (do_exit+0x0/0x67c)
> [ 3905.537567] ?r7:00000000 r6:00000000 r5:00000000 r4:00000000
> [ 3905.537597] ---[ end trace 09523b411832988b ]---
> [...cut...]
>
> - and the fact, that the device is up, but not "running"
> # ifconfig wlan0
> wlan0 ? ? Link encap:Ethernet ?HWaddr 00:02:ee:c0:ff:ee
> ? ? ? ? ?inet addr:10.0.59.34 ?Bcast:10.0.59.255 ?Mask:255.255.255.0
> ? ? ? ? ?UP BROADCAST MULTICAST ?MTU:1500 ?Metric:1
> ? ? ? ? ?RX packets:550 errors:0 dropped:0 overruns:0 frame:0
> ? ? ? ? ?TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
> ? ? ? ? ?collisions:0 txqueuelen:1000
> ? ? ? ? ?RX bytes:58779 (58.7 KB) ?TX bytes:1080 (1.0 KB)
>
> # iwconfig wlan0
> wlan0 ? ? IEEE 802.11bg ?ESSID:"rita"
> ? ? ? ? ?Mode:Ad-Hoc ?Frequency:2.462 GHz ?Cell: 1A:7E:4B:A7:14:45
> ? ? ? ? ?Tx-Power=27 dBm
> ? ? ? ? ?Retry ?long limit:7 ? RTS thr:off ? Fragment thr:off
> ? ? ? ? ?Encryption key:off
> ? ? ? ? ?Power Management:off
>
> If you have any ideas, or patches or infos,
> i'll be happy to try these and give some feedback :)
>
> Regards,
> AleX
>
> ps: If you need further infos, just let me know...
> --
> **********************************************
> Dipl.-Inform. (FH) Alexander Wenzel
> Forschungsgesellschaft fuer
> Angewandte Naturwissenschaften e. V. (FGAN)
> Neuenahrer Str. 20, 53343 Wachtberg, Germany
> Tel. ?: 0049 (0)228 9435-263
> Fax ? : 0049 (0)228 9435-685
> E-Mail: [email protected]
> Web ? : http://www.fgan.de/
> **********************************************
> Sitz der Gesellschaft: Bonn
> Registergericht: Amtsgericht Bonn VR 2530
> Vorstand: Prof. Dr. Maurus Tacke (komm. Vors.)
> ? ? ? ? ?Prof. Dr. Joachim Ender (Stellv.)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Hello.
> [ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
As far as I can see, this is check that incoming STA and your STA have
different MAC addresses. If you don't set up MAC manually on both
devices and make it unique, chances high that they are equal.
--
Max
Hi!
>> I'm trying to get the latest p54 wireless drivers (ad-hoc mode)
>> to work on a Nokia N810... So far, without any success.
>> [ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
> As far as I can see, this is check that incoming STA and your STA have
> different MAC addresses. If you don't set up MAC manually on both
> devices and make it unique, chances high that they are equal.
You saved my day :D Finally it works...! Thanks for the hint.
[ 214.478668] wlan0: Selected IBSS BSSID 56:97:1a:24:11:6c based on configured SSID
# iw dev wlan0 station dump
Station 00:02:ee:c0:ff:ee (on wlan0)
inactive time: 429 ms
rx bytes: 8964
tx bytes: 408
signal: 55 dBm
tx bitrate: 1.0 MBit/s
I just checked the other N810 devices and every device has
the same mac address. And here we go... [p54spi_eeprom.h:39]
0x00, 0x02, 0xee, 0xc0, 0xff, 0xee,
The original kernel with default os shows the correct address.
When booting a different os with the with the original or custom
kernel it shows the 'coffee' address.
So is there a way to let the kernel receive and set the
correct mac address of the wlan device?
I guess my problem is this line:
[ 3685.320800] cx3110x spi2.0: loading default eeprom...
Anyway, i'm happy that it's working now.
Regards,
AleX
--
**********************************************
Dipl.-Inform. (FH) Alexander Wenzel
Forschungsgesellschaft fuer
Angewandte Naturwissenschaften e. V. (FGAN)
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel. : 0049 (0)228 9435-263
Fax : 0049 (0)228 9435-685
E-Mail: [email protected]
Web : http://www.fgan.de/
**********************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. Maurus Tacke (komm. Vors.)
Prof. Dr. Joachim Ender (Stellv.)
Hi there...
>> I just checked the other N810 devices and every device has
>> the same mac address. And here we go... [p54spi_eeprom.h:39]
>> 0x00, 0x02, 0xee, 0xc0, 0xff, 0xee,
>> So is there a way to let the kernel receive and set the
>> correct mac address of the wlan device?
>> I guess my problem is this line:
>> [ 3685.320800] cx3110x spi2.0: loading default eeprom...
> You're right. I guess that easiest way to deal with it is to save blob from p54spi_eeprom.h into a file
> 3826.eeprom in the same directory as 3826.arm and fix MAC address in it, according to comments in p54spi_eeprom.h
[ 2675.558532] cx3110x spi2.0: firmware: requesting 3826.eeprom
[ 2675.625579] cx3110x spi2.0: loading user eeprom...
[ 2675.625671] phy0: hwaddr 00:1d:6e:9c:**:**, MAC:isl3820 RF:Longbow
Ok, p54 with user eeprom and manually inserted mac address works fine.
So, a part of the problem is somehow "fixed"... Thanks.
Regards,
AleX
--
**********************************************
Dipl.-Inform. (FH) Alexander Wenzel
Forschungsgesellschaft fuer
Angewandte Naturwissenschaften e. V. (FGAN)
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel. : 0049 (0)228 9435-263
Fax : 0049 (0)228 9435-685
E-Mail: [email protected]
Web : http://www.fgan.de/
**********************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. Maurus Tacke (komm. Vors.)
Prof. Dr. Joachim Ender (Stellv.)
Max Filippov <[email protected]> writes:
>>> Should be easy to copy the code into p54spi, we just never did, hoping
>>> Kalle would come up with a better way, maybe request_firmware() :)
>>
>> I agree with you, better not to copy the sysfs interface to p54spi. I'm
>> planning to experiment with the firmware interface at some point, but it
>> would be great if someone else could take a look at it first.
>
> I can take a look at it. (:
Excellent!
> But the question is... to take a look at it to see what?
:)
Basically we have been talking about fetching calibration data via the
request_firmware() interface. In user space there would be a udev script
which would dynamically retrieve the calibration data specific to the
platform it is running on. In N800/N810 case that would mean to run
stlc45xx-cal and provide the calibration data to the driver.
This way we can have platform specific implementations and use already
existing user space interface. The idea was discussed in this mailing
list few months ago. The implementation details are currently unknown to
me. I was planning to talk about this at the Wireless Summit, but of
course I forgot :/
stlc45xx-cal will most probably need some changes, maybe dumping the
calibration data to stdout so that udev script can forward it to the
driver? I can do the necessary changes to stlc45xx-cal, but it's better
to have a some sort of working prototype before I'll start changing
stlc45xx-cal.
--
Kalle Valo
> Basically we have been talking about fetching calibration data via the
> request_firmware() interface. In user space there would be a udev script
> which would dynamically retrieve the calibration data specific to the
> platform it is running on. In N800/N810 case that would mean to run
> stlc45xx-cal and provide the calibration data to the driver.
>
> This way we can have platform specific implementations and use already
> existing user space interface. The idea was discussed in this mailing
> list few months ago. The implementation details are currently unknown to
> me. I was planning to talk about this at the Wireless Summit, but of
> course I forgot :/
>
> stlc45xx-cal will most probably need some changes, maybe dumping the
> calibration data to stdout so that udev script can forward it to the
> driver? I can do the necessary changes to stlc45xx-cal, but it's better
> to have a some sort of working prototype before I'll start changing
> stlc45xx-cal.
Ok. Gonna make such prototype during this weekend.
--
Max
On Thursday 09 July 2009 19:57:20 Max Filippov wrote:
> В сообщении от Thursday 09 July 2009 Alexander Wenzel написал(a):
^^
> > Hi!
> > >> I'm trying to get the latest p54 wireless drivers (ad-hoc mode)
> > >> to work on a Nokia N810... So far, without any success.
> > >> [ 3905.535125] WARNING: at /home/wen/work/NokiaN810/compat-wireless-2009-07-09/net/mac80211/sta_info.c:339 sta_info_insert+0x7c/0x15c [mac80211]()
> > > As far as I can see, this is check that incoming STA and your STA have
> > > different MAC addresses. If you don't set up MAC manually on both
> > > devices and make it unique, chances high that they are equal.
> >
> > You saved my day :D Finally it works...! Thanks for the hint.
> >
> > [ 214.478668] wlan0: Selected IBSS BSSID 56:97:1a:24:11:6c based on configured SSID
> >
> > # iw dev wlan0 station dump
> > Station 00:02:ee:c0:ff:ee (on wlan0)
> > inactive time: 429 ms
> > rx bytes: 8964
> > tx bytes: 408
> > signal: 55 dBm
> > tx bitrate: 1.0 MBit/s
> >
> > I just checked the other N810 devices and every device has
> > the same mac address. And here we go... [p54spi_eeprom.h:39]
> > 0x00, 0x02, 0xee, 0xc0, 0xff, 0xee,
> >
> > The original kernel with default os shows the correct address.
> > When booting a different os with the with the original or custom
> > kernel it shows the 'coffee' address.
> > So is there a way to let the kernel receive and set the
> > correct mac address of the wlan device?
> > I guess my problem is this line:
> > [ 3685.320800] cx3110x spi2.0: loading default eeprom...
>
> You're right. I guess that easiest way to deal with it is to save blob from p54spi_eeprom.h into a file
> 3826.eeprom in the same directory as 3826.arm and fix MAC address in it, according to comments in p54spi_eeprom.h
>
> These data for sure must reside on /dev/mtdblk1 partition, but they're probably somehow coded/obfuscated.
> I couldn't find anything similar to MAC of my own n810 there.
well, this is c0ffee comes from nokia's stlc45xx-driver.
Unfortunately, they don't say how to get the device eeprom from the mtdblk1
partition. However, they certainly provide a tool stlc45xx-cal
(available at: http://stlc45xx.garage.maemo.org/ ) which can be used
to locate the eeprom's calibration data.
and by the way. If there is no mac field inside the eeprom image,
the driver will generate a random one all the time...
Regards,
Chr
>> Should be easy to copy the code into p54spi, we just never did, hoping
>> Kalle would come up with a better way, maybe request_firmware() :)
>
> I agree with you, better not to copy the sysfs interface to p54spi. I'm
> planning to experiment with the firmware interface at some point, but it
> would be great if someone else could take a look at it first.
I can take a look at it. (: But the question is... to take a look at
it to see what?
--
Max