Another newbie stuck with USB ethernet adapters...

[cobaia]

OK, this is my first post - I did wade through the topics, but failed to hit what I was looking for.

Still, I may have missed something obvious, so forgive me, if what I ponder below is common knowledge.

First, thank you all for providing decent instructions and tools to replace the very rudimentary initial kernel.

I finally got my two Sheeva Plugs thru mail and started on my quest to replace the old batch of Slugs (with their dying power supplies) with them.  Got six of them sprinkled around the world at the moment, their tasks being 1) dual-ethernet firewall and 2) always-on bittorrent node.

I succesfully managed to install the installer, and get the latest kernel in. Bittorrent replacement (rtorrent is my favourite) was a doodle, but I still hit a snag with my firewall's USB ethernet adapters: apparently even the latest 2.6.30.1 kernel does not have support  built in for them.

My understanding is that Sheeva Plug has N times the memory of Slug, yet Debian for Slug seems to have everything + kitchen sink compiled into the kernel: you plug stuff in, and it works. 

So why the trend not to do the same with Ubuntu for Sheeva, when the memory restrictions are so much less in the way of providing hooks for dynamically loadable modules? Unused driver should not cause any sort of performance degradation, as far as I remember.

As this is a generic platform for tinkering of all sorts, it would be very beneficial to have at least basic projected functionality available without the need to start compiling your own kernels. Kind of "geeky, but yet not so darn ubergeeky"-level...

Firewall with two ethernet ports certainly is one basic use case, and the only way to add a port is via USB, yet there is not life in /etc/udev, as expected.

Or is somebody actually already using Sheeva Plug as a firewall box?  If you are, can you please spare the modules and uImage files for a kernel that knows what to do with USB ethernet adapters?

I know, I could install the cross compilation env, brush up my seven-year old, fading memories of kernel compilation process, and bite the bullet, but just in case someone has done it already...

As for the hardware: I really miss the possibility of using "beep" on Sheeva (boxes with no displays are especially in need of some sort of status indication - can the blue led be blinked via program?), and the fact that shutdown does not actually power down the unit is bit of a drag.  Otherwise, especially if I ever get the OS to boot directly from SD card, this is a formidable step up from Slug.

[cbxbiker61]

If you tell me which modules you need, I can add them to my kernel.  I've been taking a wait and see approach to adding modules to my kernel, adding those modules that are requested.

[cobaia]

Thank you for your generous offer.

I took a look at three different models of ethernet adapters which I could lay my hands on at short notice, and here are the entries logged to syslog at boot:

two seem to use something called "asix":

Jul 12 11:37:36 AAA kernel: eth0: register 'asix' at usb-0000:00:01.2-2, ASIX AX8817x USB 2.0 Ethernet, [MAC]

One uses something called "pegasus":

Jul 13 00:28:31 BBB kernel: pegasus: v0.6.13 (2005/11/13), Pegasus/Pegasus II USB Ethernet driver
Jul 13 00:28:31 BBB kernel: pegasus 2-1:1.0: setup Pegasus II specific registers
Jul 13 00:28:31 BBB kernel: pegasus 2-1:1.0: eth0, ADMtek ADM8511 "Pegasus II" USB Ethernet, [MAC]
Jul 13 00:28:31 BBB kernel: usbcore: registered new driver pegasus

The way "pegasus" maps to config entries is obvious, but I do not know what "asix" matches with.

Yet again, based on my earlier experience with driver modules and kernels, enabling all of these as modules  should not add to the size of the kernel too much:

# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set

some additional newbie questions:

1) do I need to flash the whole installer via "runme" every time I want to install a new kernel, or is there some lesser procedure or script that is sufficient, now that the new installer itself already resides on flash?

2) would it be possible to make a kernel that tries to boot from SD, USB and only finally from internal flash, giving ultimate flexibility for configurations?  Would it be possible to create a kernel image that can be used in all three storage scenarios?

3) Any info from Marvell how to blink the LED as status feedback?  Slug has very nice "heartbeat" blink when it is up and running, the pulse of which is connected to system load.

[birdman]

I took a look at three different models of ethernet adapters which I could lay my hands on at short notice, and here are the entries logged to syslog at boot:

Given that they'll be dynamically loaded modules the output from lsmod could be useful, as it will show which modules have been loaded.

[cbxbiker61]

I've built a new 2.6.30.1 with "asix" and "pegusus" modules (other usb adapters are also supported).

1) do I need to flash the whole installer via "runme" every time I want to install a new kernel, or is there some lesser procedure or script that is sufficient, now that the new installer itself already resides on flash?

if you've already downloaded README-2.6.30.1 http://sheeva.with-linux.com/sheeva/ to your plug.  Delete the old sheeva-2.6.30.1* files and rerun README-2.6.30.1.

2) would it be possible to make a kernel that tries to boot from SD, USB and only finally from internal flash, giving ultimate flexibility for configurations?  Would it be possible to create a kernel image that can be used in all three storage scenarios?

Any sort of "automatic" failover boot would have to be done in u-boot.  The kernel shouldn't have a problem being booted in any of those scenarios.

3) Any info from Marvell how to blink the LED as status feedback?  Slug has very nice "heartbeat" blink when it is up and running, the pulse of which is connected to system load.

I don't want to take the "fun" out of it for you.   Blinking the blue LED is not difficult.  Details are elsewhere on the forum.

[cobaia]

OK, thanks again for the new kernel !

I can happily report that plugging in an USB-ethernet adapter makes eth1 accessible, and I was able to install my favourite "shorewall" firewall, and get incoming packet rules working (i.e. access, control and tracking of incoming port traffic).

The biggest issue was the shorewall config syntax that has changed between versions.

What still seems to be missing in the kernel is IP packet forwarding support, without which the box can not act as a router for intranet computers.

At least adding the usual "gotcha":

net.ipv4.ip_forward=1

to /etc/sysctl.conf and running "sysctl -p" or reboot still does not allow packets originating from other computers to flow thru the Plug.

My guess is that this is controlled by CONFIG_IP_ADVANCED_ROUTER in the config file.

Just in case it is of any help for this or anything else, attached is "lsmod" output from the Slug that is currently running as my firewall router.

(a minor note: your 2.6.30.1 directory file RELEASE still claims the release to be "1")

Module                  Size  Used by
ledtrig_heartbeat       3040  0
ipt_MASQUERADE          3488  1
ipt_LOG                 6624  16
xt_tcpudp               3232  37
xt_state                2304  13
act_police              6308  1
sch_ingress             3840  1
cls_u32                 9156  4
sch_sfq                 6400  3
sch_htb                17664  1
xt_pkttype              1888  4
iptable_raw             2080  0
xt_CLASSIFY             1856  0
xt_CONNMARK             2464  0
xt_MARK                 2432  0
ipt_REJECT              5600  4
xt_length               2016  0
xt_connmark             2048  0
ipt_owner               2048  0
ipt_recent             10096  0
ipt_iprange             1888  0
xt_physdev              3120  0
bridge                 59616  1 xt_physdev
xt_policy               3872  8
xt_multiport            3424  4
xt_conntrack            2912  0
iptable_mangle          2912  1
ip_nat_irc              2944  0
ip_nat_tftp             1952  0
ip_nat_ftp              3744  0
iptable_nat             7812  1
ip_nat                 18642  5 ipt_MASQUERADE,ip_nat_irc,ip_nat_tftp,ip_nat_ftp,iptable_nat
ip_conntrack_irc        7212  1 ip_nat_irc
ip_conntrack_tftp       4528  1 ip_nat_tftp
ip_conntrack_ftp        8368  1 ip_nat_ftp
ip_conntrack           56856  13 ipt_MASQUERADE,xt_state,xt_CONNMARK,xt_connmark,xt_conntrack,ip_nat_irc,ip_nat_tftp,ip_nat_ftp,iptable_nat,ip_nat,ip_conntrack_irc,ip_conntrack_tftp,ip_conntrack_ftp
nfnetlink               7768  2 ip_nat,ip_conntrack
iptable_filter          3104  1
ip_tables              14088  4 iptable_raw,iptable_mangle,iptable_nat,iptable_filter
x_tables               14628  20 ipt_MASQUERADE,ipt_LOG,xt_tcpudp,xt_state,xt_pkttype,xt_CLASSIFY,xt_CONNMARK,xt_MARK,ipt_REJECT,xt_length,xt_connmark,ipt_owner,ipt_recent,ipt_iprange,xt_physdev,xt_policy,xt_multiport,xt_conntrack,iptable_nat,ip_tables
tun                    11936  1
ipv6                  269416  14
dm_snapshot            17180  0
dm_mirror              20948  0
dm_mod                 59120  2 dm_snapshot,dm_mirror
rtc_dev                 7432  0
evdev                  10400  0
ixp4xx_mac             19572  0
asix                   12896  0
usbnet                 17350  1 asix
ixp4xx_qmgr             8652  5 ixp4xx_mac
ixp4xx_beeper           3616  0
ixp4xx_npe             14368  2 ixp4xx_mac
firmware_class         10656  1 ixp4xx_npe
ext3                  137704  1
jbd                    59368  1 ext3
mbcache                 9188  1 ext3
sd_mod                 19248  3
usb_storage            77707  2
scsi_mod              102800  2 sd_mod,usb_storage
ehci_hcd               31240  0
ohci_hcd               17156  0
usbcore               126920  6 asix,usbnet,usb_storage,ehci_hcd,ohci_hcd

[cobaia]

One additional note: this page shows what features are needed in the kernel to support traffic shaping in shorewall: it is for 2.6.21 but should be at least a good starting point.

http://www.shorewall.net/traffic_shaping.htm

[cbxbiker61]

Advanced routing and network scheduling are now included in 2.6.30.1 RELEASE 3.  See if that works for you.

[cobaia]

Thank you for the prompt turnaround, but no routing yet, unfortunately.

I think you forgot to set CONFIG_IP_ADVANCED_ROUTER. 

It is naturally possible that I made some mistake while building the shorewall config from scratch for this test, but based on the description behind this link, looks like that option should be set:

http://kernel.xc.net/html/linux-2.6.0-test4/s390/IP_ADVANCED_ROUTER

Also, even without shorewall active and IP forwarding set in /etc/sysctl.conf, no forwarding occurs.

Just an idea: Ubuntu for x86 seems to have everything enabled, at least I have never hit a snag with it while adding all sorts of peripherals and functionality to many servers utilizing it. Why not copy the config of that distribution, compile it, and see how much the kernel grows when "all options" are set?

Would be nice to have 1:1 feature set available on ARM.

PS: for bookkeeping purposes, might be worthwhile to update RELEASE file contents in the download area to match the release.

[cbxbiker61]

Advanced router is set.  RELEASE file indicates 3.

Remember to delete sheeva-2.6.30.1* before rerunning the README-2.6.30.1.

[cobaia]

So you are saying that only the config and RELEASE files were wrong, as neither modules file nor uImage file were updated at the file repository, and you kept the version number as "3"?

I'm downloading from this location:

http://sheeva.with-linux.com/sheeva/index.php?dir=2.6.30.1%2F

And only RELEASE and config are different from the previous set.

I did a full install with the new kernel (including uBoot install) and still can't get routing to go thru the Plug.

Plug itself can access web OK via eth1 and its routing table looks fine (default goes to eth1), so everything else looks ok.

I'll keep on looking in case I have missed something obvious.

[cbxbiker61]

I didn't change anything.  The files were correct.

If you want to verify which options were used in a given kernel:

zcat /proc/config.gz | less

you will find
CONFIG_IP_ADVANCED_ROUTER=y

[cobaia]

OK, I will go through all dynamic settings from ground up then.

[dumper]

Just an idea: Ubuntu for x86 seems to have everything enabled, at least I have never hit a snag with it while adding all sorts of peripherals and functionality to many servers utilizing it. Why not copy the config of that distribution, compile it, and see how much the kernel grows when "all options" are set?

Would be nice to have 1:1 feature set available on ARM.

i find it a good idea too, it's not always easy when u have everything running well, then u buy a new hardware & find out that u need to recompile the kernel & then bumb into new problems.

[cobaia]

I went thru the configurations between my working Slug firewall and non-working Plug firewall, file by file, and found an error in my Plug configuration - the definitions for NATting between the ports in Plug version of shorewall were missing, and hence no packets were routed even when the new kernel was built to support it.

I was misled yesterday when even non-active shorewall config in Plug did not forward packets: looks like the default behaviour has changed at some point in recent years, as even Slug without active shorewall did not forward packets by default.

Anyway, I can now confirm that my Plug works as a two-interface firewall via an additional USB network interface when using release 3 of 2.6.30.1 kernel by cbxbiker61.

eth0 goes to a gigabit switch in intranet using a fixed IP address and eth1 is connected to a DSL line using dhcp.

I have not yet checked traffic shaping, as it has been totally revamped between shorewall versions, and a simple copy of my old setup could not be used any more. Will try when I find some spare time for that, but for most home firewall cases, that is a low-priority feature.

There is a HUGE difference in startup times between Slug and Plug when running "shorewall restart": 60 secs vs 7 secs. First I thought that I had some grave omissions in my configuration, when restart was done that quickly...

Naturally this can not be explained only by faster CPU, as the shorewall versions are also different (the log output in the new version is much more brief than with the old one), but Plug certainly shows what five years in HW and SW development can do. I'm starting to like this new toy more and more every day...

I will fly back to my second home during next weekend, and install one Plug there as the primary firewall in order to see how it behaves in a 24/7 "always on" situation.  If there is interest, I could write instructions into Wiki on how to set up the shorewall firewall on Plug, AFTER I have seen that it works reliably (should be obvious by mid August or so). Even though the web documentation for shorewall is plentiful, excellent, and up to date, it certainly is a daunting task to build your configuration from scratch, if you have never done so before.

...and I even got the blue led blinking ok after succesful boot, thanks to the tips found elsewhere here

Big thanks to everyone who has helped me so far.