On Sun, Aug 20, 2000 at 13:26 -0400, S.T.Ryder wrote:

[ ... where to find ssh when not found on CD ... ]

I don't understand why SuSE do not have (open)ssh on their US CD's as the program is freely downloadable in the US and I have to go to metalab and get it each time I install a new SuSE version. Maybe it's the licence and not the laws. SuSE guys??

I could be wron in this respect, but is there such a thing as "the US CD"? Until now I thought it would be the German and the international version, which would imply more aspects to think about than what's relevant for the USA region. (I'm aware that's the opposite to what's the status most of the other time when there's just "US" and "them". :) virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.

I just thought it was strange that the US Federal government have a server up (ftp.cis.fed.gov) that offers ssh, openssh, openssl to the world and we cannot have it on the CD's. It says on the fed.gov site that rpms and src.rpm are available "mainly RedHat and SuSE have been tested". Yes, they specifically mention our SuSE.

Legally those software packages cannot be re-exported outside the US or Canada. Currenbtly US crypto laws says: 64 bit and lower is ok (but no-one really uses <64 bit crypto). Export licenses are easier to get, especially for western europe/etc, but most opensource packages are done outside the US in the first place (Canada, Australia and Germany seem popular). Open Source crypto is supposedly exportable if you notify the BXA (Bureau of Export Administration), so in theory you can put PGP on a webpage as long as you tell them...... Your mileage may vary, and if you end up in federal prison don't blame me. As for the "Secure server", yes it is "off the shelf" software components you can get for free, but they RSA data component of OpenSSL is licensed. OpenSSL can also use RSAREF, which is slower and generally uglier then "proper" RSA. Legally in the US you cannot use RSA unless you license it, or use RSAREF (and RSAREF has a nasty license, you can't use it for anything that generates revenue, so for example universities cannot use it since they charge tuition which pays for network services). The patents should run out September 20th however at which point the rules change. The main problem is if you press the CD's in the US and put crypto on 'em you cannot export them outside US/Canada without some potential problems. Now I doubt the US would throw every US SuSE employee in federal prison if they did do crypto on the cd's, but OTOH I would advise you consult your lawyer first and make damn sure it's legal.

With Kind Regards,

-Kurt

Greetings All, I am trying to set up a firewall box for a friend who wants to house a small LAN with access to the Internet via a cable modem. His ISP provides dynamic IP addresses with DHCP and I'm using the office network at work to test the setup of the firewall box. I'm having trouble getting dhclient to behave on SUSE 6.4. Over the last couple of weeks the dhclient hardly (if ever) seems to get an IP address, and when it fails it appears to set off a fork bomb of dhclient-script instances that (in around 2 hours) makes the machine (a pentium 166) grind to a complete halt (not even seeming to process any keyboard input). Looking in /var/log/messages after each instance of the problem (after renaming dhclient-script to stop the fork bomb killing the machine) I see either a repeated sequence of (IP address in line 2 changed to protect the guilty): dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 dhclient: DHCPOFFER from 123.123.123.123 dhclient: DHCPDECLINE on eth0 to 255.255.255.255 port 67 (the time between the first and second line is always less than a second, and the time between the second and third line is 5 to 6 seconds) or I see a repeated sequence of: dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 .... dhclient: No DHCPOFFERS received dhclient: No working leases in persistent database - sleeping. It is known that our DHCP server is sometimes not very reliable, which explains the second type of error, but not the first. Why would the dhclient refuse the dhcp offer? And why does the dhclient-script fork bomb every time it fails to get an address. I also have been using the SuSEfirewall package, but I don't think that it has any impact on this particular problem, because the above symptoms still occur when the firewall is turned off (START_FW="no" in /etc/rc.config). (As an aside, I had a to add an ipchains rule to the SuSEfirewall script to permit DHCP requests to be transmitted without the firewall blocking them (even though I had set FW_SERVICE_DHCLIENT to yes in /etc/rc.config.d/firewall.rc.config). The logs showed that the dhcp requests were tagged with the IP address of the firewall box's other network interface (which has a static 192.168.x.y address) and were thus presumably being blocked by the rules on the "forward" chain.) Any help with the dhclient problem would be much appreciated, Jason McDonald. -- Random Signature #117: Maths and alcohol don't mix - never drink and derive.