Not an official publication of
Infinite Monkeys, Inc.
DISCLAIMER:
I take no responsibility whatsoever for the contents of these comments or what happens if you try anything written here. If you don't know what you're doing, you should consult someone who does (not me).
Download the source from Adaptec. None of the RPM's converted by alien seem to work.
Copy the new files into the existing /usr/src/linux/drivers/scsi/aic7xxx (after you make a backup). So far this is what you'd expect.
Edit /usr/src/linux/drivers/scsi/Makefile to trick the system into compiling 79xx when you asked for 7xxx:
#ifeq ($(CONFIG_SCSI_AIC7XXX),y) obj-$(CONFIG_SCSI_AIC7XXX) += aic7xxx/aic79xx.o #endif
Change /usr/src/linux/drivers/scsi/aic7xxx/Makefile so the AIC7XXX flag compiles aic79xx.o:
ifeq ($(CONFIG_PCI),y) obj-$(CONFIG_SCSI_AIC7XXX) += aic79xx.o endif
Activate the aic7xxx as a module in the kernel config. Rebuild the kernel modules.
I haven't verified that every one of these steps is required, but all this collectively seems to work.
If all that fails, you can try my aic79xx.o.
:GSDEVICE=ijs: :EXTRA_GS_OPTIONS=-sIjsServer=hpijs -dIjsUseOutputFD:and to the gs call near the end of /usr/lib/printfilters/ps-to-printer.fpi, I added:
-sDeviceManufacturer=HEWLETT-PACKARD \ -sDeviceModel="PHOTOSMART P1000" \ -sIjsParams=Quality:Quality=3,Quality:ColorMode=2,Quality:MediaType=2,Quality:PenSet=2 \Theoretically, if another printer was present that didn't use GSDEVICE=ijs, the added values in ps-to-printer.fpi should be ignored.
Replace myjob with your office domain and myhouse with your home domain, assuming you're connecting your house into your office. Replace all the definitions in the first 10 lines with the real addresses for your situation. You might have to adjust the sleep time depending on your connection.
On the machine inside the firewall, add a file like this to your root cron, perhaps every five minutes:
#! /bin/bash LOCAL_HOST=1.2.3.4 LOCAL_NET=1.2.3.0 LOCAL_MASK=255.255.255.0 LOCAL_SOCKS=socks://proxy-socks.myjob.com:1080 SSH_USER=ssh-myjob REMOTE_DOMAIN=myhouse.org REMOTE_HOST=192.168.1.10 REMOTE_NET=192.168.1.0 REMOTE_MASK=255.255.255.0 SSH_PORT=22 ping -c 4 $REMOTE_HOST 1>/dev/null 2>/dev/null if [ $? -ne 0 ]; then killall -9 cotty export SSH_SOCKS_SERVER=$LOCAL_SOCKS /usr/local/bin/cotty -- /usr/sbin/pppd proxyarp noauth \ $LOCAL_HOST:$REMOTE_HOST \ -- /usr/local/bin/ssh2 -t -e none $SSH_USER@$REMOTE_DOMAIN -p $SSH_PORT -o 'Batchmode yes' \ /usr/bin/sudo /usr/sbin/pppd noauth & echo SSH sleep 15 /sbin/route add -net $REMOTE_NET gw $REMOTE_HOST netmask $REMOTE_MASK echo "ROUTE OUT" /usr/local/bin/ssh2 -t -e none $SSH_USER@$REMOTE_DOMAIN -o 'Batchmode yes' \ sudo /sbin/route add -net $LOCAL_NET netmask $LOCAL_MASK gw $LOCAL_HOST echo "ROUTE IN" fiOn the outside machine, add a user such as:
ssh-myjob:x:1234:5678::/home/localhost/ssh-myjob:/bin/shwith a blocked password and put a valid key in '/home/localhost/ssh-myjob/.ssh2'. You probably want to test the key with some simple logins first.
The strategy for this secure virtual private network is built on 2 layers. The first layer creates a unencrypted ppp connection through a telnet connection. The second layer uses an ssh2 session over the first layer to faciliate an encrypted ppp connection. After that, a couple of route commands allow for other machines to use the connection.
check-vpn:
#! /bin/bash
# needs an short 'expect' script to negotiate telnet through the firewall
LOGIN_SCRIPT="/usr/local/vpn/log-in"
LOCAL_HOST=1.2.3.4
SSH_USER=ssh-user
REMOTE_HOST=192.168.1.10
REMOTE_NET=192.168.1.0
REMOTE_MASK=255.255.255.0
PPP_NET=192.168.2
SSH_PORT=22
ping -c 4 $REMOTE_HOST 1>/dev/null 2>/dev/null
if [ $? -ne 0 ]; then
killall -9 cotty
# layer1
/usr/local/bin/cotty -- /usr/sbin/pppd $PPP_NET.1:$PPP_NET.2 noauth \
-- $LOGIN_SCRIPT &
echo "LAYER 1"
sleep 30
# layer2
/usr/local/bin/cotty -- /usr/sbin/pppd proxyarp noauth \
$LOCAL_HOST:$REMOTE_HOST \
-- /usr/local/bin/ssh2 -t -e none \
$SSH_USER@$PPP_NET.2 -p $SSH_PORT &
echo "LAYER 2"
sleep 30
# route
/sbin/route add -net $REMOTE_NET gw $REMOTE_HOST netmask $REMOTE_MASK
echo "ROUTE"
fi
log-in:
#!/usr/bin/expect -f spawn /usr/bin/telnet -e '' -8 -E -L proxy expect "gw->" send "c DOMAIN.com\r" expect "login:" send "ppp-user\r" expect "word:" send "PASSWORD\r" interact
You'll very likely have to tune the log-in script for your local configuration by logging in by hand and noting the dialog.
I put check-vpn in a five minute root cron to make sure the connection restarts promptly if it gets cut.
The remote machine needs two special user accounts. For the examples, they would be ppp-user and ssh-user. Their "shell" should both be set to the full path of ppp, such as '/usr/etc/ppp'. 'ppp-user' needs the password used in the expect script. 'ssh-user' can have a blocked password, but it needs a valid ~/.ssh2 directory populated with an appropriate key. To be safe, you should transport the ssh key by hand or some means other than internet cleartext.
If all works correctly, you should see two (extra) ppp entries when running 'ifconfig'. All operations should work just as though the remote machine was on the local net.
Once the VPN connection is established, either side can initate communication over that layer, but with this method, only the machine inside the firewall can start the initial VPN layer. Using a cron, the connection can be made persistant so that the remote machines can access the internal net at any time.
Update: as of about 20010814, the following fix no longer works. kdm is using its own Xsession apart from /etc/X11/Xsession used by xdm. I'll see what I can come up with.
The recent version of kdm appears to no longer call your .xsession or .xinitrc scripts. I solved this problem by adding a file /etc/X11/Xsession.d/25-xsession containing the following:
if [ -e "$HOME/.xsession" ]; then export WINDOWMANAGER=$startup startup=$HOME/.xsession fi
Update: Now that kernel 2.4 is out, just use 'natsemi.o'.
The fa312.o file provided by Netgear is for 2.2 and there are significant kernel include changes to 2.3. This is how I ported it. Please inform me if you see a problem.
The fa312.h is fine. Leave it alone. In Netgear's provided fa312.c,
1. ... change all usages of type 'struct device' to 'struct net_device'. (many places)
2. ... change member access '&dev->tbusy' to '&dev->state'. (two places)
3. ... change 'mark_bh (NET_BH);' to 'raise_softirq(NET_TX_SOFTIRQ);'.
(one place)
This looks plausable by looking at other headers,
but this is the least confident change.
The files do not mention a copyright, so here you go:
makefile (original)
fa312.h (original)
fa312.c (original)
fa312.c_mod
Web page, Copyright 2000, Jason Weber