Nortel Netlock VPN Client

[Piotr Walczak]

Hi,

if so then why not fix the netlock from the kernel side? I did it with
success with kernel 2.4.22-1.2115 and it works great.
In skbuff.h file I simply moved the new "real_dev" definition to the end
of the struct and recompiled the kernel. Now, the old netlock binaries
that operate on the structure see what they did before and the rest of
the world can use the new real_dev. I tried this trick on the kernel
2.4.22-1.2188 but - either I screw something up (it was well after
midnight) or something else has changed in the kernel - the mishim.o
module kills the network.
Anyway, this workaround works fine for the original FC1 kernel and I
will keep it until Apani releases the new version of netlock.

Piotr Walczak

Reddan, Charles G wrote:
        By the way, this isn't a Fedora issue per se... It appears to me
        to be a specific kernel update issue, which the NetLock vendor
        simply hasn't kept up-to-date with. It stopped working for me at
        the same time as some changes to 'skbuff.h' that went in with
        2.4.22 in the base (non-Redhat-modified) kernel, when running a
        custom kernel with RH9. 
        
        Looking around at the time, I found that the 'skbuff' data
        structure changed in 2.4.22 and beyond when a new structure
        definition
        struct net_device *real_dev;
        was inserted in the MIDDLE of the existing sk_buff structure,
        displacing anything (e.g., various control structures) that lay
        beyond that point in the original skbuff structure. The
        binary-only portion of the Netlock client naturally would not
        have spontaneously changed itself at the same time, so it would
        be using now-invalid offsets within the skbuff structure when
        *it* tries to manipulate these buffers.
        
        So, the compilable "shim" for the Netlock client still compiled
        ok, but it isn't the only part of the VPN client. At bootup
        time, if the
        binary Netlock client modules were loaded (need not actually be
        in use) I'd get a mess of "No more skbuff" messages within a
        minute or two, followed by failure. I dropped back to a 2.4.21
        kernel and it works happily with that... even now on Fedora.
        
        Looking at NetLock's (now Apani's) web site, their most recent
        release (3.0 at the start of this year) of the product is said
        to work with RH9 and Suse 8.2. The more recent version of Suse
        (9.0) is NOT listed as supported, and since its supplied kernel
        version includes that same update to skbuff.h, I am not
        surprised. Hopefully someone at Apani
        is planning to recompile the binary-only portion of their code
        with a more recent kernel someday. 
        
        Chuck R.
        
        
        
        
Charles,

Thank you for the most insightful explanation of the issue I've seen
yet. Have you sent your findings to support apani com? I was testing
their beta versions of what is now 3.0 and I had very similar failures
on FC1, RHEL3 and SUSE 9. I did come to find that changes in GNOME are
what kept me from logging in under FC1. RHEL3 would kernel panic.

I'm gonna follow your lead and try a generic 2.4.21 kernel and see if I
get any better luck. Eventually I think I'll end up using RHEL3 because
that's the direction the apps developers where I work are heading.

Apani claims they're about to release beta code for FC1, RHEL3 and SUSE
9. I saw other posts that indicated a finished product would be
available by May.

Shannon McMackin
mcmackin shentel net