Soekris 4521 and Star-OS

[kegrif]

I just got a 4521 in to try with your OS. I have it loaded with 2 Ether and 2 Ruby PC Cards. If I turn on routing and bridging and the rest of the bells and whistles, will I overload the computing power of this board?

[tony]

I just got a 4521 in to try with your OS. I have it loaded with 2 Ether and 2 Ruby PC Cards. If I turn on routing and bridging and the rest of the bells and whistles, will I overload the computing power of this board?

The Soekris boards should not have a problem.

Thanks!

[kegrif]

What about when there are 50-100 users on it. Will their routing and nating be affected?[/quote]

[tony]

That unit is more than capeable of handling 100 or more users without problem. You can have 255 client associations per card, just keep an eye on your bandwidth usage and you should be set.

[om]

Hi,

We are using soekris running staros 1.10.3 build 2866 in AP-mode and our setup is:

wired net---TT-CPE~~starlink PtP~~TT-CPE---Soekris(AP)<clients

problems we currently have with this setup are

- Radio on AP (soekris) seems to get stuck every other day with all the clients showing idle in the association list, while its ethernet interface works fine and hence AP reachable from the wired network. After a reboot, things start running fine.
- Recently we have found ethernet interface of AP (soekris) also not reachable occasionally, while the radio works fine and AP reachable from the client (radio) interface and a reboot solves the problem.

Almost all of our clients use WET11 as CPE and there are 12 of them. As for the first problem, is it the radio card (orinoco silver) in AP or the board itself causing the problem?
Second ethernet problem is surprising, everything (cable etc.) seems to be ok.

Any suggestions?

Thanks,
Om.

[tony]

This is an interesting one. I'm not sure about the etherent-side, but I would strongly consider looking in the 'dmesg' log under the Advanced menu to see if you can find any hardware-releated errors.

For the AP. The WET11s have a very hard time reassociating to an AP, and end up not passing traffic (huge flaw in the WET11 firmware), but if you reset the WET11, it typically is able to surf again. This notmally happens after your WET11 client has been idle for some time, and the AP kicks them off. Resetting the AP is a workaround for the problem as it wakes up all the WET11s when the beacons stop. You can also go into the card configuration dialog, hit "Accept Changes", then Activate Changes. This should surve the same purpose without the reboot.

With this said, you should look into a nice firmware upgrade for the WET11 units which may solve this behavour, or increase the idle disconnect do a longer duration. Can you also go into the 'dmesg' log under the Advanced menu and see if you see anything out of the ordinary, such as transmit timeouts, etc.

Thanks!

[om]

dmesg now doesn't show any hardware problem, I'll try to see the kernel logs whenever any of the two problems occurs.

Regarding WET11 issue, let me first upgrade the firmware and I will post the results.

thanks,
Om.

[om]

dear tony,

here is the kernel logs taken at both the soekris AP and TT-CPE (running starlink) when ethernet problem appeared:

soekris log:
-----------------------------------------------
eth0: Autonegotiation advertising 0x5e1 partner 0x00
eth0: link down
eth0: Autonegotiation advertising 0x5e1 partner 0x45e1
eth0: link up
--------------------------------------------

TT log:
----------------------------------------------
eth0: increased Tx theshold, txcfg 0xd0f01004
eth0: increased Tx theshold, txcfg 0xd0f01006
eth0: increased Tx theshold, txcfg 0xd0f01008
eth0: increased Tx theshold, txcfg 0xd0f0100a
eth0: increased Tx theshold, txcfg 0xd0f0100c
eth0: increased Tx theshold, txcfg 0xd0f0100e
eth0: increased Tx theshold, txcfg 0xd0f01010
eth0: increased Tx theshold, txcfg 0xd0f01012
eth0: Autonegotiation advertising 0x5e1 partner 0x00
eth0: link down
eth0: Autonegotiation advertising 0x5e1 partner 0x45e1
eth0: link up
-------------------------------------------------

rebooting either of the two solves this problem. but now it is occuring quite frequently, (please note that ethernets of TT-CPE and soekris are connected back-to-back with cross UTP cable).

also during startup, dmesg shows "eth0: Promiscous mode enabled" in TT but not in soekris. does it have to do anything with this problem?


thanks,
om.

[georgew]

How long are your ethernet cables?

There is a known problem with the soekris boards with short ethernet cables. I think there is a firmware fix for it, but an easy fix is to put a longer cable on it.


George

[butchkemper]

How long are short ethernet cables?

Is the firmware fix a change to Soekris firmware or to the ethernet driver in StarOS?

Butch

[kegrif]

The fix is actually for the Soekris board and it pertains to a Fast Ethernet connection, not 10BaseT.

[georgew]

I think short is something less than two or three feet, but it could be longer than that, depending on the problem causing it.

George

[om]

My ethernet cable is around 10 ft. I don't know if this is the cause.
But if you check my earlier post I have pasted a dmesg from both soekris and TT at the time when the problem seemed to have appeared

and if you look at them in tandem I concur that when soekris announces "auto negotiation advertising ...." and shows "link down"

and maybe in response to that the TT increases TX threshold in succession of couple of units and finally it also shows link down.

pls note my link between AP soekris and starlink TT is on back to back ethernet about 10ft.

[tony]

Make sure you have good 100Mbps rated cable between your two units. There could also be a problem with using an x-over cable between them as well, which may be solved with installing a mini-switch between them (you can get tiny 4-ports quite cheap from Ovislink that you can convert to do POE).

[TheBarron]

What sort of problem could possibly be caused by using a crossover cable?

On the other hand, I'm curious as to what the problem was/is with a 'short' ethernet cable as well.. as relates specifically to the Soekris.

[georgew]

Ok, the Soekris short cable issue is for cables shorter than 100 feet!!!

That's right, 100 feet, or 30 meters!

The symptom is excessive receive errors, probably because of too much gain on the receive amp. An additional symptom is on really short cables the unit will sometimes not receive at all. Really short is probably shorter than 10 meters... in other words, any cable we are likely to ever use is too short.

They have a fix at http://www.soekris.com/Issue0002.htm , but it is not a firmware fix, it is source code you have to include in the driver.

At the bottom of the fix page there is the statement "All DP83815 drivers should be updated to include the equivalent of the above code". This statement seems to suggest that the DP83815 chips have a variable specification, and it is the driver that is broken.

In my opinion, while this can be fixed at the driver, these boards are defective. However Soekris seems to be too small a company to manage the loss of throwing away a batch of boards, and they don't seem interested in reworking them either. So it might be prudent for us to petition our wonderful StarOS programmers to include the driver fix in StarOS. :wink: (hint hint)

This is not really a StarOS problem, so Soekris should be the one supporting the fix, however reality being what it is, this one may be best addressed in StarOS, only because the supplied fix from Soekris assumes you have access to the source code to be able to use the fix.

That or we have to use a 200 foot patch cable to cover the 6 inches between our Soekris board, and the hub it is connected to.

I've been an ISP since 1987, and in my experience, nearly nothing works the way they told you it would when you bought it. Before that I was an engineer designing computers and modems... and nothing worked right then either. So part of being an engineer is taking a bunch of non-working parts, and somehow make something that /does/ work when you are done.

But we have it easy... in cold-war era Russia, processor chips came with defect lists.... Lists of processor instructions that did not work on this particular chip. So each computer built had to have completely custom software that avoided the use of non-working instructions... that or you had to select a chip that had the instructions you needed, so you would throw away 100 chips for each one you could use... except that in communist accounting, every chip was to be used... This is how the cold war was lost, by letting the politicians make the rules for industry.

George

[tony]

Thank you for the patch information. We will include it in the next StarOS release.

Thanks!

[butchkemper]

Further reading on the Soekris incident report reveals that the problem is only present with a 100BaseT network connection.

Butch

[georgew]

Further reading on the Soekris incident report reveals that the problem is only present with a 100BaseT network connection.

This is true, however many/most of the SBC's these days are using cheap 10/100 chipsets, so I assumed the TT device probably had a similar 10/100 port, and the two sbc's probably negotiated 100mbit connections.

But yes, for people connecting to 10mbit ports, this problem does not appear to exist... probably...

My guess is the receive section of the ethernet controller has a bad resistor on the base of the incoming signal transistor. This could easily cause a problem for 10mbit too, though it may be less of a problem to decode overmodulated 10mbit signals.

George

[dkii]

something else I think would be nice is an option in star-os to manually force the controller to a certain mode(100/half,100/full,10/half or 10/full) I have a cisco router that doesn't like autonegotiating things to be plugged into it, it's only half duplex, but anything autonegotiating goes to 10/full and causes all sorts of problems. As a work around we just put a 10base hub between it and our equipment, but it would be nice not to have to do that.

[tony]

Most ethernet devices under Linux have no means to control the media types. Some drivers have specific tools to accomplish this, but nothing that is 'universal' unfortunately.

[butchkemper]

Will theSoekris DP83815 driver patch be in 1.10.4?

Butch

[tony]

Will theSoekris DP83815 driver patch be in 1.10.4?

Butch

Yes, it will be included in the next RC (or final) release.

Thanks!