DSM-G600, DNS-3xx and NSA-220 Hack Forum

gazsiazasz wrote:

jcard wrote:

gazsiazasz wrote:

please repair the "network link auto-negotiation" error
i have a 10/100 sw 

That doesn't depends on me, its a kernel bug.

The last kernel where 100Mbps works, for the dns323, is 2.6.26.8; for 2.6.27.53 and latter it does not works anymore.
I think it is related with MII versus PHYLIB and driver changing from version 1.3 to 1.4.
2.6.27 introduced lots of modifications to the marvel driver, and 2.6.27 itself was a mess (53 fixes!)

I have to make a bug report.

Okok but the dns323 with debian squeeze 2.6.32 kernel worked with my sw 2weeks ago.
And one week ago with the latest update (2.6.32-5?) begins dont working on 10/100

sorry for my bad english

okok for you too

I'm talking of vanilla kernels: 2.6.25.20 and 2.6.26.8 worked fine, 2.6.27.53, 2.6.28.10 and latter (2.6.33, 2.6.34 and 2.6.35, at least) didn't work.

Other reports about this issue on the DNS323 also say that 100mbps doesn't work on recent kernels.

Debian kernels have some patches applied, and are configured for wide/generic usage, they are "fat". For Alt-F I want a "thin" kernel, and thus I might have left out some necessary options.
But the fact that 2.6.25.20 and 2.6.26.8 worked fine with a striped-down Alt-F configuration, makes me believe that the issue is not that.

How do I test this: after compiling a vanilla kernel and booting it on the DNS-323, and after configuring the network, it works OK when connected to my gigabit switch.

Then, I issue "ethtool -s eth0 advertise 0x008" (100mbps/full) , and I see the switch leds turning off and then on again, signaling a good 100mbps link; "ethtool eth0" also reports a good working link. However, the box can't ping or be pinged.
dmesg shows a driver message saying "1000bps!:

# ethtool -s eth0 advertise 0x008
eth0: link down
# eth0: link up, 1000 Mb/s, full duplex, flow control enabled # this comes from the eth0 driver!
# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  100baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 8
        Transceiver: external
        Auto-negotiation: on
        Link detected: yes

The, I issue a "ethtool -s eth0 advertise 0x002" (10mbps/full) and the switch leds shows a established 10mbps connection, as well as "ethtool eth0", but again no ping/pinged.

Then I issue a "ethtool -s eth0 advertise 0x020" (1gbps/full) and the switch leds shows 1gbps connection, and ping (and others) work again.

With the 2.6.25.20 and 2.6.26.8 kernels, I don't even need to use ethtool, I just unplug the network cable, connect it directly to my 100mbps laptop and it works fine; unplug and replug to the 1gbps switch and it works again at 1gbps.

I don't want to go into great details here, but the problem is the communication between the driver and the PHY.

If some knowledge guy can figure it out, it would be great, but networking at the chip level is a complicated matter and is out of my knowledge.

But I might be wrong (hmmm...

Hi again,

Have played a bit more.  Tried starting via telnet, as guest and as root.  Still not working for me.  Only log I get is

Stopping sshd
Stopping telnetd
$Shutting down SMB services:
$Shutting down NMB services:
PID   USER     COMMAND
    1 root     init                               
    2 root     [ksoftirqd/0]
    3 root     [events/0]
    4 root     [khelper]
    5 root     [kthread]
   11 root     [kblockd/0]
   14 root     [khubd]
   49 root     [pdflush]
   52 root     [aio/0]
  189 root     [scsi_eh_0]
   51 root     [kswapd0]
  190 root     [scsi_eh_1]
  197 root     [mtdblockd]
  214 root     [kcryptd/0]
  215 root     [kmirrord/0]
  226 root     [loop0]
1391 root     chkbutton
1446 root     fancontrol 0
1468 root     -sh
1641 root     mDNSResponder
1642 root     mDNSResponder
1644 root     mDNSResponder
1938 root     [pdflush]
2184 root     /ffp/bin/sh
5134 root     sh
5143 root     -sh
5176 root     /bin/sh ./alt-f.sh
5343 root     ps
              total         used         free       shared      buffers
  Mem:        61812        52252         9560            0        13052
Swap:       530104            0       530104
Total:       591916        52252       539664


This doesn't look particularly bad, however afterwards there is no contact with the NAS, can't ping, telnet, ssh, or via browser.  Won't shut down by clicking power button and have to pull the plug.

I'm starting it by having alf-f tar and the .sh file in my Volume_1, then running the .sh file.  I have ffp installed.

Any guesses as to where I'm going wrong?

Hi again,

That was the complete contents of the alt-f.log that I posted.  That was on /mnt/HD_a2, I only have one disk in there.

Hmmm....i have stopped optware script from running, but haven't checked to see what is actually running after boot.  Perhaps there are some bits and pieces loading up anyway and so there isn't enough memory to complete the 'reload'.  Is there any error i can see if this is the case?

Have just bought a dlink 655 router so should be gigabit now as required.

I'll take a look tomorrow at the memory usage, bit late tonight

Thanks for the patience and replies Jcard

Hamish

Well the ifconfig gives

# ifconfig
egiga0    Link encap:Ethernet  HWaddr 00:24:01:13:F1:26 
          inet addr:192.168.0.102  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8890 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9103 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:512
          RX bytes:844385 (824.5 KiB)  TX bytes:1271960 (1.2 MiB)
          Interrupt:21


Don't know if the giga name actually means it's linked at giga and not 100....

Where should the alft_f.log file be?  I don't get one at the same place as the reload log.

Just a question on the instructions...

-a) Just want to try Alt-F once:
    download Alt-F-<version>.tar and fun_plug, rename run_plug to, e.g,
    alt-f.sh, put them in your box root directory, and call alt-f.sh from
    the shell.

Thats a typo right?  rename the Fun_plug to ....


2-If you find the alt-f-reloaded.log file, but not a alt-f.sh file, then
  Alt-F didn't boot (step 2-b) in the Installation Details above).
  Read the file, look for obvious errors and try to correct them; if
  asking for help, post the file contents.
  One of the more common problems during the 1-b) step in the Installation
  Details above is lack of free memory. If you are using ffp, run Alt-F
  right after rebooting your box.

Now i'm confused, it's creating a alt-f.sh file?  If I followed the earier step then I've already made an alt-f.sh file.  Is that then my problem, that in the first instance it hsould have been called something else?
Or do you actually mean alt-f.LOG file?

I'll try to check the lights and other things, and try the new B4 soon, bit busy with sorting out the house for my parents visit (they come a long way to visit).

Thanks

Haim

haim wrote:

Just a question on the instructions...

-a) Just want to try Alt-F once:
    download Alt-F-<version>.tar and fun_plug, rename run_plug to, e.g,
    alt-f.sh, put them in your box root directory, and call alt-f.sh from
    the shell.

Thats a typo right?  rename the Fun_plug to ....

I meant "rename the downloaded fun_plug to"

2-If you find the alt-f-reloaded.log file, but not a alt-f.sh file, then
  Alt-F didn't boot (step 2-b) in the Installation Details above).
  Read the file, look for obvious errors and try to correct them; if
  asking for help, post the file contents.
  One of the more common problems during the 1-b) step in the Installation
  Details above is lack of free memory. If you are using ffp, run Alt-F
  right after rebooting your box.

Now i'm confused, it's creating a alt-f.sh file?

You are right. I meant "creating a alt-f.log file"

If I followed the earier step then I've already made an alt-f.sh file.  Is that then my problem, that in the first instance it hsould have been called something else?
Or do you actually mean alt-f.LOG file?

I'll try to check the lights and other things, and try the new B4 soon, bit busy with sorting out the house for my parents visit (they come a long way to visit).

Thanks

Haim

Thanks for pointing out the typos. I have already fixed them in the wiki.

[Added] I need more reviewers, please.

Have a nice weekend with your parents.

Thanks,
Joao

Last edited by jcard (2010-09-25 03:52:26)

So sorry for the late reply, but haven't been checking the forum.

jcard wrote:

pnin wrote:

P.S.: I already made a comment at the site, vouching for a way to get it on USB. Is that possible?

[...] Why do you want Alt-F on USB?

I have fun_plug installed with a few services (lighttpd, transmission) running more or less OK but, as you can easily guess, I'm not very proficient as a Linux tweaker; so I thought I would start trying alt-f by just popping in a pen with the necessary alt-f setup and it would run off the pen until I rebooted, and by removing the pen I would have my previous setup back. When I felt confident enough, I would then install alt-f. I guess the logic here is somewhat similar to a LiveCD.

Alt-F, without extra Alt-F packages and even if not flashed, runs entirely on RAM(*), like the vendor's firmware and unlike ffp or debian. It only uses the disk if it finds a swap partition on it.

If you are using ffp, you can put the fun_plug script and tar file on an usb pen or disk and reload it from there, although I have not tried it. But I can see no point in doing that...

I have been meaning to move my fun_plug to usb, but one way or the other never got to the point of actually doing it, because of unresolved issues or basic fogginess on my part...

If you are not using ffp, then the fun_plug script has to be in the root of the disk filesystem, and the script has to be modified to extract/load Alt-f to/from a usb pen or disk. But again, I see no advantage...

Think LiveCD again...

Also, after booting (or reloaded), if Alt-F finds a ffp directory in the root of any disk filesystem, including a usb pen or disk, it "uses" it.

Glad to know that, another bit to lessen my fog.