1.8b Development

The problem I had with my GB-1000 was solved by Manuel and Andy with a fix applied to m0n0wall. This was when I had DSL PPPoE internet service.

The problem has come up again though. I have switched to DHCP on WAN cable service and TCP routing out to the internet is now broken. ICMP does work and this reminded me of the original symptoms prior to the fix. So I added this to my config.xml, fxp1 is my WAN interface:

<shellcmd>ifconfig fxp1 -rxcsum</shellcmd>

This fixes it.

So it would seem that the original fix done some time ago was somehow incomplete. I can live with that shellcmd in the config file, but perhaps as long as the developers are poking around under the hood, they might be able to solve it for good.

Thanks.

Hmm, what version are you on ?
I used my cable modem for testing the gb-1000 and I recall that fixed it

I'm on the latest, 1.8.0b510.

The only thing I changed was setting DHCP on WAN instead of PPPoE.

I will try resetting to default configuration and see what happens and report back.

Definite bug.

I reset to factory defaults and rebooted. System came back up, grabbed a WAN IP via DHCP, but no routing out to the internet.

I go to http://192.168.1.1/exec.php and enter:

ifconfig fxp1 -rxcsum

fxp1 is my WAN interface, and BAM it works.

At least I can get into the WebGUI and do this fix. The original problem situation wouldn't let me do even that.

Back to the config.xml with the shell command for now.

Thanks for looking.

Does this happen with traffic shaper off ?

Traffic Shaper is off when in the default install configuration. So yes, it does not route TCP with the shaper off. I didn't try with it on.

Also, ICMP does route out the WAN, it's TCP that is broken.

I'm wondering whether the GB-1000 uses a particular revision of the 82559 that doesn't support RX checksumming. It's pretty odd that the problem only occurs on the WAN interface, and didn't occur on brushedmoss' GB-1000. Would be interesting to find out what happens if you swap LAN/WAN assignments, or use one of the other two NICs for WAN.

The fxp driver in FreeBSD 8 is a bit different from the one in FreeBSD 6 as far as checksumming is concerned. The latter only enables it on 82550 or better chips (which have full hardware checksum support, including TX), while the former also enables RX-only checksumming (using a different interface) on 82559 with revision A0 and up, excluding 82559ER. If you can easily open the case and get at the chips, it would be interesting to hear what kind of markings there are - perhaps they don't all have the same revision or something, and the code that decides whether to use HW checksumming on a particular 82559 needs to be changed...

Manuel,

Thanks for your continued interest in this.

I looked at the chips. They are all the same and marked GTS® FC-515LS 2K20Y

I moved the WAN cable from fxp1 to fxp3 (which does not have the shell command to disable checksum in config.xml). Routing was broken.

What's puzzling, to me at least, is that with PPPoE on WAN everything worked. This problem didn't come up (again) until I switched ISP with the new one using DHCP on WAN. I'm sure there is something in the code that explains this.

As to why brushedmoss's GB-1000 is problem free, it could be that his unit is newer/older than mine and has different chips in it that don't exhibit the problem.

I looked at the chips. They are all the same and marked GTS® FC-515LS 2K20Y

Those are the Ethernet magnetics modules, not the actual NIC chips. Look for something like this: http://www.qqread.com/ArtImage/20060919/qp58_2.jpg (could also be in a larger package with visible pins).

What's puzzling, to me at least, is that with PPPoE on WAN everything worked.

That alone isn't surprising - when using PPPoE, all that the NIC sees is PPPoE frames, and thus it can't do any hardware checksum acceleration (so it's all done in software, and the problem doesn't appear). It's strange though that there's no problem on the LAN interface...

OK, found them. Odd that the marking cannot be read straight on, you have to look at an angle to the surface to read it:

GD82559 L0441F41 circled M circled C '98 KOREA (same as in the jpg except for the second number)

They are all alike.

I got to test mine out last night, no problems at all with current image, works fine with my cable modem.

My NIC chipset is 82559ER L050IE64  copyright 99 Korea

ok, now I know why mine works :-)

from if_fxp.c

        /* For 82559 or later chips, Rx checksum offload is supported. */
        if (sc->revision >= FXP_REV_82559_A0) {
                /* 82559ER does not support Rx checksum offloading. */
                if (sc->ident->devid != 0x1209)
                        sc->flags |= FXP_FLAG_82559_RXCSUM;
        }

OK, that explains it :-)

I do have another unit that has the CF on the the motherboard (like the one that had the bad caps and couldn't be saved) and I looked at the NIC chips.

They are 82559ER L2031A52 copyright '99 Korea. I would imagine this would work too? Perhaps I will try it and see.

So, will m0n0 be updated to check for the different chip revisions or just disable RX checksum altogether?

Thanks for looking into this. At least it's a simple fix via config.xml that doesn't require doing it on another system like when we started with 1.8.

Another unrelated problem I am having is that SNMP will stop responding after some period of time and has to be reinitialized which resets the uptime counter. Next time it dies I will investigate with top and see if it's still there or has crashed. I might go back to 1.33 for a few days to see if it stays up there or not.

hi fred, can  you execute the following in exec.php and post the output ?

Code:

sysctl dev.fxp.0.%pnpinfo

this should give the device id like this

Code:

dev.fxp.0.%pnpinfo: vendor=0x8086 device=0x1209 subvendor=0x8086 subdevice=0x000c class=0x020000

we can patch the fxp driver to not support Rx checksum offloading for that chip version.

I have temporarily reverted back to m0n0wall 1.33 to see how the SNMP Agent behaves there. So far it's fine, so there is some problem with it on m0n0wall 1.8b.

I ran the command you wanted on 1.33, here is the output:

$ sysctl dev.fxp.0.%pnpinfo

dev.fxp.0.%pnpinfo: vendor=0x8086 device=0x1229 subvendor=0x8086 subdevice=0x000c class=0x020000

If you need it run from mono 1.8b, just say so and I can do that.