From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4.1)
Description of problem:
What I want: to get my eMails prom pobox.stuttgart.redhat.com trhough
Cisco VPN Client via port 993 - IMAP-SSL
- Dell Latitude D800
- NIC onboard Broadcom - LSPIC
Bus 2, device 0, function 0:
Ethernet controller: Broadcom Corporation NetXtreme BCM5705M
Gigabit Ethernet (rev 1). IRQ 11.
Master Capable. Latency=32. Min Gnt=64.
Non-prefetchable 64 bit memory at 0xfaff0000 [0xfaffffff].
- Sitting at home connected through a DSL line.
- firing up the Cisco VPN client to connect the Red Hat intranet.
- Iï¿½m able to ping, to our stuttgart mailserver
pobox.stuttgart.redhat.com, starting evolution 1.4.5 and login in
shows me just the amount of new eMail, no headers and no way to access
the eMails in my inbox or even to get any mails to my local machine.
- I have tried all the cisco VPN clients tha IS offers through
kickstart.rdu.redhat.com but prob still exists
- the funny thing is that I can connect to a big bunch of other
internal machines w/o a prob through http/https/ping/ssh, ....
- yesterday night I took the most actual driver from the broadcom
Website, which is: bcm57xx-linux-7.1.22.zip
- unzipping the file gave me a src-rpm file, build the RPM, installed
it and fixed manually the wrong perms of the new module bcm5700.o.
Unloading the tg3 module and loading the bcm5700.0 made all probs go
hope this is specific enough ;-)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual Results: tg3 module/driver does not work propperly
Expected Results: either make tg3 module/driver work or exchange with
broadcom driver ;-)
I fear this will happen to RHEL3 and FC2 as well - but not tested ;-)
BTW: On RHL 9 everything worked fine.
*** This bug has been marked as a duplicate of 78616 ***
not that easy ;-) As far as I understood tg3 is not binary, so please
fix that problem that I can use my Notebook without the broadcom driver.
I have double checked inside the RPM-Pack of the Broadcom driver in a
file License, after installing it lies on:
/usr/share/doc/bcm5700-7.1.22/Licenses which includes the GPL 2
==> are you sure this is binary only ???
the cisco stuff is binary only and afaics only that doesn't work. Case
so ... everyone who has a Broadcom card/chip on his/her machine is not
able to get his/her eMails propperly?
ignoring instead fixin is a good way to stabilize our own products ;-)
so lets pass this over to IS than.
thanx for your help anyway
it's not a tg3 bug until you can reproduce it without any binary only
modules loaded. Which so far you haven't.
sooo... the solution must be to have a opensource replacement for the
Cisco VPN stuff... something around that works.
My only or initial intention was to have access to my emails from
outside the red hat intranet.
Sorry to bother you again, but....
please have a look at 118962, just talked with Niels Happel, one of
our Trainers & Consultants, he found also some strange behaviours of
TG3, while in a consulting Project with a big german bank. Replacing
TG3 by the Broadcom driver made everything work like it should. I also
heard from anonther consultant probs with TG3 but due to Daniels
holidays had not chance to talk to him.
Looks pretty much like our TG3 need a bit polish, does not matter if
CiscoVPNCLienst or not ;-)
I've been pestering Cisco on this issue. Here's what they have to say:
"Since the tg3 driver is new, there have been a number of issues that
it has introduced. A Google search will reveal that it's not just
VPN that's affected. One of the big differences between the VPN
Client and other applications is that the VPN Client modifies the
packet directly so that the size of the packet does not match the MTU
setting of the machine when it reaches the ethernet driver. The VPN
Client has overhead it needs to add so it lowers the MTU setting on
the workstation as soon as it makes a client connection so that when
it adds it's data, the final packet comes out to a size that won't
need to be fragmented by the ethernet driver."
I'm a bit skeptical, especially since they claim the driver is new
when it dates back at least as far as RH8, but, maybe this
information will cause someone to go "hmmm... Oh yeah!"?
it sure does ;)
tg3 is one of the drivers that does zero copy networking and checksum
offloading. "that the VPN Client modifies the packet directly"
That is illegal in linux and breaks for zerocopy networking.
Oh well. vpnc works and people are making the in kernel ipsec talk to
Similar to 157147 issue with cisco zero-copy (does not cause issues when vpn is
Turning off all offloading seems to fix on the e1000.
# ethtool -K eth1 tx off
# ethtool -K eth1 rx off
# ethtool -K eth1 sg off
# ethtool -K eth1 tso off
sure you avoid the most obvious data corruption by disabling zerocopy... I still
wouldn't trust my data to a system with this thing in though. Esp when there are
far more safe in this regard solutions around.
FWIW, Cisco has finally come up with a VPN client that works. Version
4.6.02.0030-k9 seems to resolve all the issues I've run into.