Re: Searching for cluestick - iked(8) peer to peer
On Mon, Oct 27, 2014 at 06:28:39PM -0400, Josh Grosse wrote: > I am testing an extremely simple lab environment with iked(8) and > failing to establish flows and SAs on one of two platforms. > > I'm sure its somthing extremely simple, but I'm at a loss to > figure it out on my own. A cluestick would be appreciated. I had the very same issue on my own setup. I did not investigate the source, but I think there is a bug in the code that handles PSK authn, because it worked perfectly fine when I switched to RSA key authn. If you must use PSK, isakmpd/ipsecctl/ipsec.conf would be the workaround. Cheers, -- Vincent / dermiste [demime 1.01d removed an attachment of type application/pgp-signature]
Re: iked troubles, SA not installed
On Wed, Aug 20, 2014 at 03:23:29PM +0200, Vincent Gross wrote: > Hi folks, > > I am trying to set up an IPSec VPN between my OpenBSD-current laptop and > my OpenBSD-current gateway at home. The gateway is connected with plain > old ADSL + PPPoE, and the laptop uses my smartphone tethering functions. > > laptop has a vether(4) with 192.168.55.220/24 configured and up, and > gateway has a vether(4) with 192.168.56.1/24 configured and up. Yeah I > could do without, but I've mainly seen examples where the tunnel > outgoing interface was different from the routed range interface, and > wanted to make sure it was not due to some weird address overlap. > > What goes on is, when I start both iked, negociation completes, but: > 1) only the gateway installs the SA and SP, laptop does not > 2) I am not able to go beyond the TCP three-way-handshake when > connecting from laptop to gateway. > > I tcpdump'd the traffic on outgoing interfaces: every packet that is > sent by one side is received by the other. I can observe traffic on > gateway's enc0, but nothing on laptop's enc0 (which makes sense as SA > and SP are not installed). > I dug a bit more, here is what I found: here is the routing table on the gateway once S[AP] are installed: Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 192.168.55.220/32 0 192.168.56.1/320 0 37.160.166.168/esp/use/in 192.168.56.1/320 192.168.55.220/32 0 0 37.160.166.168/esp/require/out default0 default0 0 none/esp/deny/out Yet, tcpdump on gateway's enc0 shows this: tcpdump: listening on enc0, link-type ENC tcpdump: WARNING: compensating for unaligned libpcap packets 11:29:00.455369 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 1027357934:1027357978(44) ack 3953089614 win 2112 (DF) [tos 0x10] (encap) 11:29:00.456355 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 44:88(44) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.456969 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 88:132(44) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.457439 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 132:176(44) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.499455 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 176:1228(1052) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.499731 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 1228:2280(1052) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.499922 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 2280:3332(1052) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.500189 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 3332:3648(316) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:01.516927 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: . 0:1300(1300) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:03.517208 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: . 0:1300(1300) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:05.788337 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: P 1881608350:1881608371(21) ack 183195314 win 2112 (DF) (encap) 11:29:07.517778 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: . 0:1300(1300) ack 1 win 2112 [tos 0x10] (encap) 11:29:11.788250 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: P 0:21(21) ack 1 win 2112 (DF) (encap) 11:29:14.714265 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: . ack 2 win 2112 (DF) (encap) 11:29:14.714609 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: F 21:21(0) ack 2 win 2112 (DF) (encap) 11:29:15.518775 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: . 0:1300(1300) ack 1 win 2112 [tos 0x10] (encap) 11:29:16.137495 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: F 21:21(0) ack 2 win 2112 (DF) (encap) 11:29:23.789811 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: FP 0:21(21) ack 2 win 2112 (DF) (encap) 11:29:25.130637 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: F 21:21(0) ack 2 win 2112 (DF) (encap) When I got this dump, I already had an SSH connection between laptop and gateway, and I tried to connect to gateway's 222/tcp using telnet. In my previous message, I put a tcpdump trace showing what happens when I try to establish a TCP connection: I ha
iked troubles, SA not installed
Hi folks, I am trying to set up an IPSec VPN between my OpenBSD-current laptop and my OpenBSD-current gateway at home. The gateway is connected with plain old ADSL + PPPoE, and the laptop uses my smartphone tethering functions. laptop has a vether(4) with 192.168.55.220/24 configured and up, and gateway has a vether(4) with 192.168.56.1/24 configured and up. Yeah I could do without, but I've mainly seen examples where the tunnel outgoing interface was different from the routed range interface, and wanted to make sure it was not due to some weird address overlap. What goes on is, when I start both iked, negociation completes, but: 1) only the gateway installs the SA and SP, laptop does not 2) I am not able to go beyond the TCP three-way-handshake when connecting from laptop to gateway. I tcpdump'd the traffic on outgoing interfaces: every packet that is sent by one side is received by the other. I can observe traffic on gateway's enc0, but nothing on laptop's enc0 (which makes sense as SA and SP are not installed). both are running a fairly recent -current (no more than 10 days old). Any clues on what might be going ? Cheers, -- Vincent / dermiste ## gateway /etc/iked.conf: ikev2 esp proto icmp \ from 192.168.56.1 to 192.168.55.220 peer 37.160.239.206 \ psk "redacted" ## laptop /etc/iked.conf: ikev2 active esp proto icmp \ from 192.168.55.220 to 192.168.56.1 peer 79.143.250.153 \ psk "redacted" ## initial sa state on both machines: $ sudo ipsecctl -sa FLOWS: No flows SAD: No entries ## On gateway: $ sudo tcpdump -ni pppoe0 udp port 500 or 4500 or tcp port 222 tcpdump: listening on pppoe0, link-type PPP_ETHER tcpdump: WARNING: compensating for unaligned libpcap packets 14:57:16.480895 37.160.239.206.20603 > 79.143.250.153.4500:udpencap: isakmp v2.0 exchange IKE_SA_INIT cookie: 143d03ddc5809c39-> msgid: len: 520 14:57:16.531113 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: isakmp v2.0 exchange IKE_SA_INIT cookie: 143d03ddc5809c39->383ed0522188ecdc msgid: len: 432 14:57:17.226835 37.160.239.206.20603 > 79.143.250.153.4500:udpencap: isakmp v2.0 exchange IKE_AUTH cookie: 143d03ddc5809c39->383ed0522188ecdc msgid: 0001 len: 272 14:57:17.228337 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: isakmp v2.0 exchange IKE_AUTH cookie: 143d03ddc5809c39->383ed0522188ecdc msgid: 0001 len: 224 14:57:17.229556 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 2 len 376 (DF) [tos 0x10] 14:57:17.229799 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 3 len 136 (DF) [tos 0x10] 14:57:18.059200 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 4 len 824 (DF) [tos 0x10] 14:57:18.059587 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 5 len 136 (DF) [tos 0x10] 14:57:18.266023 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 6 len 1192 (DF) [tos 0x10] 14:57:19.726565 37.160.239.206.20606 > 79.143.250.153.222: S 4201433516:4201433516(0) win 16384 (DF) 14:57:19.726641 79.143.250.153.222 > 37.160.239.206.20606: S 918752052:918752052(0) ack 4201433517 win 16384 (DF) 14:57:19.826467 37.160.239.206.20606 > 79.143.250.153.222: . ack 1 win 2048 (DF) 14:57:19.852144 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 7 len 104 (DF) 14:57:19.866853 37.160.239.206.20606 > 79.143.250.153.222: P 1:22(21) ack 1 win 8000 (DF) 14:57:20.066284 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 8 len 1048 (DF) 14:57:20.266288 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 9 len 1384 (DF) [tos 0x10] 14:57:20.868080 37.160.239.206.20606 > 79.143.250.153.222: P 1:22(21) ack 1 win 8000 (DF) 14:57:20.868190 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 10 len 88 (DF) 14:57:22.868423 37.160.239.206.20606 > 79.143.250.153.222: P 1:22(21) ack 1 win 8000 (DF) 14:57:22.868615 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 11 len 88 (DF) 14:57:24.266858 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 12 len 1384 [tos 0x10] 14:57:25.847062 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 13 len 1064 (DF) 14:57:26.869638 37.160.239.206.20606 > 79.143.250.153.222: P 1:22(21) ack 1 win 8000 (DF) 14:57:26.869732 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 14 len 88
Failing to receive message with MSG_OOB
Hi folks, I am trying to observe the effect of MSG_OOB while receiving data. I have a small demo program that creates an accepting socket, connect a sending socket to the accepting, closes the accepting socket to keep only the sending and the receiving, forks, and handle receive on the parent and send on the child. No flags of any kinds are set. write(send_sk, (void *)&payload, sizeof(payload)) / read(recv_sk, (void *)&payload, sizeof(payload)) => no problem. sendto(send_sk, (void *)&payload, sizeof(payload), 0, NULL, 0) / recvfrom(recv_sk, (void *)&payload, sizeof(payload), 0, NULL, 0) => no problem. sendto(send_sk, (void *)&payload, sizeof(payload), MSG_OOB, NULL, 0) / recvfrom(recv_sk, (void *)&payload, sizeof(payload), 0, NULL, 0) => fails with errno = 0, and tcpdump shows me the packet with the URG flag set. sendto(send_sk, (void *)&payload, sizeof(payload), MSG_OOB, NULL, 0) / recvfrom(recv_sk, (void *)&payload, sizeof(payload), MSG_OOB, NULL, 0) => fails with EINVAL on the receiving end, and tcpdump shows me the packet with the URG flag set. Did I miss something on the man pages ? or is it something more sinister ? Thnaks for your time -- Vincent / dermiste [demime 1.01d removed an attachment of type application/pgp-signature]
event handling in OpenBGPd
Hi gang, I am considering to write a daemon of some kind, and I was going over OpenBGPd's sources to get some good fine-grained design examples. I noticed that although all IO's are asynchronous, libevent is not used, but I can't figure out why. So, is libevent not used by accident or by design ? in the latter case, what is precisely the feature/design consideration that made it unsuitable ? Cheers, -- Vincent / dermiste
Re: Request for Funding our Electricity
On Wed, Jan 15, 2014 at 06:25:53PM +0200, MJ wrote: > > I have long held the opinion that Theo is probably the best coder on this > planet. That?s not any sort of ass-kissing, either, it?s my objective, > unbiased opinion. And I know Henning personally, as in ?live and worked > together with him" - one hell of an expert. > > However, the dilemma that the project has found itself in now very clearly > demonstrates that Theo is not a businessman and that there isn?t any other > businessman at the helm, either. Imagining that people will suddenly start to > pay for something that they have constantly been getting for free is absurd - > their belief is that somebody else will surely step up first or somebody will > fork in the name of fame. No business on this planet is going to allocate > budget to paying OpenBSD?s electricity bills, let alone anything else, > without 1) a detailed itemisation of the electrical bills, 2) a detailed > justification of said line items, and 3) a satisfaction of their own business > interest. It?s just not sexy for a philanthropist to support a relatively > unheard of operating system when cancer is still left uncured. Define sexy. Some people will say it's having flash running full speed on their web browser while streaming 3 youtube videos. For me it's being able to trust my operating system to behave in a way that keeps me in the loop and able to fix it. As for the legalese, some people said "You'll never get anywhere without a protocol number for CARP!", yet some ciscos support CARP nowadays. > > It?s not good to be removing coders from their tasks; the project needs a > businessman or two. One who will handle the corporate feature requests and > charge dearly for them. Things like routing technology and high-speed packet > forwarding - things that can replace the exorbitant costs of maintaining > cisco routers. This is the key. With the FBSD 10GB wire speed packet > forwarding incorporated, OpenBSD would be ready to challenge Cisco in a very > serious way. Completely free as always, but with paid support for this edge > cases that make life what it is. > I don't know what is your background with corporate IT, but my experience is that most of the time what the suits are looking for is the assurance they will have resources to fix arising issues, or in layman terms, a tech support to yell at. I do not see OpenBSD providing such a support. However there are quite a few companies that provide such service for their OpenBSD-based appliances. Does that mean OpenBSD roadmap should be based on what will sell with these companies? The answer (which is "no") has already be given many times on misc@, and I will let Theo add another layer of p[ao]int if he deems it necessary. Lastly, you suggest having a businessman in the project. That is, someone who gets a commit bit by doing something else than coding. It's not even about what this says to the world or the example it sets. It is just plain rude towards the developers. I am not downplaying the skills of businessmen; but you simply can't just say that contributing code the OpenBSD way is the same as selling the product, however tough that may be. This is not a race; this is about doing things right. regards, -- Vincent
Re: Are there any default password managers in OpenBSD?
On Thu, Dec 05, 2013 at 08:20:07AM +0100, obsd, cgi wrote: > So I know the rule.. only remember a few very very long passwords (ex.: > based on several words and a few special chars), and keep the rest of the > passwords in a password manager (those aren't remembered and extreme long). > > But this gets me to 2 questions: > > - Are there any default password managers in OpenBSD (console/GUI based?)? > Or there are only from ports that are not very audited? What is the advise > to where to store the pwd's? > > - Are there any best-practises to generate a password? - that are kept in > password manager, so ex.: 128 char long with special/random chars, etc. > > Thanks for your time > `jot -rc -s '' 32 33 127` will print a random sequence of 32 printable ascii characters using arc4random(3). Min entropy is 32*6 = 192 bits. My 0.2 BTC, -- Vincent / dermiste [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Where is "Secure by default" ?
On Mon, Mar 9, 2009 at 3:36 PM, irix wrote: > In www.openbsd.org wrote "Only two remote holes in the default > install, in more than 10 years!", this not true. I using OpenBSD > like customer, not like administrator. So it wasn't default install anymore, was it ? > And my OpenBSD were attacked, > by simple MiTM attack in arp protocol. that's why OpenBSD comes with IPSec and OpenSSH by default : to let you create secure networks without having to install poorly-integrated 3rd party software. > How then can we talk about the " security by default" Simply because it wasn't default install anymore. > For example, FreeBSD is decided very simply, with this patch http://freecap.ru/if_ether.c.patch > When this is introduced in OpenBSD, so you can say with confidence > that the system really "Secure by default" ? My guess is this will never be in OpenBSD source tree. "Security is a process, not a product", and blindly adding code inside kernel to cover a marginal use case for which there is already a solution is not my idea of a good process, and I'm pretty sure this is not OpenBSD developers's either. For authenticating remote hosts, have a look at ipsecctl, ssh and SSL. Cheers, -- Vincent Gross "So, the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." -- Jerome Simeon & Phil Wadler
Re: dhcpd's options.c in a weird shape
okay, pb solved, i just reused a stable tree to populate a current tree
thanks again
On Nov 10, 2007 4:14 PM, Kenneth R Westerback <[EMAIL PROTECTED]> wrote:
>
> On Sat, Nov 10, 2007 at 03:31:03PM +0100, Vincent GROSS wrote:
> > Hi folks,
> >
> > there seem to be a lil' problem with /usr/src/usr/sbin/dhcpd/options.c.
> > the following patch highlights two weirds constructs inside the file,
> > one in the header, the other one in the MMS checking code.
> >
> > --- /usr/src/usr.sbin/dhcpd/options.c Sat Nov 10 04:53:05 2007
> > +++ ./options.c Sat Nov 10 15:17:50 2007
> > @@ -1,8 +1,4 @@
> > -<<<<<<< options.c
> > -/* $OpenBSD: options.c,v 1.8.4.1 2007/10/10 06:10:27 ckuethe Exp $ */
> > -===
> > /* $OpenBSD: options.c,v 1.19 2007/10/29 16:51:02 krw Exp $*/
> > ->>>>>>> 1.19
> >
> > /* DHCP options parsing and reassembly. */
> >
> > @@ -279,13 +275,9 @@
> > sizeof(u_int16_t))) {
> > mms = getUShort(
> > inpacket->options[DHO_DHCP_MAX_MESSAGE_SIZE].data);
> > -<<<<<<< options.c
> > if (mms < 576)
> > mms = 576; /* mms must be >= minimum IP MTU */
> > }
> > -===
> > - }
> > ->>>>>>> 1.19
> >
> > if (mms) {
> > if (mms < 576)
> >
> > this is the resulting diff of the changes I made, IT IS NOT AN
> > OFFICIAL PATCH, USE IT AT YOUR OWN RISKS !
> >
> > Cheers,
> >
> > --
> > Vincent GROSS
> > "GUIs normally make it simple to accomplish simple actions and
> > impossible to accomplish complex actions." --Doug Gwyn (22/Jun/91 in
> > comp.unix.wizards)
> >
>
> Not sure what you think the problem is. You're apparently comparing
> -stable and -current sources. Can you explain exactly what problem
> you see?
>
> Ken
>
--
Vincent GROSS
"GUIs normally make it simple to accomplish simple actions and
impossible to accomplish complex actions." --Doug Gwyn (22/Jun/91 in
comp.unix.wizards)
dhcpd's options.c in a weird shape
Hi folks,
there seem to be a lil' problem with /usr/src/usr/sbin/dhcpd/options.c.
the following patch highlights two weirds constructs inside the file,
one in the header, the other one in the MMS checking code.
--- /usr/src/usr.sbin/dhcpd/options.c Sat Nov 10 04:53:05 2007
+++ ./options.c Sat Nov 10 15:17:50 2007
@@ -1,8 +1,4 @@
-<<<<<<< options.c
-/* $OpenBSD: options.c,v 1.8.4.1 2007/10/10 06:10:27 ckuethe Exp $ */
-===
/* $OpenBSD: options.c,v 1.19 2007/10/29 16:51:02 krw Exp $*/
->>>>>>> 1.19
/* DHCP options parsing and reassembly. */
@@ -279,13 +275,9 @@
sizeof(u_int16_t))) {
mms = getUShort(
inpacket->options[DHO_DHCP_MAX_MESSAGE_SIZE].data);
-<<<<<<< options.c
if (mms < 576)
mms = 576; /* mms must be >= minimum IP MTU */
}
-===
- }
->>>>>>> 1.19
if (mms) {
if (mms < 576)
this is the resulting diff of the changes I made, IT IS NOT AN
OFFICIAL PATCH, USE IT AT YOUR OWN RISKS !
Cheers,
--
Vincent GROSS
"GUIs normally make it simple to accomplish simple actions and
impossible to accomplish complex actions." --Doug Gwyn (22/Jun/91 in
comp.unix.wizards)
Re: OpenBSD kernel janitors
Okay, so if we're looking for a list of simple tasks to train ourselves, PR list is a good place. At least I've learned something today (mandatory whine : why did we have to wait the 17th post to see this list mentioned ?). On 10/31/07, Theo de Raadt <[EMAIL PROTECTED]> wrote: > >On 31.10-08:40, Theo de Raadt wrote: > >[ ... ] > >> > Yeah, right. > >[ ... ] > >> I don't understand. Is newbies learning new things a waste to you? Do > >> you think they won't really learn anything unless the patch is > >> approved? Or will the patches not be subject to peer review? Or are > >> you worried at who would pass for peer review getting overwhelmed by a > >> huge volume of poor quality patches? > > > >and i would suggest that the severe and prevelant attitude toward the > >possibilty of poor patches or under-educated actions is the most > >significant barrier to encouraging new/young developers. > > Yes, it is a significant problem that we won't hand-hold whiners who > could by now be digging for things to fix. There are hundreds of ways > to self-motivate, but instead we get whine whine whine. > > We've got a PR database with bugs in it, and we NEVER get fixes from > outsiders. That's not news to anyone, if they actually wanted to do > more than whine whine whine. > > Hey, don't blame us if many of you guys are lazy whiners. > > STOP telling us that we need to do more than we already do. > > If you want to be more involved, _you've_ got to step up to the plate. > > But please, first cut the whining. It's just childish. > > -- Vincent GROSS "GUIs normally make it simple to accomplish simple actions and impossible to accomplish complex actions." --Doug Gwyn (22/Jun/91 in comp.unix.wizards)
Re: How can i boot a bsd.rd from windows 2000 ?
On 10/11/07, Christopher Bianchi <[EMAIL PROTECTED]> wrote: > Craig Skinner ha scritto: > > Christopher Bianchi wrote: > >> The situation is this: this notebook can boot from cdrom and floppy, > >> yes..but from docking station ! i haven't docking station ! Desperate > >> :-( > > > > Can it boot from a USB floppy? > > > > > in the bios there aren't any voices for boot from usb... so i assume > that this notebook can't boot in this way :-( > > and from a pen drive ? if your laptop can boot from usb flash pen drive, the following should work : 1) save the contents of your pen drive somewhere 2) do a fdisk -i , create a single partition with disklabel then newfs it 3) copy /bsd.rd and /boot on the freshly newfs'ed partition. 4) do an installboot to set up properly the PBR on the pen drive 5) plug the pendrive on your laptop and try to have the bios boot it. 6) at the boot prompt, type bsd.rd and voila ! see fdisk(8), disklabel(8), newfs(8) and installboot(8) for more informations -- Vincent GROSS "GUIs normally make it simple to accomplish simple actions and impossible to accomplish complex actions." --Doug Gwyn (22/Jun/91 in comp.unix.wizards)
Re: misplacement in dhclient.conf.5
meh, forgot the demimer ... thank you Nick. here is the inlined patch. $ diff -Naur dhclient.conf.5.orig dhclient.conf.5 --- dhclient.conf.5.origSun Oct 14 22:01:48 2007 +++ dhclient.conf.5 Sun Oct 14 22:00:03 2007 @@ -345,19 +345,6 @@ .Nm dhclient.conf , the value that the user wishes the client configuration script to use if the predefined lease is used. -.It Ic script Ar \&"script-name\&" ; -The -.Ic script -statement is used to specify the pathname of the DHCP client configuration -script. -This script is used by the DHCP client to set each interface's initial -configuration prior to requesting an address, to test the address once it -has been offered, and to set the interface's final configuration once a -lease has been acquired. -If no lease is acquired, the script is used to test predefined leases, if -any, and also called once if no valid lease can be identified. -For more information, see -.Xr dhclient.leases 5 . .It Ic medium Ar \&"media setup\&" ; The .Ic medium @@ -485,6 +472,19 @@ Whenever the client tries to renew the lease, it will use that same media type. The lease must expire before the client will go back to cycling through media types. +.It Ic script Ar \&"script-name\&" ; +The +.Ic script +statement is used to specify the pathname of the DHCP client configuration +script. +This script is used by the DHCP client to set each interface's initial +configuration prior to requesting an address, to test the address once it +has been offered, and to set the interface's final configuration once a +lease has been acquired. +If no lease is acquired, the script is used to test predefined leases, if +any, and also called once if no valid lease can be identified. +For more information, see +.Xr dhclient.leases 5 . .El .Sh EXAMPLES The following configuration file is used on a laptop On 10/15/07, Vincent GROSS <[EMAIL PROTECTED]> wrote: > Hi folks, > > I found a misleading statement in dhclient.conf.5 : the description of > the 'script' statement is in the lease declaration section, which can > lead someone to think the script statement is a part of the static > lease declaration. > > The joined gzip'ed patch fix that, but it's only a cut'n'paste at a > more proper place. > > -- > Vincent GROSS > "GUIs normally make it simple to accomplish simple actions and > impossible to accomplish complex actions." --Doug Gwyn (22/Jun/91 in > comp.unix.wizards) > > -- Vincent GROSS "GUIs normally make it simple to accomplish simple actions and impossible to accomplish complex actions." --Doug Gwyn (22/Jun/91 in comp.unix.wizards)
misplacement in dhclient.conf.5
Hi folks, I found a misleading statement in dhclient.conf.5 : the description of the 'script' statement is in the lease declaration section, which can lead someone to think the script statement is a part of the static lease declaration. The joined gzip'ed patch fix that, but it's only a cut'n'paste at a more proper place. -- Vincent GROSS "GUIs normally make it simple to accomplish simple actions and impossible to accomplish complex actions." --Doug Gwyn (22/Jun/91 in comp.unix.wizards) [demime 1.01d removed an attachment of type application/x-gzip which had a name of dhclient.conf.5.patch.gz]
Re: calling syscalls directly from asm
On 7/15/07, Marcus Watts <[EMAIL PROTECTED]> wrote: > Date:Sat, 14 Jul 2007 18:48:46 +0200 > To: misc@openbsd.org > From: "Vincent GROSS" <[EMAIL PROTECTED]> > Subject: calling syscalls directly from asm > > Hi folks, > > I would like to call write(2) without going through the libc functions. I wrote > this little thing to test, it does not print anything, but friends say > it works just > fine with linux. I did check the addresses and operands in the resulting > binary with objdump, everything has the correct values. What am I doing > wrong ? Feel free to cluebat me to death if I missed some obvious point ... ... I don't know what you hope to accomplish by avoiding the use of libc. But if you really want to do that, you'll need to know that the system call interface is completely different on linux than openbsd. Here's assembly code to call write on linux: .globl write write: pushl %ebx movl8(%esp),%ebx# fd movl12(%esp),%ecx # buffer movl16(%esp),%edx # count movl$4,%eax # __NR_write int $128 popl%ebx testl %eax,%eax jl cerror_ ret cerror_: negl%eax movl%eax,errno movl$-1,%eax movl$-1,%edx ret In linux, parameters are passed in the registers, & the error code is returned as a negative number. Here's assembly code to call write on openbsd: .globl write write: movl$4,%eax # SYS_write int $128 jb cerror_ ret cerror_: movl%eax,errno movl$-1,%eax movl$-1,%edx ret On OpenBSD, parameters are passed on the stack. The kernel cleverly copies stuff from the stack just where the C calling conventions left them, which is why you don't see any code here to muck with that. An error is indicated by setting the carry flag. Incidently, there are better ways to do hexadecimal conversion. That is, assuming you really don't want to use libc. For instance, consider how you might use this: *--cp = "0123456789abcdef" [ n & 15 ]; -Marcus Watts Okay, so I did missed a big, fat, screaming obvious point ... Thanks a lot for your answers. -- Vincent GROSS "GUIs normally make it simple to accomplish simple actions and impossible to accomplish complex actions." --Doug Gwyn (22/Jun/91 in comp.unix.wizards)
calling syscalls directly from asm
Hi folks,
I would like to call write(2) without going through the libc functions. I wrote
this little thing to test, it does not print anything, but friends say
it works just
fine with linux. I did check the addresses and operands in the resulting
binary with objdump, everything has the correct values. What am I doing
wrong ? Feel free to cluebat me to death if I missed some obvious point ...
#include
#include
char hexstr[12] = "0x\n" ;
int main(int argc, char *argv[]){
unsigned int stack_ptr ;
unsigned int str_addr ;
int *page_start ;
int page[1024] ;
int i ;
int __ret ;
asm("movl %%ebp, %0" : "=r"(stack_ptr)) ;
str_addr = (unsigned int)hexstr ;
page_start = (int *)(stack_ptr & ~0xFFF) ;
for (i = 0 ; i < 8 ; i++){
switch ((stack_ptr >> (i*4)) & 0xf){
case 0 :
hexstr[9-i] = '0' ;
break ;
case 1 :
hexstr[9-i] = '1' ;
break ;
case 2 :
hexstr[9-i] = '2' ;
break ;
case 3 :
hexstr[9-i] = '3' ;
break ;
case 4 :
hexstr[9-i] = '4' ;
break ;
case 5 :
hexstr[9-i] = '5' ;
break ;
case 6 :
hexstr[9-i] = '6' ;
break ;
case 7 :
hexstr[9-i] = '7' ;
break ;
case 8 :
hexstr[9-i] = '8' ;
break ;
case 9 :
hexstr[9-i] = '9' ;
break ;
case 10 :
hexstr[9-i] = 'a' ;
break ;
case 11 :
hexstr[9-i] = 'b' ;
break ;
case 12 :
hexstr[9-i] = 'c' ;
break ;
case 13 :
hexstr[9-i] = 'd' ;
break ;
case 14 :
hexstr[9-i] = 'e' ;
break ;
default :
hexstr[9-i] = 'f' ;
}
}
/*
write(1, hexstr, 11) ;
*/
asm volatile ("\n\tint $0x80"
: "=a"(__ret)
: "0"(4), "b"(1), "c"(hexstr), "d"(11));
/*
for (i = 0 ; i < 1024 ; i++){
page[i] = page_start[i] ;
}
write(1, (char *)page, 4096) ;
*/
exit(0) ;
}
--
Vincent GROSS
"GUIs normally make it simple to accomplish simple actions and
impossible to accomplish complex actions." --Doug Gwyn (22/Jun/91 in
comp.unix.wizards)
Re: driver question
On 4/17/07, Jonathan Gray <[EMAIL PROTECTED]> wrote: On Mon, Apr 16, 2007 at 05:09:12PM -0700, Ted Unangst wrote: > On 4/16/07, James Mackinnon <[EMAIL PROTECTED]> wrote: > >This was likely answered before. I went hunting and seemed to not find a > >solid > >answer, thus, after the time of looking, I figured I need to take the > >moment > >to ask > > > >I have a quad Xeon 700 Dell 6450 with 4 146gig scsi drives connected to a > >perc > >2/dc controller. > > pretty sure that's the aac driver. it doesn't really work. PERC 2/DC is listed in ami(4) so it should work fine and with bioctl(8) RAID management even. Did you check the emulation mode (mass storage or iop) in your card's bios? I have a perc2/sc and everything works fine in mass storage mode, while iop mode is definitely broken. -- Vincent GROSS "God made fertile lands so that humans could live in and deserts so that they could recognize their soul." (Tuareg saying)
Re: Booting a Thinkpad T23
On 4/4/07, Kamil Monticolo <[EMAIL PROTECTED]> wrote: On Wed, 4 Apr 2007 06:23:54 -0700 (PDT) sweetnsourbkr <[EMAIL PROTECTED]> wrote: > I'm trying into install OpenBSD 4.0 onto my laptop. It's a Pentium 3 1.13 > MHz with 768MB RAM. > > I burned an install CD following the installation instructions. I buned the > cd40.iso first, started a multisession CD. Then afterwards, burned the rest > of the packages and finished the multisession CD. This setup boots fine on > my desktop system. > > On my laptop, however, it reads the CD, but it does not boot, and goes > straight into the hard disk boot (Lilo in my case). > > I've tried disabling hard drive boot, enabling the floppy disk, enabling > superdisk boot, updated the BIOS to the latest release, all to no avail. > > Does anyone know how I can boot onto my Thinkpad? Any help would be greatly > appreciated. :) > -- > View this message in context: http://www.nabble.com/Booting-a-Thinkpad-T23-tf3525744.html#a9836727 > Sent from the openbsd user - misc mailing list archive at Nabble.com. > Maybe try to burn it on cd-rw in single-session mode or on native cd-r disc. It should works fine. If you have another machine, try to netboot it. you just need a bootp/dhcp server and a tftp server with the files pxeboot and bsd.rd. If you only have win32 machines, tftpd32 makes a nice dhcp & tftp server (and it's open source). -- Vincent GROSS
wireless on OpenBSD : ath(4) or ral(4) ?
On 4/4/07, Marius ROMAN <[EMAIL PROTECTED]> wrote: ral(4) because it's better supported. On 4/4/07, Nick ! <[EMAIL PROTECTED]> wrote: > On 4/4/07, Vincent GROSS <[EMAIL PROTECTED]> wrote: > > > > > 1) what is the R.E. level of ath(4) ? fully understood, mainly understood ? > > > > 2) Is Atheros still reluctant to disclose documentation for its chips ? > > > > 3) If 1)=fully and 2)=reluctant, what should I pick between ath(4) and ral(4) ? > > ral(4). I have ath(4) because I got it from a big box store, but I'm > ashamed. Don't support stupid vendors, give your money elsewhere. > As you are conforting me in my final decision, let's go for ral(4). Thanks folks. -- Vincent GROSS
wireless on OpenBSD : ath(4) or ral(4) ?
Hi folks, I've decided to get myself a wireless card to have an opportunity to play with wireless w/o being limited by Intel's licenses and iwi firmware. I looked at http://www.openbsd.org/lyrics.html#37, then http://www.openbsd.org/lyrics.html#39. From 3.7 I retained ral(4) and ath(4), but ath(4) is reverse engineered. So my questions are : 1) what is the R.E. level of ath(4) ? fully understood, mainly understood ? 2) Is Atheros still reluctant to disclose documentation for its chips ? 3) If 1)=fully and 2)=reluctant, what should I pick between ath(4) and ral(4) ? -- Vincent GROSS
Re: cat.c includes
On 3/19/07, hiren <[EMAIL PROTECTED]> wrote: hi all, i found it interesting that cat.c compiles after removing these includes: #include #include #include #include #include im just curious to hear opinions and learn something ;) Have you tried to run it ? -- Hiren Patel [EMAIL PROTECTED] -- Vincent GROSS
