LEAF Linux Embedded Appliance Framework

These notes (mostly) discuss running Leaf 4.x on a Soekris 4801 box, 
since there is little in the wiki.  I will add a few notes to the 
Leaf Soekris 4801 wiki page after I get permission. The good news is 
that there is not too much to say since there are no special 
problems.

I have been using Leaf and it's predecessors through various 
incarnations back to the original LRP days. I started on a repurposed 
486 machine but for quite a while have been using a Soekris 4801 box 
with Leaf on compact flash. The Soekris box has three RJ45 ports 
connected to a DSL modem as a router to a local network and a DMZ 
with a small web server. I like the Soekris box because it is small, 
silent, and has low power consumption.

Yesterday I upgraded Leaf on the Soekris from 3.X to 4.01, and then 
today upgraded again to beta 4.1 without any problems.

The Soekris box requires the natsemi module for the network ports, 
which is autodetected nicely in both 4.01 and 4.1. Therefore there 
are no special instructions required on the Soekris box different 
than would be needed on any headless box installed using a serial 
connection with the Leaf distribution on compact flash.

I used an old Canon branded Sandisk 32 MB Compact Flash card that 
came with a camera, so I  had to leave out a few files. I'm not sure 
it's a good idea to have the entire Leaf distribution on a production 
system anyway, so I might try to delete any packages I am not 
actually using, and maybe try KP's suggestion earlier today to get 
rid of extra modules.

I have a few tiny questions that aren't related to Soekris.

1. I can never get Dropbear's scp to work with a program like Winscp. 
I briefly tried, but switched to sshd and sftp, which works fine. If 
anyone knows how to get Dropbear's scp to work, I'd be interested.

2. I had recently been using an alternate resolve.conf file for 
dnsmasq because it gets overwritten by dhcp. I noticed that 
resolv.conf is now in configdb.lrp, so if I edit it with opendns 
server IPs,the changes are saved. Have I got this right, or is there 
still a danger resolv.conf is overwritten? I could always make an 
alternate resolv.conf file, put it in configdb, and have dnsmasq use 
it, which might be safer. I just want to use opendns and not my DSL 
provider's dns servers.

Thanks to the Bering-uClibc 4.x team for all their hard work!

Tim

Hi KP

on 31.07.2011 00:31, KP Kirchdoerfer wrote:
>  
> Hi;
> 
> An advantage of Bering-uClibc 4.0 over the 3.x versions is the autodetection 
> and autoloading of modules, and therefor the support of much more appliances 
> out-of-the box.
> 
...>
> For Bering-uClibc 4.1 the busybox cpio applet has been added, which is needed 
> to rebuild initrd on your LEAF box.
> 
> In short the steps are (given you have enough RAM):
> - mount your boot device and copy initrd.lrp to /tmp
> - untar initrd.lrp

No I am confused is it tar format or cpio format?

cheers

Erich

Am Montag, 1. August 2011, 16:08:56 schrieb Erich Titl:
> Hi KP
> 
> on 31.07.2011 00:31, KP Kirchdoerfer wrote:
> > Hi;
> > 
> > An advantage of Bering-uClibc 4.0 over the 3.x versions is the
> > autodetection and autoloading of modules, and therefor the support of
> > much more appliances out-of-the box.
> 
> ...>
> 
> > For Bering-uClibc 4.1 the busybox cpio applet has been added, which is
> > needed to rebuild initrd on your LEAF box.
> > 
> > In short the steps are (given you have enough RAM):
> > - mount your boot device and copy initrd.lrp to /tmp
> > - untar initrd.lrp
> 
> No I am confused is it tar format or cpio format?
You're correct - it's not a tar file.
The reference is always the documentation in the wiki and not my mail written 
from memory.

kp

Hi Tim

on 01.08.2011 01:46, Tim Wegner wrote:
> These notes (mostly) discuss running Leaf 4.x on a Soekris 4801 box, 
> since there is little in the wiki.  I will add a few notes to the 
> Leaf Soekris 4801 wiki page after I get permission. The good news is 
> that there is not too much to say since there are no special 
> problems.
> 
....

> 
> 1. I can never get Dropbear's scp to work with a program like Winscp. 
> I briefly tried, but switched to sshd and sftp, which works fine. If 
> anyone knows how to get Dropbear's scp to work, I'd be interested.
> 
> 2. I had recently been using an alternate resolve.conf file for 
> dnsmasq because it gets overwritten by dhcp. I noticed that 
> resolv.conf is now in configdb.lrp, so if I edit it with opendns 
> server IPs,the changes are saved. Have I got this right, or is there 
> still a danger resolv.conf is overwritten? I could always make an 
> alternate resolv.conf file, put it in configdb, and have dnsmasq use 
> it, which might be safer. I just want to use opendns and not my DSL 
> provider's dns servers.

If it getrs overwritten by dhcp then it will be overwritten whatever you
do to configdb. As it may well be overwritten any time during operation.

The following link
http://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/ may help to
avoid this.

cheers

Erich

Eric wrote (in response to my query about resolv.conf getting 
overwritten)

> If it gets overwritten by dhcp then it will be overwritten whatever
> you do to configdb. As it may well be overwritten any time during
> operation.
> 
> The following link
> http://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/ may help
> to avoid this.

I read the link, thanks.

My objective is to use the opendns dns servers for all the boxes on 
my local network by listing their dns server as 192.168.1.254. What I 
did before was create a file 

/etc/my_resolv.conf

containing the opendns dns servers, and then having a line in 
dnsmasq.conf as follows:

# Change this line if you want dns to get its upstream servers from
# somewhere other that /etc/resolv.conf
resolv-file=/etc/my_resolv.conf

and then put my_resolv.conf in the etc.lrp package, which was awkward 
but seemed to work.

So far my Leaf box's /etc/resolv.conf has not been overwritten. But 
since it might be, I guess I will go back to my old method, except 
that configdb.lrp provides a much handier (and more appropriate) 
place to put /etc/my_resolv.conf than etc.lrp.

Thanks for your help. Please let me know if this doesn't make sense.

Tim

Hi Folks

has anybody tried the fdisk utility in hdsupp on BuClibc 4.0? I believe
it is just broken. It appears to be a wrapper around the real thing
which depends heavily on some libraries of the build host.

cheers

Erich

Hi Folks

trying to get my router to a moderately current version I downloaded
Bering-uClibc_4.0.1_i486_syslinux_ser.tar.gz for my WRAP based board and
got bitten in initrd here

[    2.047660] Freeing unused kernel memory: 236k freed
LINUXRC: Bering - Initrd - 4.0.1 Rev 1 uClibc 0.9.30.3
[    5.988390] isofs: disagrees about version of symbol module_layout
modprobe: can't load module isofs (isofs.ko): in[    6.001773] fat:
disagrees ab
out version of symbol module_layout
valid module format
modprobe: can't load module fat (fat.ko): invalid module format
[    6.696414] scsi_mod: disagrees about version of symbol module_layout
[    6.703958] scsi_mod: disagrees about version of symbol module_layout
[    6.709917] scsi_mod: disagrees about version of symbol module_layout
[    8.053053] scsi_mod: disagrees about version of symbol module_layout
modprobe: can't load module scsi_mod (scsi_mod.ko): invalid module format
[    9.719562] scsi_mod: disagrees about version of symbol module_layout
[    9.726986] scsi_mod: disagrees about version of symbol module_layout
[    9.733003] scsi_mod: disagrees about version of symbol module_layout
[   11.193503] fat: disagrees about version of symbol module_layout

I tried the initrd.lrp and initrd_i486.lrp both with the same results.

cheers

Erich

On Tue, 2011-09-06 at 00:14 +0200, Erich Titl wrote:
> Hi Folks
> 
> trying to get my router to a moderately current version I downloaded
> Bering-uClibc_4.0.1_i486_syslinux_ser.tar.gz for my WRAP based board and
> got bitten in initrd here
> 
> [    2.047660] Freeing unused kernel memory: 236k freed
> LINUXRC: Bering - Initrd - 4.0.1 Rev 1 uClibc 0.9.30.3
> [    5.988390] isofs: disagrees about version of symbol module_layout
> modprobe: can't load module isofs (isofs.ko): in[    6.001773] fat:
> disagrees ab
> out version of symbol module_layout
> valid module format
> modprobe: can't load module fat (fat.ko): invalid module format
> [    6.696414] scsi_mod: disagrees about version of symbol module_layout
> [    6.703958] scsi_mod: disagrees about version of symbol module_layout
> [    6.709917] scsi_mod: disagrees about version of symbol module_layout
> [    8.053053] scsi_mod: disagrees about version of symbol module_layout
> modprobe: can't load module scsi_mod (scsi_mod.ko): invalid module format
> [    9.719562] scsi_mod: disagrees about version of symbol module_layout
> [    9.726986] scsi_mod: disagrees about version of symbol module_layout
> [    9.733003] scsi_mod: disagrees about version of symbol module_layout
> [   11.193503] fat: disagrees about version of symbol module_layout
> 
> I tried the initrd.lrp and initrd_i486.lrp both with the same results.
> 
> cheers
> 
> Erich

Hi Erich,

FYI, the initrd.lrp and initrd_i486.lrp files are identical (in an i486
"image"). When writing the image, all of the initrd_*.lrp files get
copied into the image (because they match the pattern *.lrp) and then
the specific initrd for the target platform gets re-copied as
initrd.lrp.

These errors are normally due to using e.g. an i686 module with an i486
image. Is there any chance you might have got a mis-matching kernel and
initrd?

davidMbrooke

Am Dienstag, 6. September 2011, 00:14:37 schrieb Erich Titl:
> Hi Folks
> 
> trying to get my router to a moderately current version I downloaded
> Bering-uClibc_4.0.1_i486_syslinux_ser.tar.gz for my WRAP based board and
> got bitten in initrd here
> 
> [    2.047660] Freeing unused kernel memory: 236k freed
> LINUXRC: Bering - Initrd - 4.0.1 Rev 1 uClibc 0.9.30.3
> [    5.988390] isofs: disagrees about version of symbol module_layout
> modprobe: can't load module isofs (isofs.ko): in[    6.001773] fat:
> disagrees ab
> out version of symbol module_layout
> valid module format
> modprobe: can't load module fat (fat.ko): invalid module format
> [    6.696414] scsi_mod: disagrees about version of symbol module_layout
> [    6.703958] scsi_mod: disagrees about version of symbol module_layout
> [    6.709917] scsi_mod: disagrees about version of symbol module_layout
> [    8.053053] scsi_mod: disagrees about version of symbol module_layout
> modprobe: can't load module scsi_mod (scsi_mod.ko): invalid module format
> [    9.719562] scsi_mod: disagrees about version of symbol module_layout
> [    9.726986] scsi_mod: disagrees about version of symbol module_layout
> [    9.733003] scsi_mod: disagrees about version of symbol module_layout
> [   11.193503] fat: disagrees about version of symbol module_layout
> 
> I tried the initrd.lrp and initrd_i486.lrp both with the same results.
> 

Hi Erich;

doublechecked (in a virtualbox environment) - I see no problems.

kp

06.09.2011 01:14, Erich Titl пишет:
> Hi Folks
>
> trying to get my router to a moderately current version I downloaded
> Bering-uClibc_4.0.1_i486_syslinux_ser.tar.gz for my WRAP based board and
> got bitten in initrd here
>
> [    2.047660] Freeing unused kernel memory: 236k freed
> LINUXRC: Bering - Initrd - 4.0.1 Rev 1 uClibc 0.9.30.3
> [    5.988390] isofs: disagrees about version of symbol module_layout
> modprobe: can't load module isofs (isofs.ko): in[    6.001773] fat:
> disagrees ab
> out version of symbol module_layout
> valid module format
> modprobe: can't load module fat (fat.ko): invalid module format
> [    6.696414] scsi_mod: disagrees about version of symbol module_layout
> [    6.703958] scsi_mod: disagrees about version of symbol module_layout
> [    6.709917] scsi_mod: disagrees about version of symbol module_layout
> [    8.053053] scsi_mod: disagrees about version of symbol module_layout
> modprobe: can't load module scsi_mod (scsi_mod.ko): invalid module format
> [    9.719562] scsi_mod: disagrees about version of symbol module_layout
> [    9.726986] scsi_mod: disagrees about version of symbol module_layout
> [    9.733003] scsi_mod: disagrees about version of symbol module_layout
> [   11.193503] fat: disagrees about version of symbol module_layout
>
> I tried the initrd.lrp and initrd_i486.lrp both with the same results.
>
> cheers
>
> Erich
Maybe you forgot to update kernel?

Hi Andrew

at 06.09.2011 11:49, Andrew wrote:
> 06.09.2011 01:14, Erich Titl пишет:
>> Hi Folks
>>
>> trying to get my router to a moderately current version I downloaded
>> Bering-uClibc_4.0.1_i486_syslinux_ser.tar.gz for my WRAP based board and
>> got bitten in initrd here
>>
>> [    2.047660] Freeing unused kernel memory: 236k freed
>> LINUXRC: Bering - Initrd - 4.0.1 Rev 1 uClibc 0.9.30.3
>> [    5.988390] isofs: disagrees about version of symbol module_layout
>> modprobe: can't load module isofs (isofs.ko): in[    6.001773] fat:
>> disagrees ab
>> out version of symbol module_layout
>> valid module format
>> modprobe: can't load module fat (fat.ko): invalid module format
>> [    6.696414] scsi_mod: disagrees about version of symbol module_layout
>> [    6.703958] scsi_mod: disagrees about version of symbol module_layout
>> [    6.709917] scsi_mod: disagrees about version of symbol module_layout
>> [    8.053053] scsi_mod: disagrees about version of symbol module_layout
>> modprobe: can't load module scsi_mod (scsi_mod.ko): invalid module format
>> [    9.719562] scsi_mod: disagrees about version of symbol module_layout
>> [    9.726986] scsi_mod: disagrees about version of symbol module_layout
>> [    9.733003] scsi_mod: disagrees about version of symbol module_layout
>> [   11.193503] fat: disagrees about version of symbol module_layout
>>
>> I tried the initrd.lrp and initrd_i486.lrp both with the same results.
>>
>> cheers
>>
>> Erich
> Maybe you forgot to update kernel?

Correct, the kernel is not in the root anymore and I boot with grub

sorry for the noise

Erich

Hi Folks

Thanks to your heads up I got the system to a state where it loads
sufficient modules to be able to talk to it and access the hardware.
Still I have a few open issues

Loading modules:
[   39.535904] nf_conntrack: disagrees about version of symbol module_layout
[   39.578250] softdog: disagrees about version of symbol module_layout
[   39.620261] 8021q: disagrees about version of symbol module_layout
[   40.202667] ath5k: disagrees about version of symbol module_layout
[   40.259703] crc32: disagrees about version of symbol module_layout

The moddb is from the same version as the kernel

STYX# cat /proc/version
Linux version 2.6.35.11-i486 (kapeka@...) (gcc version 4.4.5 (GCC)
) #1 Th
u Jul 7 22:53:55 CEST 2011

STYX# cd /lib/modules
STYX# ls | more
2.6.35.11-i486
8021q.ko
ah4.ko
ah6.ko
ahci.ko
arp_tables.ko
arpt_mangle.ko
arptable_filter.ko
ata_generic.ko
ata_piix.ko
ath5k.ko
cdrom.ko
cls_u32.ko
ehci-hcd.ko

STYX# modprobe natsemi
modprobe: can't load module crc32 (kernel/lib/crc32.ko): invalid module
format

I unpacked the module tarball and extracted a few modules from there, I
had to copy them to the flash disk with scp and then on the newly
rebooted system

LEAF Bering-uClibc STYX 2.6.35.11-i486 #1 Thu Jul 7 22:53:55 CEST 2011

Type in help if you are really lost
STYX# mount /CF
STYX# cd /CF
STYX# modprobe natsemi.ko
modprobe: can't load module crc32 (kernel/lib/crc32.ko): invalid module
format
STYX# modprobe crc32.ko
modprobe: can't load module crc32.ko (kernel/lib/crc32.ko): invalid
module forma
t

OK this takes the modules from /lib/modules, using the ones in /CF
results in

STYX# insmod crc32.ko
STYX# insmod natsemi.ko
insmod: can't insert 'natsemi.ko': unknown symbol in module, or unknown
paramete
r

This is ugly, I need the natsemi module to talk to the system.

Now this time I am sure the modules correspond to the kernel. The
modules from initrd now load correctly and crc32 loaded correctly too.

STYX# lsmod
    Not tainted
crc32 8979 0 - Live 0xb4b97000
sd_mod 20212 2 - Live 0xb4921000
pata_acpi 1908 0 - Live 0xb4910000
ata_generic 2051 0 - Live 0xb4906000
pata_sc1200 1898 1 - Live 0xb48fb000
libata 115136 3 pata_acpi,ata_generic,pata_sc1200, Live 0xb48c7000
scsi_mod 93416 2 sd_mod,libata, Live 0xb486e000
vfat 6518 1 - Live 0xb483b000
fat 34404 1 vfat, Live 0xb4825000
isofs 17067 0 - Live 0xb4809000

cheers

Erich

Am Dienstag, 6. September 2011, 19:43:04 schrieb Erich Titl:
> Hi Folks
> 
> Thanks to your heads up I got the system to a state where it loads
> sufficient modules to be able to talk to it and access the hardware.
> Still I have a few open issues
> 
> Loading modules:
> [   39.535904] nf_conntrack: disagrees about version of symbol
> module_layout [   39.578250] softdog: disagrees about version of symbol
> module_layout [   39.620261] 8021q: disagrees about version of symbol
> module_layout [   40.202667] ath5k: disagrees about version of symbol
> module_layout [   40.259703] crc32: disagrees about version of symbol
> module_layout
> 
> The moddb is from the same version as the kernel
> 
> STYX# cat /proc/version
> Linux version 2.6.35.11-i486 (kapeka@...) (gcc version 4.4.5 (GCC)
> ) #1 Th
> u Jul 7 22:53:55 CEST 2011
> 
> STYX# cd /lib/modules
> STYX# ls | more
> 2.6.35.11-i486
> 8021q.ko
> ah4.ko
> ah6.ko
> ahci.ko
> arp_tables.ko
> arpt_mangle.ko
> arptable_filter.ko
> ata_generic.ko
> ata_piix.ko
> ath5k.ko
> cdrom.ko
> cls_u32.ko
> ehci-hcd.ko
> 
> STYX# modprobe natsemi
> modprobe: can't load module crc32 (kernel/lib/crc32.ko): invalid module
> format
> 
> I unpacked the module tarball and extracted a few modules from there, I
> had to copy them to the flash disk with scp and then on the newly
> rebooted system
> 
> LEAF Bering-uClibc STYX 2.6.35.11-i486 #1 Thu Jul 7 22:53:55 CEST 2011
> 
> Type in help if you are really lost
> STYX# mount /CF
> STYX# cd /CF
> STYX# modprobe natsemi.ko
> modprobe: can't load module crc32 (kernel/lib/crc32.ko): invalid module
> format
> STYX# modprobe crc32.ko
> modprobe: can't load module crc32.ko (kernel/lib/crc32.ko): invalid
> module forma
> t
> 
> OK this takes the modules from /lib/modules, using the ones in /CF
> results in
> 
> STYX# insmod crc32.ko
> STYX# insmod natsemi.ko
> insmod: can't insert 'natsemi.ko': unknown symbol in module, or unknown
> paramete
> r
> 
> This is ugly, I need the natsemi module to talk to the system.
> 
> Now this time I am sure the modules correspond to the kernel. The
> modules from initrd now load correctly and crc32 loaded correctly too.
> 
> STYX# lsmod
>     Not tainted
> crc32 8979 0 - Live 0xb4b97000
> sd_mod 20212 2 - Live 0xb4921000
> pata_acpi 1908 0 - Live 0xb4910000
> ata_generic 2051 0 - Live 0xb4906000
> pata_sc1200 1898 1 - Live 0xb48fb000
> libata 115136 3 pata_acpi,ata_generic,pata_sc1200, Live 0xb48c7000
> scsi_mod 93416 2 sd_mod,libata, Live 0xb486e000
> vfat 6518 1 - Live 0xb483b000
> fat 34404 1 vfat, Live 0xb4825000
> isofs 17067 0 - Live 0xb4809000
> 
> cheers
> 
> Erich

Erich;

Pls try to load bitrev.ko before natsemi.ko.

hth
kp

Hi KP

on 06.09.2011 20:55, KP Kirchdoerfer wrote:
> 
> Erich;
> 
> Pls try to load bitrev.ko before natsemi.ko.

LEAF Bering-uClibc 4.0.1 Rev 1 uClibc 0.9.30.3  STYX ttyS0
STYX login: root
LEAF Bering-uClibc STYX 2.6.35.11-i486 #1 Thu Jul 7 22:53:55 CEST 2011

Type in help if you are really lost
STYX# modprobe bitrev.ko
modprobe: module bitrev.ko not found in modules.dep

Althoug in BuC 4.0 there is no bitrev module loaded and the natsemi
driver still works. I am using a double boot installation on that piece
of hardware. The previous version is always used to load the current
version.

But indeed it helps

TYX login: root
LEAF Bering-uClibc STYX 2.6.35.11-i486 #1 Thu Jul 7 22:53:55 CEST 2011

Type in help if you are really lost
STYX# mount /CF
STYX# ls
STYX# cd /CF
STYX# cp crc32.ko /lib/modules/kernel/lib
STYX# cp bitrev.ko /lib/modules/kernel/lib
STYX# modprobe bitrev
modprobe: module bitrev not found in modules.dep
STYX# insmod ./bitrev.ko
STYX# insmod ./crc32.ko
STYX# insmod ./natsemi.ko

after saving moddb.lrp a reboot yields the following

Loading modules:
[   39.780353] nf_conntrack: disagrees about version of symbol module_layout
[   39.823154] softdog: disagrees about version of symbol module_layout
[   39.865226] 8021q: disagrees about version of symbol module_layout
[   40.448808] ath5k: disagrees about version of symbol module_layout
[   40.615875] natsemi dp8381x driver, version 2.1, Sept 11, 2006
[   40.615925]   originally by Donald Becker <becker@...>
[   40.615965]   2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
[   40.629799] natsemi eth0: NatSemi DP8381[56] at 0x80040000
(0000:00:0e.0), 00
:0d:b9:04:6e:d8, IRQ 10, port TP.

A small step for a man but a big step towards connectivity. Now all
that's lacking is all the rest of the unloaded modules.

STYX# modprobe 8021q
modprobe: can't load module 8021q (8021q.ko): invalid module format
STYX# modprobe nf_conntrack
modprobe: can't load module nf_conntrack (nf_conntrack.ko): invalid
module format
STYX# modprobe ath5k
modprobe: can't load module ath5k
(kernel/drivers/net/wireless/ath5k/ath5k.ko): invalid module format

according to modules.dep none of the above depend on anything.

Something in the dependencies has changed dramatically. from 4.0 to 4.01

cheers

Erich

Am Dienstag, 6. September 2011, 22:59:21 schrieb Erich Titl:
> Hi KP
> 
> on 06.09.2011 20:55, KP Kirchdoerfer wrote:
> > Erich;
> > 
> > Pls try to load bitrev.ko before natsemi.ko.
> 
> LEAF Bering-uClibc 4.0.1 Rev 1 uClibc 0.9.30.3  STYX ttyS0
> STYX login: root
> LEAF Bering-uClibc STYX 2.6.35.11-i486 #1 Thu Jul 7 22:53:55 CEST 2011
> 
> Type in help if you are really lost
> STYX# modprobe bitrev.ko
> modprobe: module bitrev.ko not found in modules.dep
> 
> Althoug in BuC 4.0 there is no bitrev module loaded and the natsemi
> driver still works. I am using a double boot installation on that piece
> of hardware. The previous version is always used to load the current
> version.
> 
> But indeed it helps
> 
> TYX login: root
> LEAF Bering-uClibc STYX 2.6.35.11-i486 #1 Thu Jul 7 22:53:55 CEST 2011
> 
> Type in help if you are really lost
> STYX# mount /CF
> STYX# ls
> STYX# cd /CF
> STYX# cp crc32.ko /lib/modules/kernel/lib
> STYX# cp bitrev.ko /lib/modules/kernel/lib
> STYX# modprobe bitrev
> modprobe: module bitrev not found in modules.dep
> STYX# insmod ./bitrev.ko
> STYX# insmod ./crc32.ko
> STYX# insmod ./natsemi.ko
> 
> after saving moddb.lrp a reboot yields the following
> 
> Loading modules:
> [   39.780353] nf_conntrack: disagrees about version of symbol
> module_layout [   39.823154] softdog: disagrees about version of symbol
> module_layout [   39.865226] 8021q: disagrees about version of symbol

Note: softdog and 8021q just loads out of the box in my test environment 
(running Bering-uClibc 486 syslinux serial in virtualbox)



> Something in the dependencies has changed dramatically. from 4.0 to 4.01

There has been no changes which justifies such an assumption.
See: 
http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_-
_Changelog#Changes_between_4.0_and_4.0.1

I assume you have mixed up versions. 

Can you summarize the steps you've made trying to update?
kp

Hi KP

at 06.09.2011 23:26, KP Kirchdoerfer wrote:
..
> 
> I assume you have mixed up versions. 

An assumption as good as any other :-)

> 
> Can you summarize the steps you've made trying to update?

To start with I have a box which will start ftom either partition 0 or 1
using BuC 4.0.whatever. The bootloader is GRUB and I have 2 entries in
the boot menu allowing me to choose. This enables me to overload an
installation with fallback to the previous version should the kernel not
load.

1) Start BuC 4.0 from partition 1 on the box
2) mount partition 0 on the Compact Flash
3) clean the partition with the exception of /CF/boot
4) copy kernel, initrd and the most important modules from the new
tarball to partition 0
5) copy leaf.cfg from partition 1 to partition 0
5) start and test the installation

for your reference, these are the contents of menu.lst

#Useful extras:
serial --speed=38400
terminal serial
#password --md5 $1TH$8O$%w0$d&^20R4ff&^*a2K/oUm.

root (hd0,0)
timeout 5
default saved
fallback 0

# For booting Linux

title LEAF Styx Version 4.01
  root (hd0,0)
  kernel /linux console=ttyS0,38400 init=/linuxrc rw root=/dev/ram0
boot=/dev/sda1:vfat \
  reboot=bios \
  PKGPATH=/dev/sda1:vfat initrd=initrd.lrp \
  LEAFCFG=/dev/sda1:vfat \
  syst_size=15M
  savedefault

initrd /initrd.lrp

title LEAF Styx Version 4.0
  root (hd0,1)
  kernel /linux console=ttyS0,38400 init=/linuxrc rw root=/dev/ram0
boot=/dev/sda2:vfat \
  reboot=bios \
  PKGPATH=/dev/sda2:vfat initrd=initrd.lrp \
  LEAFCFG=/dev/sda2:vfat \
  LRP=root,etc,local,config syst_size=12M log_size=10M
  savedefault

initrd /initrd.lrp

STYX# cat /proc/version
Linux version 2.6.35.11-i486 (kapeka@...) (gcc version 4.4.5 (GCC)
) #1 Thu Jul 7 22:53:55 CEST 2011

Here are the sha1 hashes of the most important parts

STYX# cd /CF
STYX# sha1sum *
2bab74ca7bcdf56b067c95a2458f030b3628400c  bitrev.ko
94f540568b83ac86fabd1a386344e50d3a9ee784  config.lrp
41997ae6e72450b1e48f0697c0ea4495922f959c  configdb.lrp
ef663dd8f28ceaea0c467d65487ddeb7822fc0d9  crc32.ko
4bde1bd2b6e5b6dee5261a43ef298ba0d5ea6a47  dhcpcd.lrp
5d6ebb323efe8ac62104ad811b6317d1cbbf70ae  dirstruc.lrp
4ea89dc9ae6c894fe32ce3bbfebd2edc14759bf7  dnscache.lrp
c80fee2ff3cd93cc025c81e23344c3e1ee70b2e3  elvis.lrp
3165fe474a53d493cefc0ad4906973eaaaa73094  etc.lrp
9e9d322ecb83d372c43da716e04304e04ffe0a50  initrd.lrp
358874257f39fe651da420c168009e1182e843b0  iptables.lrp
55b32d6ccf14e107e0dd1681a39eb85bb90b429f  leaf.cfg
2b6d8007bc9f054eeb6fa83d21e78bdb967b4eef  libcrpto.lrp
9742d60b61322e38a2b9edf693b1796b266ff368  liblzo.lrp
4dadd96c653f452e2c4c8b26123950461fbe7b98  libm.lrp
563f3f66783f9e03343ac2d5c1126f4181d959f2  libpcap.lrp
7c39fcc4464010304d2e7736924024fade2e26ef  libssl.lrp
b7581504adf6460993771f0fc0fbae8e2a9372ea  libz.lrp
37c5c1f1316d63ee1e8da19f9eb0f51a65af22a9  linux
df10a3dc89cc96021a55eb2039d016317d03af1b  local.lrp
d089181f9b6a3258fbe8b757ff93d24c0e598005  mhttpds.lrp
d738daa32f19528933ec81cfaf37490e8d692229  moddb.lrp
a4399749da316a482f448db88f34e0ac44a28649  modules.lrp
4f741b08af81c3bc7ad5a767a9c3404989e2ca99  natsemi.ko
c36314366c57642176ecf60f58df88f9068e528a  ncurses.lrp
c680c3b4fbb528805a0dab9c2c36266e142d600e  ntpd.lrp
794f3dd8384f9528ee026bcd966718ca94bb8369  perl.lrp
b2d0d84298cd22c0c0f103bd46d628e01dd330d8  root.lrp
57a2aa3bd84ae0d0ba821b5230e275589275793b  shorwall.lrp
1a186d41a4b0fd0f4d2bad135ab67867461ce338  sshd.lrp
0df92b9e35546f92fab326e819b9cfdcb4743493  tcpdump.lrp
fff5f6d5c163b31fb46e348532200d8f486be0d5  webconf.lrp
f80da4713447c7657edb60c7b4e7f098c60dd30b  wireless.lrp

of course moddb is overwritten as it holds now the bitrev and crc32 modules.

cheers

Erich

On 9/6/2011 13:43, Erich Titl wrote:
> [   40.202667] ath5k: disagrees about version of symbol module_layout
> [   40.259703] crc32: disagrees about version of symbol module_layout
I also had this problem before but don't remember how I fixed exactly!

I am using gurb as well. Except I have gurb in /dev/[hs]da1 (32M), leaf 
v4.1-b2 in /dev/[sh]da2 (64M) and leaf v3.1.x in /dev/[sh]da3, etc. I 
also use ext2 instead of vfat and to do that I had to add mbcache.ko and 
ext2.ko to initrd.lrp. As I am using the alix MB,
# cat /proc/version
Linux version 2.6.35.14-geode (kapeka@...) \
(gcc version 4.4.5 (GCC) ) #1 Tue Aug 30 22:19:59 CEST 2011

On 9/7/2011 02:55, Erich Titl wrote:
> title LEAF Styx Version 4.01
>   root (hd0,0)
>   kernel /linux console=ttyS0,38400 init=/linuxrc rw root=/dev/ram0 \

For version 4.x.x, the last line above should be:
kernel /syslinux/linux rw root=/dev/ram0 \
   LEAFCFG=/dev/sda2:ext2 initrd=initrd.lrp \
   console=ttyS0,38400n8 console=tty0

For version 3.x.x, the last line above should be:
kernel /linux init=/linuxrc rw root=/dev/ram0 \
   LEAFCFG=/dev/hda3:ext2 initrd=initrd.lrp \
   console=ttyS0,38400n8 console=tty0

I think that should fix it? Please let us know.
Cheers, Kwon

On 9/6/2011 13:43, Erich Titl wrote:
> [   40.202667] ath5k: disagrees about version of symbol module_layout
> [   40.259703] crc32: disagrees about version of symbol module_layout
I also had this problem before but don't remember how I fixed exactly!

I am using gurb as well. Except I have gurb in /dev/[hs]da1 (32M), leaf 
v4.1-b2 in /dev/[sh]da2 (64M) and leaf v3.1.x in /dev/[sh]da3, etc. I 
also use ext2 instead of vfat and to do that I had to add mbcache.ko and 
ext2.ko to initrd.lrp. As I am using the alix MB,
# cat /proc/version
Linux version 2.6.35.14-geode (kapeka@...) \
(gcc version 4.4.5 (GCC) ) #1 Tue Aug 30 22:19:59 CEST 2011

On 9/7/2011 02:55, Erich Titl wrote:
> title LEAF Styx Version 4.01
>   root (hd0,0)
>   kernel /linux console=ttyS0,38400 init=/linuxrc rw root=/dev/ram0 \

For version 4.x.x, the last line above should be:
kernel /syslinux/linux rw root=/dev/ram0 \
   LEAFCFG=/dev/sda2:ext2 initrd=initrd.lrp \
   console=ttyS0,38400n8 console=tty0

For version 3.x.x, the last line above should be:
kernel /linux init=/linuxrc rw root=/dev/ram0 \
   LEAFCFG=/dev/hda3:ext2 initrd=initrd.lrp \
   console=ttyS0,38400n8 console=tty0

I think that should fix it? Please let us know.
Cheers, Kwon

Hi Folks

on 07.09.2011 17:13, n22e113 wrote:
> On 9/6/2011 13:43, Erich Titl wrote:
....
> 
> For version 3.x.x, the last line above should be:
> kernel /linux init=/linuxrc rw root=/dev/ram0 \
>    LEAFCFG=/dev/hda3:ext2 initrd=initrd.lrp \
>    console=ttyS0,38400n8 console=tty0
> 
> I think that should fix it? Please let us know.
> Cheers, Kwon

You guys were all correct.
The real culprit was a fouled up PKGPATH variable in leaf.cfg, which
pointed to a bad location. Too many parameters in too many places :-(

I will report my progress

Thanks

Erich

Hi folks

after my struggle with the wrong path I got to my next hurdle.

Has anyone successfully loaded the atheros wireless driver ath5k?

STYX# modprobe ath5k
modprobe: can't load module cfg80211
(kernel/drivers/net/wireless/cfg80211.ko): unknown symbol in module, or
unknown parameter

So it depends on cfg80211, but there is one or more dependencies which I
could not fathom.

Thanks

Erich

Am Donnerstag, 8. September 2011, 00:18:40 schrieb Erich Titl:
> Hi folks
> 
> after my struggle with the wrong path I got to my next hurdle.
> 
> Has anyone successfully loaded the atheros wireless driver ath5k?
> 
> STYX# modprobe ath5k
> modprobe: can't load module cfg80211
> (kernel/drivers/net/wireless/cfg80211.ko): unknown symbol in module, or
> unknown parameter
> 
> So it depends on cfg80211, but there is one or more dependencies which I
> could not fathom.
> 

You may try 
lrcfg -> 'f) Find & load modules for hardware'

Loading the follwoing modules works for me:
arc4.ko
ecb.ko
mac802111.ko
cfg80211.ko
rfkill.ko
led-class.ko
ath.ko
ath5k.ko

kp

Hi Folks

A follow up to my moddb woes. Trying to remove all unneeded maodules
from my moddb I wanted some kind of automatic removal

Here is a first attempt, use at your own risk...

cd /lib/modules
find -type f > /tmp/modules.installed
lsmod > /tmp/modules.loaded

for i in `cat /tmp/modules.installed`
do

MODULE_FILE=`basename $i .ko`
grep $MODULE_FILE modules.loaded > /dev/null
STATE=$?
[ $STATE -ne 0 ] && echo $i is NOT loaded && echo $i can be removed
[ $STATE -ne 0 ] && rm $i
done

I ended up with the following

Creating moddb.lrp Please wait: -
New Package:
-rw-r--r--    1 root     root        474053 Sep  8 14:53 /tmp/moddb.lrp
Old Package:
-rwxr-xr-x    1 root     root       1224422 Sep  8 11:15
/var/lib/lrpkg/mnt0/moddb.lrp

the necessary space for the root directory was reduced by 30%

the content in /lib/modules was reduced to

STYX# find -type f
./ipv6.ko
./kernel/fs/isofs/isofs.ko
./kernel/fs/fat/vfat.ko
./kernel/fs/fat/fat.ko
./kernel/lib/bitrev.ko
./kernel/lib/crc32.ko
./kernel/crypto/ecb.ko
./kernel/crypto/arc4.ko
./kernel/net/netfilter/x_tables.ko
./kernel/net/netfilter/xt_time.ko
./kernel/net/netfilter/xt_tcpudp.ko
./kernel/net/netfilter/xt_tcpmss.ko
./kernel/net/netfilter/xt_recent.ko
./kernel/net/netfilter/xt_realm.ko
./kernel/net/netfilter/xt_pkttype.ko
./kernel/net/netfilter/xt_owner.ko
./kernel/net/netfilter/xt_multiport.ko
./kernel/net/netfilter/xt_mark.ko
./kernel/net/netfilter/xt_length.ko
./kernel/net/netfilter/xt_iprange.ko
./kernel/net/netfilter/xt_helper.ko
./kernel/net/netfilter/xt_hashlimit.ko
./kernel/net/netfilter/xt_conntrack.ko
./kernel/net/netfilter/xt_connmark.ko
./kernel/net/netfilter/xt_connlimit.ko
./kernel/net/netfilter/xt_comment.ko
./kernel/net/netfilter/xt_TPROXY.ko
./kernel/net/netfilter/xt_NFQUEUE.ko
./kernel/net/netfilter/xt_CLASSIFY.ko
./kernel/net/netfilter/nf_tproxy_core.ko
./kernel/net/netfilter/nf_conntrack.ko
./kernel/net/ipv4/netfilter/nf_nat.ko
./kernel/net/ipv4/netfilter/nf_defrag_ipv4.ko
./kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko
./kernel/net/ipv4/netfilter/iptable_raw.ko
./kernel/net/ipv4/netfilter/iptable_nat.ko
./kernel/net/ipv4/netfilter/iptable_mangle.ko
./kernel/net/ipv4/netfilter/iptable_filter.ko
./kernel/net/ipv4/netfilter/ipt_addrtype.ko
./kernel/net/ipv4/netfilter/ipt_REJECT.ko
./kernel/net/ipv4/netfilter/ipt_LOG.ko
./kernel/net/ipv4/netfilter/ip_tables.ko
./kernel/net/mac80211/mac80211.ko
./kernel/net/rfkill/rfkill.ko
./kernel/arch/x86/scx200.ko
./kernel/drivers/scsi/sd_mod.ko
./kernel/drivers/scsi/scsi_mod.ko
./kernel/drivers/ata/libata.ko
./kernel/drivers/ata/ata_generic.ko
./kernel/drivers/ata/pata_sc1200.ko
./kernel/drivers/ata/pata_acpi.ko
./kernel/drivers/watchdog/scx200_wdt.ko
./kernel/drivers/net/8021q/8021q.ko
./kernel/drivers/net/natsemi.ko
./kernel/drivers/net/wireless/cfg80211.ko
./kernel/drivers/net/wireless/ath/ath.ko
./kernel/drivers/net/wireless/ath/ath5k/ath5k.ko

please note the structured aproach :-)

cheers

Erich

Am Donnerstag, 8. September 2011, 15:34:44 schrieb Erich Titl:
> Hi Folks
> 
> A follow up to my moddb woes. Trying to remove all unneeded maodules
> from my moddb I wanted some kind of automatic removal
> 
> Here is a first attempt, use at your own risk...
> 
> cd /lib/modules
> find -type f > /tmp/modules.installed
> lsmod > /tmp/modules.loaded
> 
> for i in `cat /tmp/modules.installed`
> do
> 
> MODULE_FILE=`basename $i .ko`
> grep $MODULE_FILE modules.loaded > /dev/null
> STATE=$?
> [ $STATE -ne 0 ] && echo $i is NOT loaded && echo $i can be removed
> [ $STATE -ne 0 ] && rm $i
> done
> 
> I ended up with the following
> 
> Creating moddb.lrp Please wait: -
> New Package:
> -rw-r--r--    1 root     root        474053 Sep  8 14:53 /tmp/moddb.lrp
> Old Package:
> -rwxr-xr-x    1 root     root       1224422 Sep  8 11:15
> /var/lib/lrpkg/mnt0/moddb.lrp
> 
> the necessary space for the root directory was reduced by 30%
> 
> the content in /lib/modules was reduced to
> 
> STYX# find -type f
> ./ipv6.ko
> ./kernel/fs/isofs/isofs.ko
> ./kernel/fs/fat/vfat.ko
> ./kernel/fs/fat/fat.ko
> ./kernel/lib/bitrev.ko
> ./kernel/lib/crc32.ko
> ./kernel/crypto/ecb.ko
> ./kernel/crypto/arc4.ko
> ./kernel/net/netfilter/x_tables.ko
> ./kernel/net/netfilter/xt_time.ko
> ./kernel/net/netfilter/xt_tcpudp.ko
> ./kernel/net/netfilter/xt_tcpmss.ko
> ./kernel/net/netfilter/xt_recent.ko
> ./kernel/net/netfilter/xt_realm.ko
> ./kernel/net/netfilter/xt_pkttype.ko
> ./kernel/net/netfilter/xt_owner.ko
> ./kernel/net/netfilter/xt_multiport.ko
> ./kernel/net/netfilter/xt_mark.ko
> ./kernel/net/netfilter/xt_length.ko
> ./kernel/net/netfilter/xt_iprange.ko
> ./kernel/net/netfilter/xt_helper.ko
> ./kernel/net/netfilter/xt_hashlimit.ko
> ./kernel/net/netfilter/xt_conntrack.ko
> ./kernel/net/netfilter/xt_connmark.ko
> ./kernel/net/netfilter/xt_connlimit.ko
> ./kernel/net/netfilter/xt_comment.ko
> ./kernel/net/netfilter/xt_TPROXY.ko
> ./kernel/net/netfilter/xt_NFQUEUE.ko
> ./kernel/net/netfilter/xt_CLASSIFY.ko
> ./kernel/net/netfilter/nf_tproxy_core.ko
> ./kernel/net/netfilter/nf_conntrack.ko
> ./kernel/net/ipv4/netfilter/nf_nat.ko
> ./kernel/net/ipv4/netfilter/nf_defrag_ipv4.ko
> ./kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko
> ./kernel/net/ipv4/netfilter/iptable_raw.ko
> ./kernel/net/ipv4/netfilter/iptable_nat.ko
> ./kernel/net/ipv4/netfilter/iptable_mangle.ko
> ./kernel/net/ipv4/netfilter/iptable_filter.ko
> ./kernel/net/ipv4/netfilter/ipt_addrtype.ko
> ./kernel/net/ipv4/netfilter/ipt_REJECT.ko
> ./kernel/net/ipv4/netfilter/ipt_LOG.ko
> ./kernel/net/ipv4/netfilter/ip_tables.ko
> ./kernel/net/mac80211/mac80211.ko
> ./kernel/net/rfkill/rfkill.ko
> ./kernel/arch/x86/scx200.ko
> ./kernel/drivers/scsi/sd_mod.ko
> ./kernel/drivers/scsi/scsi_mod.ko
> ./kernel/drivers/ata/libata.ko
> ./kernel/drivers/ata/ata_generic.ko
> ./kernel/drivers/ata/pata_sc1200.ko
> ./kernel/drivers/ata/pata_acpi.ko
> ./kernel/drivers/watchdog/scx200_wdt.ko
> ./kernel/drivers/net/8021q/8021q.ko
> ./kernel/drivers/net/natsemi.ko
> ./kernel/drivers/net/wireless/cfg80211.ko
> ./kernel/drivers/net/wireless/ath/ath.ko
> ./kernel/drivers/net/wireless/ath/ath5k/ath5k.ko
> 
> please note the structured aproach :-)

Nice.

But have you rebooted in the meantime - I'm almost shure you'll get some 
hardware drivers reinstalled that live in initrd.

kp

at 08.09.2011 15:49, KP Kirchdoerfer wrote:
> 
> But have you rebooted in the meantime - I'm almost shure you'll get some 
> hardware drivers reinstalled that live in initrd.

Of course, but I usually take one step after the other.

Cheers

Erich

Hi Folks

In my attempt to build a wifi connected router I am facing a little
problem definig my wifi based uplink

right now I have defined

#auto wlan0
iface wlan0 inet dhcp

As soon as I call ifup on the interface, dhcp tries to get an address
and waits for the carrier, e.g. the prompt does not return. Basically
that is what I want, only I would like to scan for available networks
first, then select a certain network, get connected and then start the
dhcp daemon.

Is this feasible at all with ifup or do I have to write my own?

Thanks

Erich

On 09/11/2011 02:09 PM, Erich Titl wrote:
> Hi Folks
>
> In my attempt to build a wifi connected router I am facing a little
> problem definig my wifi based uplink
>
> right now I have defined
>
> #auto wlan0
> iface wlan0 inet dhcp
>
> As soon as I call ifup on the interface, dhcp tries to get an address
> and waits for the carrier, e.g. the prompt does not return. Basically
> that is what I want, only I would like to scan for available networks
> first, then select a certain network, get connected and then start the
> dhcp daemon.
>
> Is this feasible at all with ifup or do I have to write my own?
>
> Thanks
>
> Erich
Yes, use map and a script to scan for different conditions.

then you can use
ifup wlan0=wlan0-net1
ifup wlan0=wlan0-net2

or just
ifup wlan0

see

http://manpages.ubuntu.com/manpages/hardy/man5/interfaces.5.html

https://help.ubuntu.com/community/WifiDocs/WiFiHowTo#Automatic_WLAN_Picker_Script

Remember wpa_supplicant.conf

/Per

Hi Per

at 11.09.2011 17:25, Per Sjoholm wrote:
> On 09/11/2011 02:09 PM, Erich Titl wrote:
>> Hi Folks
>>
...
> Yes, use map and a script to scan for different conditions.
> 
> then you can use
> ifup wlan0=wlan0-net1
> ifup wlan0=wlan0-net2

> 
> or just
> ifup wlan0
> 
> see
> 
> http://manpages.ubuntu.com/manpages/hardy/man5/interfaces.5.html
> 
> https://help.ubuntu.com/community/WifiDocs/WiFiHowTo#Automatic_WLAN_Picker_Script
> 
> Remember wpa_supplicant.conf

I have some difficulties understanding its settings.

For example, I can scan available APs in the vicinity. Some are WEP
protected and some are WPA protected. Will wpa_supplicant cater for both
protection schemes?

STYX# wpa_cli scan_results
Selected interface 'wlan0'
bssid / frequency / signal level / flags / ssid
e0:91:f5:60:93:ae       2437    189
[WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP] Linda1968
00:25:9c:09:aa:12       2452    184
[WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP] scoobly
74:ea:3a:d1:45:c0       2462    171     [WPA2-PSK-CCMP] elektrosmog.ch
c0:3f:0e:2f:52:34       2412    166
[WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP] cjung
34:08:04:dc:1c:ec       2412    164
[WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP] Skynet
00:24:c9:63:5d:60       2462    162
[WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP] sol-99815
bc:ae:c5:ea:ca:a3       2422    159     [WPA2-PSK-CCMP] Terminator
00:21:04:20:05:5d       2437    171     [WEP]   Home
80:c6:ab:1a:81:f3       2462    159     [WEP]   rigo

Now to associate with a certain AP I would need to set its attributes

STYX# wpa_cli list_networks
Selected interface 'wlan0'
network id / ssid / bssid / flags
0       scoobly any

Here I was already capable of setting the desired network ssid

STYX# wpa_cli set_network 0 password "xxxxxxxxxx"
Selected interface 'wlan0'
FAIL

but.....

STYX# wpa_cli
wpa_cli v0.5.11
Copyright (c) 2004-2008, Jouni Malinen <j@...> and contributors

This program is free software. You can distribute it and/or modify it
under the terms of the GNU General Public License version 2.

Alternatively, this software may be distributed under the terms of the
BSD license. See README and COPYING for more details.

Selected interface 'wlan0'

Interactive mode

> set_network 0 password "xxxxxxxxxx"
OK

So not all attributes may be set on the command line. This makes it
rather difficult to configure it.

Now following a save_config I have this minimalistic setting

STYX# cat wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
update_config=1

network={
        ssid="scoobly"
        key_mgmt=NONE
        password="xxxxxxxxxx"
}

I cannot see though the ssid being set on the interface

STYX# iwconfig wlan0
calling iwconfig
wlan0     IEEE 802.11abg  ESSID:"default"
          Mode:Managed  Frequency:2.437 GHz  Access Point: Not-Associated
          Tx-Power=20 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

Neither is there an association

There is a hole in my understanding of the interaction of all these bits
and pieces.

cheers

Erich

Hi Folks

I made considerable progress in my attempt to get the wifi client up and
running.
I found a simple network definition for wpasupplicant which would
sufficiently describe the connection to my WRT54GH

STYX# cat /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
update_config=1

network={
        ssid="scoobly"
        psk="xxxxxxxxxxx"
}

and here is the status

STYX# wpa_cli status
Selected interface 'wlan0'
bssid=00:25:9c:09:aa:12
ssid=scoobly
id=0
pairwise_cipher=CCMP
group_cipher=TKIP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.217.100

The IP address is obtained using dhcp, so I assume the most basic
connectivity is there.

When I try top ping the AP then all I see on the interface is arp requests

STYX# tcpdump -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:17:07.791504 ARP, Request who-has 192.168.217.1 tell 192.168.217.100,
length 28
20:17:08.793505 ARP, Request who-has 192.168.217.1 tell 192.168.217.100,
length 28
20:17:10.793533 ARP, Request who-has 192.168.217.1 tell 192.168.217.100,
length 28
20:17:11.795505 ARP, Request who-has 192.168.217.1 tell 192.168.217.100,
length 28
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

So it appears that packets are passed at a certain moment.

If I disconnect and reassociate the following can be seen

STYX# tcpdump -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:19:13.339501 ARP, Request who-has 192.168.217.1 tell 192.168.217.100,
length 28
20:19:36.559619 EAPOL key (3) v1, len 117
20:19:36.562865 EAPOL key (3) v1, len 117
20:19:36.576570 EAPOL key (3) v1, len 175
20:19:36.579198 EAPOL key (3) v1, len 95
20:19:36.666855 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 00:0b:6b:36:bb:cd (oui Unknown), length 321
20:19:37.770728 IP 192.168.217.1.bootps > 255.255.255.255.bootpc:
BOOTP/DHCP, Reply, length 300
20:19:37.777122 ARP, Request who-has 192.168.217.100 tell 0.0.0.0, length 28

It appears that the connection comes up fine and dhcp takes place. Still
I cannot reach the AP.

When I enter the arp address manually I can see ICMP echos leaving
through wlan0, but no reply. It feels like the AP does not want to talk
to me.

Using my windoze laptop with the same AP I can ping without a problem :-(

Any ideas?

Thanks

Erich