Firmware compatible to Wireless Space?

[fvdw]

think a found the problem, a type error in the code, as result two time the same function was called for initializing the ethernet interfaces, although with some different data but it tried to register it at same place. This kernel should initialize both interfaces. Please check it out

[coelhonet]

Hi!

Just tested. Sounds eth0 found but no static IP set. I'll try later to put a DHCP Server on my notebook and restest.

Log attached.

Thanks!

[coelhonet]

So, some updates on DHCP Server testing.

I setup a DHCP Server on my notebook, starting to lease IPs from 192.168.1.252 up to 192.168.1.254. No other device was added to the network to get a lease for 192.168.1.252 (which one is what I configured on fvdw-sl-console and also I have set on Wireless Space original LaCie firmware).

No matter which port I put network cable into, none of them get a DHCP lease from my DHCP Server.

Then, I decided to turn Wireless Space off and I put another device on same network cable and I got a DHCP lease.

Thanks!

[fvdw]

:punk :woohoo
the problem is solved and both the network interface seem to work :mrgreen:
see this part of the console output:

Code: Select all

[    2.598941] Register Driver 'mv643xx_eth'
[    2.603084] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[    2.610098] libphy: mv643xx_eth smi: probed
[    2.614552] Register Driver 'mv643xx_eth_port'
[    2.620281] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:d0:4b:8f:94:aa
[    2.630192] mv643xx_eth_port mv643xx_eth_port.1 eth1: port 0 with MAC address 00:d0:4b:8f:93:e2


We just have established basic support for the wireless space.
You should have now access with the telnet client when the standalone kernel is running

Please note that the standalone is a special kernel that runs fully from ram and assigns itself two static ip's 192.168.1.252 and 192.1681.0.252
It also tries to get a dynamic one from a dhcp server, but in any case the two static should work.
As the standalone kernel runs fully from RAM it doesn't even need a disk installed (but needs to be loaded using the fvdw-sl interface).
From the output in tle log it seems you have loaded the kernel differently. This won't work properly as this standalone kernel is not designed for normal operation, it is specially for diagnose and trouble shooting if the the normal kernel and firmware doesn't boot properly. Also it can be use to install the fvdw-sl firmware.


The next step is to make a normal kernel that will be loaded from disk at boot and will also load the firmware and make the wireless space independent on loading of a kernel via the fvdw-sl console. I will compile that kernel this evening.
With the standalone kernel running you can now use the feature to install the fvdw-sl firmware using the webinterface.
However you will need a normal kernel corrected for the wireless space to let the firmware run normally.
I will compile this this evening. When I post it I will also post the instruction how to get it installed.

[fvdw]

ok the installation package containing the normal kernel and adapted firmware (version 15-3) can be found here

viewtopic.php?f=7&t=1987

[fvdw]

files were temporarily off-line for double check on possible wrong content, but they are ok and again available for download

[coelhonet]

Hey!

This can sound stupid, but I just cannot connect via telnet after fvdw is loaded. Console just sends "Sending discover..." to stdout and I couldn't find a way to stop that and check what real IPs where set on interfaces.

I have a wired cable from my notebook (192.168.1.251, static IP) to Wireless Space (192.168.1.252, static IP on LaCie firmware, before booting into fvdw).

I know that I should be one step after (from what you provided), but I couldn't make it.

Any idea on what I can do?

Thanks!

[fvdw]

the standalone kernel should assigns itself 2 static ip addresses 192.168.1.252 and 192.168.0.252. Furthermore it tries to as sign's itself a dynamic one, for that it send discovers for a dhcp server to pick up, that will continue until a dhcp server answer's, it will make 5 tries to get the lease. Then it aborts.
However the two static ip addresses should always be available as they are assigned manually.
In your case I see this in the serial console output.

Setting IP address 0.0.0.0 on eth0

I think this is the output of the dhcp client as afterwards the send discover message's are comming.
After trying 5 times the dhcp client gives up (so you should see only 5 times "discover send"
The these messages should come

Code: Select all

prepare telnet access
start telnet
make dev node for buttons...
mkdir: can't create directory '/dev/input': File exists
mknod: /dev/input/event0: File exists
start buttons control daemon
buttons-nwsp2 daemon started
pass control to sh shell
/bin/sh: can't access tty; job control turned off
~ #

I don't see this in the serial console you posted ??


That something is not is 100% ok is also be indicated by this part of the console output:

Code: Select all

[    3.193127] netpoll: netconsole: local port 6666
[    3.197828] netpoll: netconsole: local IPv4 address 192.168.1.252
[    3.203895] netpoll: netconsole: interface 'eth0'
[    3.208625] netpoll: netconsole: remote port 6666
[    3.213315] netpoll: netconsole: remote IPv4 address 192.168.1.251
[    3.219559] netpoll: netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
[    3.226444] netpoll: netconsole: device eth0 not up yet, forcing it
[    3.233308] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 10 Mb/s, half duplex, flow control disabled
[    3.243337] netpoll: netconsole: carrier detect appears untrustworthy, waiting 4 seconds
[    7.259816] console [netcon0] enabled
[    7.263549] netconsole: network logging started


That indicates that it tries to setup as local ip 192.168.1.152 but fails. Also setting 10 Mb/s half duplex is abnormal and indicates a connection issue

Because the dhcp discover is active you should be able to solve this problem by using a dhcp server that assigns a dynamic one IP. Please note that this can be different from the static ones. You need to look in the client list of the dhcp server to find out the ip address assigned or do a network scan (IP scanner). The one you have previously set when using Lacie firmware has no meaning, the dhcp server will decide which one to assign or you must assign that IP to the mac address of the Ethernet port of the wsp
From your previous post it seems you already tried this but that the lease failed.


PS Sometimes the telnet client gives up to quickly to get connection, in that case you can try manually to connect via the telnet client Use connect button in the telnet client and choose remote system etc..
But in your case I think that won't work because assigning the static ip address seems to be lost

I will add some lines to the standalone kernel to get more output and see if we can get the assignment of static ip working as it should. But if we could get a dynamic ip address via dhcp server would be easier.
(a simple router has a dhcp server should work)

[fvdw]

I edited the above post

[fvdw]

attached a standalone kernel with adapted init script that should give some more output on the serial console when initializing the network interface