Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED
Chris Cappuccio [ch...@nmedia.net] wrote: > The installation entails: > > dd if=miniroot55.fs of=/dev/rsd2c > Actually, for the install55.fs image, you want to specify a block size, (or wait ages.) dd if=install55.fs of=/dev/rsd2c bs=1m It's something like 20x faster to specify a block size on some of mine. The 512 byte default block size is so small, it must cause the USB key to re-write the same physical block multiple times. These devices have underlying blocks of 4K and larger.
VideoCore driver stack released under BSD license
http://blog.broadcom.com/chip-design/android-for-all-broadcom-gives-developers-keys-to-the-videocore-kingdom/ -- db
Re: mandoc(1) -Tutf8 misrenders accents
On Sat, Mar 01, 2014 at 00:28, Ingo Schwarze wrote: >> As near as I can tell, this is the "correct" output. > > No, it is not. That's indeed a bug in mandoc(1). Thanks, I appreciate the update and correction. Anything that gets me closer to enabling pretty quotes again is ok by me.
mandoc(1) -Tutf8 misrenders accents
Hi Ted and Stuart,
Ted Unangst wrote on Mon, Feb 24, 2014 at 03:11:16PM -0500:
> On Mon, Feb 24, 2014 at 19:48, Stuart Henderson wrote:
>> On 2014/02/24 10:46, Ted Unangst wrote:
>>> CVSROOT:/cvs
>>> Module name:src
>>> Changes by: t...@cvs.openbsd.org2014/02/24 10:46:37
>>>
>>> Modified files:
>>> etc: man.conf
>>>
>>> Log message:
>>> default to locale awareness. safer than changing internal mandoc defaults.
>> As an example, each of the following commands will input the program
>> ??slithy_toves.?? and write its indented text to ??slithy_toves.out??:
> As near as I can tell, this is the "correct" output.
No, it is not. That's indeed a bug in mandoc(1).
> Here's the source.
>
> As an example, each of the following commands will input the program
> \`slithy_toves.c\' and write its indented text to
> \`slithy_toves.out\':
>
> This is, I believe, asking for combining characters. i.e., it is the
> markup one would use to create an accented c, which plain ascii output
> only approximates as c'. The leading ` may or may not appear depending
> on whether xterm or whatever decides to combine it with the space.
No, this is not asking for combining characters.
Both the Ossanna/Kernighan/Ritter troff manual and the GNU troff
documentation document \' as equivalent to \(aa and \` as equivalent
to \(ga, and all of these are supposed to be rendered stand-alone.
In particular, groff doesn't produce combining Unicode characters
in this case.
If you want combining Unicode characters, there are several ways,
none of them very portable:
1. base character + combine character using U escape
2. base character + combine character using C escape
3. base character + combine character using name-u escape
4. name-combine escape using numeric names
5. name-combine escape using mnemonic names
6. name escape with leading accent
7. name escape with trailing accent
For example, the French "e accent aigu" can be expressed as follows.
The various forms are rendered correctly by the following programs:
input groff mandoc Heirloom plan9
1. e\U'0301' no no yes no
2. e\C'u0301' yesyes unlikely no
3. e\[u0301] yesyes unlikely no
4. \[u0065_0301] yesno unlikely no
5. \[e aa]yesno unlikely no
6. \('e yesyes unlikely no
7. \(e' no no unlikely yes
Where the invocations are:
groff -P-c -mandoc -Tutf8 ...
mandoc -Tutf8 ...
9 nroff -Tutf -man ...
I haven't Heirloom troff set up for testing right now;
if somebody wants to build a port, you are welcome.
> I've been running the diff for a while and didn't notice anything
> unusual in our manpages because we use the correct markup.
You are right in so far as the example above shouldn't use
accents at all, but quotes, or even better a .Pa macro.
That said, here is a patch to mandoc that i intend to commit
after unlock. Now is your rare chance to OK a mandoc patch,
or raise concerns before commit.
Yours,
Ingo
Index: chars.in
===
RCS file: /cvs/src/usr.bin/mandoc/chars.in,v
retrieving revision 1.20
diff -u -p -r1.20 chars.in
--- chars.in22 Jan 2014 20:58:35 - 1.20
+++ chars.in28 Feb 2014 16:46:26 -
@@ -49,21 +49,21 @@
CHAR("}", "", 0)
/* Accents. */
-CHAR("a\"","\"", 779)
+CHAR("a\"","\"", 733)
CHAR("a-", "-",175)
CHAR("a.", ".",729)
-CHAR("a^", "^",770)
-CHAR("\'", "\'", 769)
-CHAR("aa", "\'", 769)
-CHAR("ga", "`",768)
-CHAR("`", "`",768)
-CHAR("ab", "`",774)
-CHAR("ac", ",",807)
-CHAR("ad", "\"", 776)
+CHAR("a^", "^",94)
+CHAR("\'", "\'", 180)
+CHAR("aa", "\'", 180)
+CHAR("ga", "`",96)
+CHAR("`", "`",96)
+CHAR("ab", "`",728)
+CHAR("ac", ",",184)
+CHAR("ad", "\"", 168)
CHAR("ah", "v",711)
CHAR("ao", "o",730)
-CHAR("a~", "~",771)
-CHAR("ho", ",",808)
+CHAR("a~", "~",126)
+CHAR("ho", ",",731)
CHAR("ha", "^",94)
CHAR("ti", "~",126)
Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED
The installation entails: dd if=miniroot55.fs of=/dev/rsd2c Assuming your USB key is identified as 'sd2' after you plug it in (Be careful not to write over a system disk!) Also you can use physdiskwrite or other tools on Windows or other platforms. All tests are welcome.
USB install image for OpenBSD 5.5 - TESTING REQUIRED
Here are some potential USB installer images for OpenBSD/amd64 5.5 http://www.nmedia.net/chris/install55.fs http://www.nmedia.net/chris/miniroot55.fs The install55.fs contains full installation packages. The miniroot55.fs is a ramdisk-kernel only (for network installation or troubleshooting.) Please test either on as many amd64 machines as you can with any USB flash and any USB-CF adapters that you have. Report failures and success of each image ASAP. Test as many flash types (USB, CF-USB, old USB, new USB...) as you can. SPECIFICALLY, IF you have a boot failure, I need to see the dmesg output (and the fdisk and disklabel output from the machine if possible to boot it another way). Any error messages displayed from the boot blocks or BIOS are also essential.
Re: Packet Filter nat-to issue
On 28 February 2014 12:27, Stuart Henderson wrote:
> On 2014/02/28 12:19, Mike Belopuhov wrote:
>> On 28 February 2014 12:14, Stuart Henderson wrote:
>> > While I agree with this, I don't think we should ever be natting to a
>> > non-scoped link-local address..
>> >
>>
>> i think i have addressed this (or a similar) problem some time ago:
>> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_lb.c#rev1.14
>> it would be nice if someone could take a look at it and see if more
>> work is needed. i'll jump in to help as soon as i can.
>>
>
> Ah I had some recollection of a commit in this area, but forgot where
> exactly - you fixed the 'nat-to (em0)' case for dynamic addresses in the
> kernel, but pfctl doesn't know about this.
>
> $ echo 'pass in nat-to em0' | pfctl -o none -nvf -
> table <__automatic_0> const { fe80::f2de:f1ff:fef9:a752
> 2001:8b0:648e:cc01:f2de:f1ff:fef9:a752 }
> pass in inet6 all flags S/SA nat-to <__automatic_0> round-robin
>
ok, so the "nat-to (em0)" will do the right thing since it's a
PF_ADDR_DYNIFTL type pool, but "nat-to em0" is converted to the
automatic table by the pfctl itself. looks like pfctl needs
to grow the IN6_IS_ADDR_LINKLOCAL check itself as well.
Re: Packet Filter nat-to issue
On 28 February 2014 12:24, Mike Belopuhov wrote: > On 28 February 2014 12:19, Mike Belopuhov wrote: >> On 28 February 2014 12:14, Stuart Henderson wrote: >>> While I agree with this, I don't think we should ever be natting to a >>> non-scoped link-local address.. >>> >> >> i think i have addressed this (or a similar) problem some time ago: >> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_lb.c#rev1.14 >> it would be nice if someone could take a look at it and see if more >> work is needed. i'll jump in to help as soon as i can. > > looks like it got lost in the rev1.22: > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_lb.c#rev1.22 my bad, the code got moved to the pf_table.c
Re: Packet Filter nat-to issue
On 2014/02/28 12:19, Mike Belopuhov wrote:
> On 28 February 2014 12:14, Stuart Henderson wrote:
> > While I agree with this, I don't think we should ever be natting to a
> > non-scoped link-local address..
> >
>
> i think i have addressed this (or a similar) problem some time ago:
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_lb.c#rev1.14
> it would be nice if someone could take a look at it and see if more
> work is needed. i'll jump in to help as soon as i can.
>
Ah I had some recollection of a commit in this area, but forgot where
exactly - you fixed the 'nat-to (em0)' case for dynamic addresses in the
kernel, but pfctl doesn't know about this.
$ echo 'pass in nat-to em0' | pfctl -o none -nvf -
table <__automatic_0> const { fe80::f2de:f1ff:fef9:a752
2001:8b0:648e:cc01:f2de:f1ff:fef9:a752 }
pass in inet6 all flags S/SA nat-to <__automatic_0> round-robin
Re: Packet Filter nat-to issue
On 28 February 2014 12:19, Mike Belopuhov wrote: > On 28 February 2014 12:14, Stuart Henderson wrote: >> While I agree with this, I don't think we should ever be natting to a >> non-scoped link-local address.. >> > > i think i have addressed this (or a similar) problem some time ago: > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_lb.c#rev1.14 > it would be nice if someone could take a look at it and see if more > work is needed. i'll jump in to help as soon as i can. looks like it got lost in the rev1.22: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_lb.c#rev1.22
Re: Packet Filter nat-to issue
On 28 February 2014 12:14, Stuart Henderson wrote: > While I agree with this, I don't think we should ever be natting to a > non-scoped link-local address.. > i think i have addressed this (or a similar) problem some time ago: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_lb.c#rev1.14 it would be nice if someone could take a look at it and see if more work is needed. i'll jump in to help as soon as i can.
Re: Packet Filter nat-to issue
On 2014/02/28 11:54, Mike Belopuhov wrote:
> On 28 February 2014 10:15, Loïc Blot wrote:
> > Hello,
> > i encounter a strange problem today on PF. I don't know if this i normal
> > but the result is illogic.
> >
> > I have this rule:
> >
> > pass out quick proto tcp from to port { smtp smtps 587
> > imap imaps pop3 pop3s } nat-to $natto_iface
> >
> > Tables contain IPv4 addresses only.
Tables may contain IPv4 addresses only now, but you may add an IPv6
address to a table later, so it is correct that this rule is added.
> > After applying this rule (i added IPv6 support yesterday), those
> > protocols weren't NAT-ed by PF.
> >
> > By investigating, i found this:
> >
> > pfctl -sr | grep nat-to
> >
> > pass out quick inet6 proto tcp from to any port = 465
> > flags S/SA nat-to <__automatic_d309aaac_0> round-robin
> >
> > Then i look at __automatic_d309aaac_0, because inet6 was strange !
> >
> > pfctl -t __automatic_d309aaac_1 -T show
> >2001:660:3bbb:::2
> >fe80::92b1:1cad:fe18:ea18
> >
> > To resolve this problem i added inet keyword to my rule.
> >
> > Is this normal ?
>
> yes, you've got what you've asked for. you should say "pass out quick inet"
> if you don't want inet6.
While I agree with this, I don't think we should ever be natting to a
non-scoped link-local address..
Re: Packet Filter nat-to issue
On Fri, Feb 28, 2014 at 10:15:15AM +0100, Lo?c Blot wrote:
> i encounter a strange problem today on PF. I don't know if this i normal
> but the result is illogic.
>
> I have this rule:
>
> pass out quick proto tcp from to port { smtp smtps 587
> imap imaps pop3 pop3s } nat-to $natto_iface
the problem here is that the interface has several addresses, so you end up with
> pass out quick inet6 proto tcp from to any port = 465
> flags S/SA nat-to <__automatic_d309aaac_0> round-robin
an automatically generated table, containing all addresses assigned to the
interface, and the poor thing tries to load balance between them (round-robin).
The most straightforward fix is to change the nat-to so it refers to one
specific
address only, and only applies to inet, something like
natto_addr="192.0.2.198"
pass out quick on egress inet proto tcp from to port { smtp
smtps 587 \
imap imaps pop3 pop3s } nat-to $natto_addr
as always, a pfctl -vnf on the config file would show all these things expanded
(yes,
I've been bit by the exact same round-robin problem myself)
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Packet Filter nat-to issue
* Loïc Blot [2014-02-28 11:33]: > Is this normal ? yes. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Packet Filter nat-to issue
On 28 February 2014 10:15, Loïc Blot wrote:
> Hello,
> i encounter a strange problem today on PF. I don't know if this i normal
> but the result is illogic.
>
> I have this rule:
>
> pass out quick proto tcp from to port { smtp smtps 587
> imap imaps pop3 pop3s } nat-to $natto_iface
>
> Tables contain IPv4 addresses only.
>
> After applying this rule (i added IPv6 support yesterday), those
> protocols weren't NAT-ed by PF.
>
> By investigating, i found this:
>
> pfctl -sr | grep nat-to
>
> pass out quick inet6 proto tcp from to any port = 465
> flags S/SA nat-to <__automatic_d309aaac_0> round-robin
>
> Then i look at __automatic_d309aaac_0, because inet6 was strange !
>
> pfctl -t __automatic_d309aaac_1 -T show
>2001:660:3bbb:::2
>fe80::92b1:1cad:fe18:ea18
>
> To resolve this problem i added inet keyword to my rule.
>
> Is this normal ?
yes, you've got what you've asked for. you should say "pass out quick inet"
if you don't want inet6.
> Maybe a fix was required on pf parser?
>
> Have a nice day
>
>
> --
> Best regards,
>
> Loïc BLOT, Engineering
> UNIX Systems, Security and Network Engineer
> http://www.unix-experience.fr
>
>
>
Packet Filter nat-to issue
Hello,
i encounter a strange problem today on PF. I don't know if this i normal
but the result is illogic.
I have this rule:
pass out quick proto tcp from to port { smtp smtps 587
imap imaps pop3 pop3s } nat-to $natto_iface
Tables contain IPv4 addresses only.
After applying this rule (i added IPv6 support yesterday), those
protocols weren't NAT-ed by PF.
By investigating, i found this:
pfctl -sr | grep nat-to
pass out quick inet6 proto tcp from to any port = 465
flags S/SA nat-to <__automatic_d309aaac_0> round-robin
Then i look at __automatic_d309aaac_0, because inet6 was strange !
pfctl -t __automatic_d309aaac_1 -T show
2001:660:3bbb:::2
fe80::92b1:1cad:fe18:ea18
To resolve this problem i added inet keyword to my rule.
Is this normal ? Maybe a fix was required on pf parser?
Have a nice day
--
Best regards,
Loïc BLOT, Engineering
UNIX Systems, Security and Network Engineer
http://www.unix-experience.fr
