Re: ED25519 SSHFP in OpenSSH IETF
Le 2014-04-09 12:47, Loganaden Velvindron a écrit : This situation is rather unusual, and that makes me wonder what's exactly going on there, as I believe that we've done our homework correctly. UNUSUAL??? The IETF is notorious for its incredible delays. The situation is typical IMHO. Nobody in IETF is accountable for anything, so you rely on people's good intentions. You need to poke the right people, and poke them again, and poke someone who will know how to poke them, etc. etc. etc. Maybe the OpenSSH community needs to get involved, so that we can get work done :-) ? If by get involved you mean swamping the IETF powers that be with email, that would the wrong way to do it. SM knows how to navigate the IETF waters. Let him do his job. Simon
Re: PF rule for transparent siproxd ?
I don't know the direct answer to your question, but taking a step back... Any reason you want a transparent SIP proxy rather than an explicitly-configured SIP B2BUA? The latter is usually much easier to set up and maintain. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: NAT reliability in light of recent checksum changes
Le 2014-01-27 21:21, Geoff Steckel a écrit : It would be good if when data protected by a checksum is modified, the current checksum is validated and some appropriate? action is done (drop? produce invalid new checksum?) when proceeding. This is exactly what's being done. Don't you listen when Henning speaks? Simon
Re: NAT reliability in light of recent checksum changes
Le 2014-01-28 03:39, Richard Procter a écrit : In order to hide payload corruption the update code would have to modify the checksum to exactly account for it. But that would have to happen by accident, as it never considers the payload. It's not impossible, but, on the other hand, checksum regeneration guarantees to hide any bad data. So updates are more reliable. This analysis is bullshit. You need to take into account the fact that checksums are verified before regenerating them. That is, you need to compare a) verifying + regenerating vs b) updating. If there's an undetectable error, you're going to propagate it no matter whether you do a) or b). Simon
Re: NAT reliability in light of recent checksum changes
Le 2014-01-28 12:45, Stuart Henderson a écrit : This analysis is bullshit. You need to take into account the fact that checksums are verified before regenerating them. That is, you need to compare a) verifying + regenerating vs b) updating. If there's an undetectable error, you're going to propagate it no matter whether you do a) or b). Checksums are, in many cases, only verified *on the NIC*. Consider this scenario, which has happened in real life. - NIC supports checksum offloading, verified checksum is OK. - PCI transfers are broken (in my case it affected multiple machines of a certain type, so most likely a motherboard bug), causing some corruption in the payload, but the machine won't detect them because it doesn't look at checksums itself, just trusts the NIC's rx csum good flag. In this situation, packets which have been NATted that are corrupt now get a new checksum that is valid; so the final endpoint can not detect the breakage. I'm not sure if this is common enough to be worth worrying about here, but the analysis is not bullshit. You're right. I was in the rough, sorry, and thanks for the explanation. I don't think this scenario is worth worrying about though. Simon
Re: NAT reliability in light of recent checksum changes
Le 2014-01-25 14:40, Richard Procter a écrit : I'm not saying the calculation is bad. I'm saying it's being calculated from the wrong copy of the data and by the wrong device. And it's not just me saying it: I'm quoting the guys who designed TCP. Those guys didn't envision NAT. If you want end-to-end checksum purity, don't do NAT. Simon
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-25 07:45, chrisbenn...@bennettconstruction.us a écrit : I have two very old IP print servers that work just fine. You just have to flip those 4 tiny little switches to get access to program them over IP. Can I get another tiny switch to add IPv6? You could just map an IPv6 address to them using pf's af-to keyword: pass in inet6 to 2001:db8::1 af-to inet from 192.0.2.1 to 192.0.2.2 Simon
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-25 00:20, Constantine A. Murenin a écrit : No dual-stacking is provided; in their slides from [0], T-Mobile USA claims that IPv6-only with NAT64/DNS64 is cheaper than dual-stack with NAT44. Yes. I forgot to mention another reason why the 3GPP folks like NAT64: most 3GPP equipment vendors charge ISPs by the number of PDP contexts. Currently deployed equipment can not do dual-stack PDP contexts. So if you want to provide dual-stack to your customers, you need to provide them each with two single-stack PDP contexts, which doubles the amount you end up paying in license fees to equipment vendors. That's going to change in the medium term when new equipment capable of dual-stack PDP contexts gets deployed. But in the short term, NAT64 looks very attractive. Simon
Re: Why anyone in their right mind would like to use NAT64
One use case: ISP who wants to provide IPv4+IPv6 to customers, but does not have enough IPv4 addresses for everyone, so has to NAT anyway, and wants to simplify the operation of its edge network by running only one protocol. Quite popular with 3GPP folks since they have zillions of customers and are already NATing them in IPv4-only, and their handsets all run applications coded in a high-level language like Java and therefore support IPv6 by default. The notable exception being Skype... As soon as you provide IPv6, you have a huge chunk of your traffic that is IPv6: Google, Facebook, Youtube, Akamai, etc. So NAT64 is only used for the remaining mom and pop shops, and www.openbsd.org. And that fraction of IPv4-only hosts is diminishing and all signs point to that trend continuing. So these 3GPP providers can go from NAT everything to NAT a little by deploying NAT64. Why would anyone in their right mind not consider that? Simon
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-24 14:25, Kurt Mosiejczuk a écrit : The one use I could think of us to make your internal network independent of your ISP. Right now, if you change ISPs, your network prefix changes and your whole network has to be renumbered. I read about it in the following article earlier this year. http://www.theregister.co.uk/2012/03/31/ipv6_sucks_for_smes/ I'd be happy to have it pointed out to me how the article is wrong, but it seemed to point out the ugly corners the IPv6 folks don't talk about. What you need to multihome is either BGP or NAT. Exactly as in IPv4. Nothing has changed. The only new thing with IPv6 is that there's more bits. However, with more bits you have the possibility of using a nicer form of NAT in that statelessly maps one prefix to another: http://tools.ietf.org/html/rfc6296 And here's a draft with more info on how to apply it to multihoming: http://tools.ietf.org/html/draft-bonica-v6-multihome-03 Simon
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-24 14:54, Claudio Jeker a écrit : But less PI space. Since some evangelists belive in the superiority of IPv6 and try everything to make it impossible to get routable PI space. At the moment IPv6 is a step backwards in all regards. Wait wait wait... what RIR doesn't take multihoming as a valid justification for getting IPv6 PI space? Simon
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-24 15:29, Barbier, Jason a écrit : Well expanding on the address space and numbering issue, that would be a valid use for NAT but I honestly think it would be better to actually try and fix that before trying to put a hack over the top of it. I'm going to wait a long time for a firmware update that makes my IPv4-only printer speak IPv6. Simon On Wed, Oct 24, 2012 at 12:24 PM, Peter Hesslerphess...@theapt.org wrote: You have IPv4 only applications, that need to talk with the IPv6 internet.
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-24 15:38, Barbier, Jason a écrit : I'm going to wait a long time for a firmware update that makes my IPv4-only printer speak IPv6. Well man there are several stable implementations of 4 to 6 and 6 to 4 bridges. I don't know what kind of bridges you're talking about, but I'll assume that pf's NAT64 implementation is one of them. Simon
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-24 15:59, Paul de Weerd a écrit : On Wed, Oct 24, 2012 at 03:42:52PM -0400, Simon Perreault wrote: | Le 2012-10-24 15:38, Barbier, Jason a ?crit : | I'm going to wait a long time for a firmware update that makes my | IPv4-only printer speak IPv6. Even if it did, would you trust that stack on the global (v6) internet ? No, I was thinking of a v6 LAN. | Well man there are several stable implementations of 4 to 6 and 6 to 4 | bridges. | | I don't know what kind of bridges you're talking about, but I'll | assume that pf's NAT64 implementation is one of them. I think he means lpr listening on v6 and pushing out to the v4 address on the other end. There's no need for extra shit to do what has been possible for years. Of course you can do it at any layer you want. There's also faithd if you want to do it at layer 4. I prefer my translations to be done at layer 3, thank you very much. Simon
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-24 16:30, Claudio Jeker a écrit : With IPv6 multihoming should work trivially: plug two access lines into a switch, get RAs from both, get addresses from both on your end-host, and your end-host needs to select the proper route for each source address. Again, no NAT or BGP. Applications will need to support hosts having multiple addresses in the future, and happy eyeballs seems to have made browsers do that. Ha ha ha ha, this will work for a single host but how will you manage multiple ones. Bonus question, how do you think the host router with no knowledge of the underlying network topology will choose a route? This setup is one of the biggest mistakes made in IPv6. Careful. What he's talking about is his own proposal, not what IPv6 is. Simon
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-24 15:12, Jussi Peltola a écrit : On Wed, Oct 24, 2012 at 02:43:14PM -0400, Simon Perreault wrote: What you need to multihome is either BGP or NAT. Exactly as in IPv4. Nothing has changed. The only new thing with IPv6 is that there's more bits. Oh? I have two internet connections plugged directly into my desktop box at home, it is multihomed and there is no BGP or NAT. This does need some policy routing to work with uRPF filtered access lines. With IPv6 multihoming should work trivially: plug two access lines into a switch, get RAs from both, get addresses from both on your end-host, and your end-host needs to select the proper route for each source address. Source-based routing is arguably not multihoming, depending on your definition of multihoming. It's not new to IPv6 either. Again, no NAT or BGP. Applications will need to support hosts having multiple addresses in the future, and happy eyeballs seems to have made browsers do that. There is also a considerable advantage against multihoming where hosts only have 1 address configured: if the application tries to use all source addresses available, Oh, that's the new thing you're proposing: happy eyeballs on source addresses. Interesting... you can get to google even if one of your access lines has no connectivity to them; with BGP multihoming you will not, If you can't trust the routes you receive over BGP, you're kinda screwed anyway. Simon
Re: [OpenBGPd = Cisco] error in OPEN message, unknown subcode 8
Le 2012-10-10 06:13, Laurent CARON a écrit : On my side I do have 2 OpenBSD (OpenBGPd) boxes. What versions? In my logs I do observe this: A pcap dump would be useful... Oct 9 09:44:40 bgpgw-003 bgpd[17498]: neighbor 193.105.232.181 (pv4_gw-003_to_ISC): state change Idle - Connect, reason: Start Oct 9 09:44:40 bgpgw-003 bgpd[17498]: neighbor 193.105.232.181 (pv4_gw-003_to_ISC): state change Connect - OpenSent, reason: Connection opened Oct 9 09:44:40 bgpgw-003 bgpd[17498]: neighbor 193.105.232.181 (pv4_gw-003_to_ISC): received notification: error in OPEN message, unknown subcode 8 FYI, subcode 8 has not yet been assigned by IANA: http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xml#bgp-parameters-6 ...but it is defined in a new draft: http://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-07#section-5 8 - Grouping Conflict - values of capability codes used in Session Id of the received message cannot be unambiguously mapped to a locally configured group That should provide enough clue to be able to dig at the right place... Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: [OpenBGPd = Cisco] error in OPEN message, unknown subcode 8
Le 2012-10-10 11:51, Laurent CARON a écrit : A pcap dump would be useful... Here it is: http://elfe.lncsa.com/get?k=5Rya5Acaq26TqJ9MXG The pcap shows that the Cisco box is refusing your OPEN message. It doesn't like it for some reason. You need to figure out why. Probably because of the way it's configured. I see no reason to blame either side so far. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: SSI
Le 2012-09-27 16:04, Brian Empson a écrit : Has there been/are there plan to include some SSI functionality for BSD? Try mod_include. Doc here: http://httpd.apache.org/docs/1.3/mod/mod_include.html Simon
Re: How to PROVE your system is up to date?
Le 2012-09-18 12:36, Ed Flecko a écrit : I have State and Federal regulators that want me to PROVE (since their only used to looking at Micro$oft servers) my OBSD 5.1 server is up to date, and there are no outstanding patches that need to be applied. *I* know that's the case, because I follow the patch branch, but how do I show (i.e., something I could print for them would be best) them my system is up to date and that all patches have been applied??? Ask them what they would consider acceptable? This is fuzzy stuff. They're not looking for a math-style proof. They need to ensure you're following best practices. So ask them what they want, then give it to them. My two cents (Canadian)... Simon
Re: pf change state's altq queue
Le 2012-09-17 11:57, Ted Unangst a écrit : Here's the background. My cable ISP has this turbo boost thing where the first ~2 seconds of a connection download at 50Mbps, then it's throttled back to 20Mbps. I want to do this in pf (differentiate casual web browsing from long downloads). My first thought is I need to set up two altq queues, one full speed and one half speed. [...] Alternatively, any way to accomplish the same thing would be good. I probably have missed something obvious... Why don't you just use hfsc? Simon
Re: pf change state's altq queue
Le 2012-09-17 13:19, Ted Unangst a écrit : I probably have missed something obvious... Why don't you just use hfsc? I want the queue to change based on the length of time (or data) the connection has been around. All of my traffic is going to be coming from port 80, so there's way to identify to long connections vs short connections in pf. Isn't that the point of hfsc? From pf.conf(5): The hfsc scheduler supports some additional options: linkshare sc The bandwidth share of a backlogged queue. realtime sc The minimum required bandwidth for the queue. upperlimit sc The maximum allowed bandwidth for the queue. sc is an abbreviation for service curve. The format for service curve specifications is (m1, d, m2). m2 controls the bandwidth assigned to the queue. m1 and d are optional and can be used to control the initial bandwidth assignment. For the first d milliseconds the queue gets the bandwidth given as m1, afterwards the value given in m2. Just define m1, d, and m2 according to your needs... I must be missing something obvious... Simon
Re: problem setting inet6 route
Le 2012-09-04 02:13, Remi Locherer a écrit : I now got an answer from Hetzner: - I'm not allowed to use an address from the gateway subnet. They will block my traffic if I'm using such an address - They recommend that I configure a /59 prefix. In my opinion this makes no sense. I now configured a /63 prefix which contains my subnet and the gateway subnet (this works). They did not explain how their gateway is configured to send traffic to my host without configuring a specific address on my host. This is broken. I tried to give them benefit of the doubt, but they're just clueless. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: problem setting inet6 route
(I rearranged your email: provider info at the top, your actions at the bottom.) Le 2012-08-31 03:19, Remi Locherer a écrit : I rented a server from Hetzner where I installed OpenBSD 5.1. Hetzner also provides IPv6 but somehow with a strange setup. I got something like the following from them: Gateway Address: 2001:db8:1:1110::1/64 Subnet I can use: 2001:db8:1:/64 For Linux they give these instructions: linux# ip route add 2001:db8:1:1110::1 dev eth0 linux# ip route add default via 2001:db8:1:1110::1 I would understand this to mean: a---[You]---b---[Them]---Internet a = 2001:db8:1:::/64 b = 2001:db8:1:1110::/64 You on a = 2001:db8:1:::whatever You on b = 2001:db8:1:1110::whatever except 1 Them on b = 2001:db8:1:1110::1 If you don't need a, don't configure it. If I now assign for example 2001:db8:1::1/64 to the interface on my server it doesn't let me set the default gateway becaus it's not in the same subnet: openbsd# ifconfig rl0 inet6 2001:db8:1::/64 openbsd# route add -inet6 default 2001:db8:1:1110::1 route: writing to routing socket: Network is unreachable add net default: gateway 2001:db8:1:1110::1: Network is unreachable I tried: openbsd# route add -inet6 -iface 2001:db8:1:1110::1 2001:db8:1:::1 openbsd# route add -inet6 default 2001:db8:1:1110::1 But now it's not possible to ping6 2001:db8:1:1110::1 or any other IPv6 address. Yeah that's all wrong. Assuming that rl0 is on network b, try: ifconfig rl0 inet6 2001:db8:1:1110::2 route add -inet6 default 2001:db8:1:1110::1 Simon
Re: problem setting inet6 route
Le 2012-08-31 10:52, Remi Locherer a écrit : Gateway Address: 2001:db8:1:1110::1/64 Subnet I can use: 2001:db8:1:/64 For Linux they give these instructions: linux# ip route add 2001:db8:1:1110::1 dev eth0 linux# ip route add default via 2001:db8:1:1110::1 I would understand this to mean: a---[You]---b---[Them]---Internet Right except there is no network a. On [You] there is only one interface (rl0). So? It allows you to create such a network a. That's the point. You don't need a physical interface. There are many kinds of network interfaces that you can create yourself (loopback, tunnels, etc.). Have some imagination. a = 2001:db8:1:::/64 b = 2001:db8:1:1110::/64 You on a = 2001:db8:1:::whatever You on b = 2001:db8:1:1110::whatever except 1 Them on b = 2001:db8:1:1110::1 If you don't need a, don't configure it. If I now assign for example 2001:db8:1::1/64 to the interface on my server it doesn't let me set the default gateway becaus it's not in the same subnet: openbsd# ifconfig rl0 inet6 2001:db8:1::/64 openbsd# route add -inet6 default 2001:db8:1:1110::1 route: writing to routing socket: Network is unreachable add net default: gateway 2001:db8:1:1110::1: Network is unreachable I tried: openbsd# route add -inet6 -iface 2001:db8:1:1110::1 2001:db8:1:::1 openbsd# route add -inet6 default 2001:db8:1:1110::1 But now it's not possible to ping6 2001:db8:1:1110::1 or any other IPv6 address. Yeah that's all wrong. Assuming that rl0 is on network b, try: ifconfig rl0 inet6 2001:db8:1:1110::2 route add -inet6 default 2001:db8:1:1110::1 This works. But I have to figure out (ask Hetzner) if I'm the only customer they use 2001:db8:1:1110::/64 (I think so). If not it would mean there are multiple customers on network b. That would be somewhat unusual. Also over their web interface they only offer me to create DNS entries for 2001:db8:1:::/64. This make total sense. Just assign yourself an address from that prefix, e.g. on the loopback interface. Simon
Re: More sensible and consistent rc.conf.local
Le 2012-08-29 09:57, Mikkel Bang a écrit : If OpenBSD was on Git / at GitHub, youngins like me would have patched this baby up a long time ago. Sadly, a good argument against moving to Git. Simon
Re: IPv6, OpenBSD and .. Mac OS X Lion
On 07/12/2012 02:41 PM, Tor Houghton wrote: On Thu, Jul 12, 2012 at 12:32:52PM -0500, Mark Felder wrote: That's odd... I swear my wife's macbook has had functional IPv6 for quite a while... unless the recent Lion update nuked it and I didn't notice? Please report your findings -- I'd love to fix this at home if it's broken. I'm still looking; wide-dhcp6 is running, but Lion is not playing ball. FYI, it works for us over here. OpenBSD router running rtadvd, Macs running default config. Never needed to do anything special on the Macs. Just defaults everywhere. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: simple PF rule? redirect port without touching address
On 2012-07-09 10:17, Stuart Henderson wrote: On 2012-07-09, Fil DiNotofdin...@gmail.com wrote: But i was wondering if I could achieve something that would work for ALL the addresses behind the router as well without creating individual rules for each address. Something like this: pass in on egress proto tcp from $location1 to any port ssh rdr-to (original destination IP) port XXX22 nope. easiest option for this is probably a userland proxy. not sure but I reckon relayd can probably do it. Not even with a bitmask pool? pass ... rdr-to 0.0.0.0/0 port XXX22 bitmask Simon
Re: OpenBSD as IPv4+6 gateway
On 2012-06-21 22:00, Hugo Osvaldo Barrera wrote: On 2012-06-21 17:22, Simon Perreault wrote: On 2012-06-21 15:50, Hugo Osvaldo Barrera wrote: I have read a great deal regarding IPv6 and IIRC, if I subnet my network block, my ISP would have to know it has to route traffic to that subnet through the WAN IP address of my router. Yes. If they don't allow that, then they don't know what they are doing. You're not supposed to assign a /48 to a single link. A single link gets a /64. But how would they know though which single IP to route the rest of the subnets? I mean, if I assign: 2800:40:402:::1/64 to my router's WAN interface (2800:40:402::: is it's default gateway) 2800:40:402::1/64 to it's LAN interface 2800:40:402::2/64 to one of my clients Doesn't my ISP need to know that traffic to 2800:40:402::1 should be routed through 2800:40:402:::1? Yes. They need to tell you the address. Call and ask them. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: OpenBSD as IPv4+6 gateway
On 2012-06-22 09:13, Mark Felder wrote: All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link. Yeah, I think we'll stick with our /126s. This is ridiculous. You should be allocating all your PtP links out of a single prefix protected by an ACL at your border. All packets to the PtP prefix need to be dropped. You should be doing this no matter the size of your PtP links. The attack is impossible with good operational practices. Simon
Re: OpenBSD as IPv4+6 gateway
On 2012-06-21 03:46, Hugo Osvaldo Barrera wrote: My assigned block is 2800:40:402::0/48 My default gateway is 2800:40:402::: (it's inside my assigned block). Hugo, Friendly suggestion: read a book on IPv6. If you had understood the above information, you wouldn't be talking about bridging. This makes me think that your question isn't about OpenBSD, it is about IPv6. You need to understand IPv6 first, and then when you know exactly what you want on a protocol level you can come back and ask how to do it in OpenBSD. Simon
Re: Learning C Programming
On 2012-06-21 15:21, Juan Francisco Cantero Hurtado wrote: Some good or bad comments about Deitel's C How to program? http://www.deitel.com/Books/C/CHowtoProgram7e/tabid/3635/Default.aspx The worst book on C programming I've ever read. No, scratch that. The worst book on programming I've ever read. No, it's worse. The worst book I've ever read. All categories. Simon
Re: OpenBSD as IPv4+6 gateway
On 2012-06-21 15:50, Hugo Osvaldo Barrera wrote: I have read a great deal regarding IPv6 and IIRC, if I subnet my network block, my ISP would have to know it has to route traffic to that subnet through the WAN IP address of my router. Yes. If they don't allow that, then they don't know what they are doing. You're not supposed to assign a /48 to a single link. A single link gets a /64. The alternative would be to proxy ndp and have OpenBSD forward packets, yet I don't see a way to proxy an entire subnet using ndp. Right, because you shouldn't do that, especially in IPv6 with the 64 bits of addressing for a single subnet. Am I missing something perhaps? Call the support and ask them for the missing information? You're definitely not supposed to bridge. Simon
Re: pf and ICMP in asymmetric routing setups
On 2012-06-12 14:08, Bernd wrote: I've got two OpenBSD 5.1-stable/amd64 boxes employed which do all the routing for our AS (OpenBGPd and OpenOSPFd). I see asymmetric traffic (I thought it to be that way), which itself doesn't really create problems. However, I see problems with ICMP. pf seems to drop all but the first response from any of the hosts within our network (seen from the Internet). Any idea how to deal with this? As soon as I turn off pf, everything runs smoothly. Without having the details of your setup, the big principle is: pf is stateful (by default). Statefulness doesn't play well with asymmetric routing. I'm sure if you investigate a little bit more you'll discover it's not limited to ICMP. In the end the solution will be one of: remove statefulness, avoid asymmetric routing, or share state with pfsync. My two cents: try to avoid statefulness on core routers. Move stateful elements to the edge, where routing is symmetric. Simon
Re: pf and ICMP in asymmetric routing setups
On 2012-06-12 15:55, Bernd wrote: What might be the easiest solution to have pf not care about states any longer -- using 'keep state sloppy'? Or disabling statefulness entirely (how?)? If you don't need it, just disable pf. echo pf=NO /etc/rc.conf.local Sloppy tracking could work. Also check out flags any. Tagging no state at the end of each rule could incur a performance hit because the rule set will need to be traversed for each packet instead of relying on the state table. Only do it if performance doesn't matter or you have few rules. I would definitely try it for the kind of coarse-grain ACL we usually see on core routers, i.e. a single pass rule with a table of allowed source/destination addresses. Simon
Re: setsockopt question
On 2012-06-10 11:26, Peter J. Philipp wrote:
+ if (setsockopt(udp[i], IPPROTO_IPV6,
+ IPV6_HOPLIMIT,on, sizeof(on)) 0) {
s/IPV6_HOPLIMIT/IPV6_RECVHOPLIMIT/
RFC 3542 for more info.
Simon
Re: OpenBSD mailing lists demime in an ascii world
On 2012-06-04 19:10, Jérémie Courrèges-Anglas wrote: AFAIK SMTP without MIME can only transport ASCII. Sure, but shear.ucar.edu advertizes 8BITMIME, the only problem here is demime. 8BITMIME is useless. It only allows SMTP to transport arbitrary 8-bit content. It still doesn't allow you to specify a character set other than ASCII. So what are you going to do with this extra bit? Unless you can communicate the character set, you're still pretty much stuck with ASCII. You need MIME, with its Content-Type header, to be able to specify a character set other than ASCII. 8BITMIME is an optimization to allow bodies to be encoded more efficiently, using 8 bits instead of 7. But you need an 8-bit character set in order to benefit from it. Simon
Re: OpenBSD mailing lists demime in an ascii world
While what I wrote below is true, I didn't understand correctly the problem with demime. I thought it properly demimed the message, including the headers. Turns out it just stupidly and brokenly mangled the body. And it looks like the problem is fixed now. Yay! Simon On 2012-06-05 08:39, Simon Perreault wrote: On 2012-06-04 19:10, Jérémie Courrèges-Anglas wrote: AFAIK SMTP without MIME can only transport ASCII. Sure, but shear.ucar.edu advertizes 8BITMIME, the only problem here is demime. 8BITMIME is useless. It only allows SMTP to transport arbitrary 8-bit content. It still doesn't allow you to specify a character set other than ASCII. So what are you going to do with this extra bit? Unless you can communicate the character set, you're still pretty much stuck with ASCII. You need MIME, with its Content-Type header, to be able to specify a character set other than ASCII. 8BITMIME is an optimization to allow bodies to be encoded more efficiently, using 8 bits instead of 7. But you need an 8-bit character set in order to benefit from it. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: OpenBSD mailing lists demime in an ascii world
On 2012-06-02 13:19, JC)rC)mie CourrC(ges-Anglas wrote: As you'll see in my signature above, 8 bit characters are mangled on OpenBSD mailing lists. Not that I care much, but passing the demime perl script a ''-8'' argument would be enough to solve that (if that is desired). AFAIK SMTP without MIME can only transport ASCII. Simon
Re: SMTP server pools at odds with the RFC?
On 2012-06-04 06:06, David Diggles wrote: I was just thinking surely resending from a different IP breaks the RFC for SMTP? Then I did some googling, and found this. http://bsdly.blogspot.com.au/2008/10/ietf-failed-to-account-for-greylisting.html Not only is greylisting fine from a protocol point of view (as others have pointed out), the IETF is also well aware of it. This is about to become an RFC: http://tools.ietf.org/html/draft-ietf-appsawg-greylisting Abstract This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. Simon
Re: OpenBSD in April's issue of the CACM
On 2012-05-29 19:40, Theo de Raadt wrote: http://www.freebsd.org/news/status/report-2011-10-2011-12.html#The-New-CARP Look at that last entry about talking to IANA! The entry in question is: 4. Work with IANA to get an official protocol number. gnn@ to handle. This shows ignorance about how IANA works. You cannot work with IANA. IANA is a clerk. It maintains registries. It is a bookkeeping job. It cannot make decisions of its own. The IETF, and its steering group the IESG, are the ones who lay down the rules that IANA must obey. Protocol numbers are maintained at: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml The important bit is the Registration Procedures, which are: IESG Approval or Standards Action These terms are defined here: http://tools.ietf.org/html/rfc5226#section-4.1 IESG Approval - New assignments may be approved by the IESG. Although there is no requirement that the request be documented in an RFC, the IESG has discretion to request documents or other supporting materials on a case-by-case basis. Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG. See also this RFC which specifically applies to protocol-numbers: http://tools.ietf.org/html/rfc5237 Even though the IESG Approval route may look easier, in practice it is exceptional for registrations to go through this path. There needs to be some justification for not writing an RFC, usually based on urgency. In the present case I don't see how they could present such a justification. Simon
Re: Recent BIND ports
Le 12-05-25 06:24, Kostas Zorbadelos a icrit : Henning Brauerlists-open...@bsws.de writes: * Kostas Zorbadeloskzo...@otenet.gr [2012-05-25 10:06]: from all relevant discussions I have seen it seems that BIND in base will not be updated to a newer version and unbound has a good chance to be the replacement. The thing is, we need a newer version of BIND for resolving (at least 9.7, preferably 9.8 or in the future 9.9). purely out of curiosity: why? filter--on-v4 (9.7+) (needed now) purely out of curiosity: why?
Re: Recent BIND ports
On 2012-05-25 15:14, Kostas Zorbadelos wrote: filter--on-v4 (9.7+) (needed now) purely out of curiosity: why? Crude workaround for increased levels of IPv6 brokeness in our networks (aka CPE with broken firmware). Needed until the proper solution is given. Interesting, thanks. In any case, if any possible option was already available there would be no need for new BIND versions, or any other software, right? Unbound is replacing BIND in OpenBSD for increased betterness. Stay tuned... Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: Recent BIND ports
On 2012-05-25 15:33, Kostas Zorbadelos wrote: Yes, I have understood that. The question remains: what do you think of ports for recent BIND versions? I am running a hand-compiled BIND 9.9 right now for the DNS64 feature. I'd like to have an up to date port. I don't one to contribute, so I shut up and endure. PS: Initial tests with Nominum's resperf tool are not encouraging. My guess is that it has to do with the lack of threading support (in-kernel) for OpenBSD 5.1. Situation could be improved with the coming rthreads? Of course this is a subject of a different thread when I have more test data. I'd guess that rthreads will play a big role, but this is only a guess. Simon
Re: Watchdog timeout reset in 5.1 on intel nic:s
On 2012-05-11 04:15, Garry Dolley wrote: I now have an amd64 test VM set up, where I installed stock 5.0. I ran a lot of traffic over em0 without any timeouts. That's expected. 5.0 has been running without issue for me for a long time. I also have been trying several -current kernels. As of: OpenBSD 5.1-current (GENERIC) #205: Wed Mar 28 21:40:45 MDT 2012 I don't see any em0 timeouts. I will continue to try newer ones and report back here... Why not just test 5.1? Problems have been reported against 5.1, not -current. Simon
Re: IPv6 and carp(4) problems
Resurrecting an old topic...
On 2011-10-27 16:05, Stefan Rinkes wrote:
I'm currently using a current kernel with following patch:
--- sys/netinet6/in6.c 8 Aug 2011 13:04:35 - 1.93
+++ sys/netinet6/in6.c 27 Oct 2011 19:59:00 -
@@ -2476,6 +2476,14 @@ in6if_do_dad(struct ifnet *ifp)
* NS would confuse the DAD procedure.
*/
return (0);
+#if NCARP 0
+ case IFT_CARP:
+ /*
+ * XXX: DAD does not work currently on carp(4)
+ * so disable it for now.
+ */
+ return (0);
+#endif
default:
/*
* Our DAD routine requires the interface up and running.
It disables DAD on CARP, cause it does not work on normal CARP and creates
false alarms on balancing CARP. Not great, but at least balancing and IPv6
works now.
Looking at the code, DAD should already be disabled on carp interfaces.
As soon as you assign a vhid to a carp interface, a link-local address
is attached. in6_ifattach_linklocal() unconditionally sets IN6_IFF_NODAD
on the interface. Further down it removes it but not for CARP interfaces:
if (in6if_do_dad(ifp) ((ifp-if_flags IFF_POINTOPOINT) ||
(ifp-if_type == IFT_CARP)) == 0) {
ia-ia6_flags = ~IN6_IFF_NODAD;
ia-ia6_flags |= IN6_IFF_TENTATIVE;
}
So all CARP interfaces should have IN6_IFF_NODAD set.
Simon
Re: slightly OT be my own dyndns provider
On 2012-05-08 08:09, Stuart Henderson wrote: One method is to run your own name server and have a way to update the zone database with your dynamically updated entries.[...] Another option is to use generated zone files [...] Alternatively outsource DNS hosting [...] Or you could do a blend, serve things locally at your own server/s and also push updates to an API-based provider[...] Why not nsupdate(8)? Simon
Re: Watchdog timeout reset in 5.1 on intel nic:s
On 2012-05-08 19:08, Per-Olov Sjvholm wrote: It says em1: watchdog timeout -- resetting aol I saw the same on an amd64 VPS from arpnetworks.com. Network was not functional. Backed out. Did not investigate further. /aol Simon
Re: Memory usage of BIND process
On 2012-04-20 07:43, Kostas Zorbadelos wrote: I understand the kernel VM layers are completely different, but how come the named process on OpenBSD for the same load consumes so low resident memory? Also, why VZS RSS on OpenBSD? The general question I am trying to answer is, can BIND utilize all available memory on the system (so I can arrange the amount of memory when I order the servers). IMHO you're asking the wrong questions. Do your users care about VZS/RSS/CPU/load average/whatever? If they don't, why should you? From what you wrote, it seems to me that what you should care about is how many records can fit in the cache and how many queries it can handle per second. Then measure that. Measure the number of records in cache, and measure how many queries it can handle per second. That is, measure *externally observable behavior*. Don't measure irrelevant technical details. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: Memory usage of BIND process
On 2012-04-20 14:07, Kostas Zorbadelos wrote: Eventually you are right. However I am trying to answer the primitive question: should I buy servers with a lot of RAM or not? If BIND cannot utilize more than 4GB let's say, it makes no sense to buy servers with 32GB. The servers' only role will be caching resolvers. A few years back, a colleague had noticed problems in custom compiled BIND we currently use (on Linux), when the process size exceeded 4GB. The server produced a lot of SERVFAIL errors. As a workaround the setting max-cache-size 3G; was introduced in named.conf and since noone investigated further it has remained to this day. Here's a test protocol for you: 1. Set your VM to 6G. 2. Set max-cache-size to 4G. 3. Measure how many records it can store. 4. Set max-cache-size to 5G. 5. Measure how many records it can store. 6. If #3 and #5 differ, you're good. ;) Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: random nat, ftp clients and 425: Securiy: Bad IP connecting
On 2012-02-28 08:23, Stuart Henderson wrote: btw: that random stuff, at least without source-tracking, is likely to break bank websites etc. This is right. Random pools break a lot of things in practice. Do use random it if you're paranoid and don't care about breaking things. Otherwise, the best current practice is to maintain a constant mapping from internal to external source address. Simon
Keyboard mapping
Here's yet another question about keyboard mapping... When I boot bsd.rd and pick the cf keyboard mapping in the installer, everything works perfectly. After I reboot (bsd.mp), the keyboard seems correctly mapped (keys are at the right places), but some keys do nothing (e-acute (not a dead key) and accent dead keys). /etc/kbdtype contains cf. I tried playing with kbd and wsconsctl. Everything seems normal except the above mentioned keys that do nothing. When I switch to us, the keys that did nothing start working correctly, although with the us mapping. What could be different between bsd and bsd.rd that could have such an impact? I include both the dmesg from bsd.rd and bsd.mp. Thanks, Simon OpenBSD 5.0 (RAMDISK_CD) #36: Wed Aug 17 10:27:31 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE real mem = 2138238976 (2039MB) avail mem = 2096250880 (1999MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 09/23/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xf0720 (30 entries) bios0: vendor American Megatrends Inc. version 0905 date 09/23/2009 bios0: ASUSTeK Computer INC. 1005HA acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT SLIC acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 166MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 1, remapped to apid 2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (P0P5) acpiprt2 at acpi0: bus 1 (P0P7) acpiprt3 at acpi0: bus -1 (P0P6) bios0: ROM list: 0xc/0xec00! pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GME Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel 82945GME Video rev 0x03 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured Intel 82801GB HD Audio rev 0x02 at pci0 dev 27 function 0 not configured ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 2 int 16 pci1 at ppb0 bus 4 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 2 int 17 pci2 at ppb1 bus 2 athn0 at pci2 dev 0 function 0 Atheros AR9285 rev 0x01: apic 2 int 17 athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 1c:4b:d6:20:6c:fe ppb2 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 2 int 19 pci3 at ppb2 bus 1 alc0 at pci3 dev 0 function 0 Attansic Technology L2C rev 0xc0: msi, address 90:e6:ba:57:8a:72 atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 11 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 2 int 23 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 2 int 19 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 2 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 2 int 16 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 2 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2 pci4 at ppb3 bus 5 pcib0 at pci0 dev 31 function 0 Intel 82801GBM LPC rev 0x02 ahci0 at pci0 dev 31 function 2 Intel 82801GBM AHCI rev 0x02: msi, AHCI 1.1 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, ST9250315AS, 0002 SCSI3 0/direct fixed naa.5000c500192a178e sd0: 238475MB, 512 bytes/sector, 488397168 sectors usb1 at uhci0: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 Sonix Technology Co., Ltd. USB 2.0 Camera rev 2.00/9.07 addr 2 at uhub0 port 2 not configured softraid0 at root scsibus1 at softraid0: 256 targets root on rd0a swap on rd0b dump on rd0b OpenBSD 5.0 (GENERIC.MP) #59: Wed Aug 17 10:19:44 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE real mem = 2138238976 (2039MB) avail mem = 2093182976 (1996MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date
Re: Keyboard mapping
On 2012-01-23 16:40, Steffen Daode Nurpmeso wrote: If the program you are working with is eight bit clean (ksh(1) doesn't work, csh(1) does), maybe it's the mapping. THANK YOU! Keys work fine in csh, not in ksh. And bsd.rd uses sh IIRC, so that would be the answer. Thanks! Simon
Re: Limit ICMP echo reply
On 01/11/2012 06:39 PM, Limaunion wrote: Hi all! very simple PF question, is it possible to limit the number of ICMP echo replies, like 5/min from any source address ? If you're looking to limit the rate emitted by OpenBSD as a host, check out the net.inet.icmp.errppslimit sysctl. If you're looking to limit the rate forwarded by OpenBSD as a router, then you just apply QoS in pf as usual. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: CARP health check ?
On 01/12/2012 01:18 PM, PP;Q Q P(P8P?P8QP8P= wrote: we are using nagios for monitoring and it is running on separate server. we do not want to monitor server from inside. we want to run run something via ssh and see whether carp peer is dead or not. Give each server it's unique IP address. Use a third IP address for carp. Monitor all three addresses. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: CARP health check ?
On 01/12/2012 01:49 PM, PP;Q Q P(P8P?P8QP8P= wrote: most of our carp clusters run on single address. no spare IP space. That's the root of the problem. Use IPv6 for the non-carp addresses? RFC 1918? rdr on some ports? Otherwise, you'll have to invent a hackish and fragile solution... Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: inet6 autoconfprivacy broken on -current ?
Le 02/01/2012 6:00 PM, Mattieu Baptiste a icrit : On my machine running -current/amd64, inet6 autoconfprivacy seems to broke neighbor sol/adv. I just tested this and it works for me. Sorry. Simon
Re: ping6 bug or feature?
Peter J. Philipp wrote, on 12/04/2011 08:06 AM: Somehere inside ping6 the return address is not checked with the outgoing address and it happily accepts 2001:a60:f074::25 as a valid return address in my case. That's a feature. Think about what would happen when pinging a multicast or an anycast address. I *want* to see any reply coming in, no matter the source address. Simon
How to use /dev/srandom
Hello, I'm trying to use /dev/srandom, but I can't get even a single byte out of it. To reproduce: $ hexdump -n 1 /dev/srandom It just hangs there, sleeping. If I use /dev/urandom instead, it returns immediately, as expected: $ hexdump -n 1 /dev/urandom 000 0069 001 I tried on various routers that have been forwarding packets since forever. I waited a long time for the read to succeed. I tried on OpenBSD 4.3 and 4.6. Am I doing something wrong? Thanks, Simon -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: How to use /dev/srandom
On 2010-09-29 10:36, Theo de Raadt wrote: it is hanging because: 23208 hexdump CALL read(0,0x81ffc000,0x1) It is trying to read too much. A whole buffer, into stdio. So it empties the pool it can have, and then has to wait for more. eventually it does get data, and print 1 char. Thanks! I was using the much slower add printf()s debugging method... I am susprised that hexdump doesn't decide to read less based on the -n argument. Me too! Thanks a lot for your help, that fixes my issue. Simon -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: How to use /dev/srandom
On 2010-09-29 10:49, Theo de Raadt wrote:
Perhaps a posix weenie can look into making hexdump use setvbuf and
adjusting the read requirements for fread() when the length (-n
argument) is specified as being short of the blocksize.
How about this weenie?
Index: display.c
===
RCS file: /cvs/src/usr.bin/hexdump/display.c,v
retrieving revision 1.18
diff -u -p -r1.18 display.c
--- display.c 27 Oct 2009 23:59:39 - 1.18
+++ display.c 29 Sep 2010 15:03:11 -
@@ -300,6 +300,8 @@ next(char **argv)
++_argv;
continue;
}
+ if (length 0 length BUFSIZ)
+ setvbuf(stdin, NULL, _IONBF, 0);
statok = done = 1;
} else {
if (done++)
--
NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca
STUN/TURN server-- http://numb.viagenie.ca
vCard 4.0 -- http://www.vcarddav.org
Re: Source Overview
On 2010-04-21 14:35, Theo de Raadt wrote: They mailed diffs. Not requests for tasks. If you request a task, it means you have no itch to scratch. You're just looking for an excuse to program. And it's often not enough motivation.
Re: Question regarding MSS
On 2010-04-15 12:18, Matthew Sullenberger wrote: I understand the host I am trying to communicate with has its own set of issues, but my question to Misc is that I was under the belief that if either side did not explicitly send a MSS during the handshake the required behavior was to default to 576 for the send MSS. My Assuming you meant 536... understanding was this was the required behavior even with PMTU enabled, however it does not seem to be the case. Am I misunderstanding how this is supposed to work? If I disable PMTU, my box does reduce the Send MSS as I would expect. ...you're right according to RFC 879: HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO ACCEPT LARGER DATAGRAMS. This is a long established rule. THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS FORTY. The default IP Maximum Datagram Size is 576. The default TCP Maximum Segment Size is 536. And also according to RFC 1122: If an MSS option is not received at connection setup, TCP MUST assume a default send MSS of 536 (576-40) [TCP:4]. And also accordint to RFC 1191: A TCP implementation must also store the MSS value received from its peer (which defaults to 536), and not send any segment larger than this MSS, regardless of the PMTU. In 4.xBSD-derived implementations, this requires adding an additional field to the TCP state record. Simon -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: Question regarding MSS
On 2010-04-15 13:46, Matthew Sullenberger wrote: So would this be possibly a bug in the OpenBSD PMTU implementation (the expected behavior occurs and the connection works normally if I disable PMTU) and if so should I be submitting some kind of official report? Maybe. Use sendbug(1). Simon -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: Load Balance Outgoing Traffic and Killing Interface-Specific States
On 2010-03-23 18:54, Daniel Melameth wrote:
Using the example from the PF User's Guide
(http://www.openbsd.org/faq/pf/pools.html#outgoing), what's the best way to
kill all states related to ONE of the route-to interfaces created by the
pass in on $int_if route-to { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2)
}... rule? It is a simple thing to kill interface-specific states
generated by the related pass out on $ext_ifx route-to... rules, but I'm
uncertain of the best way to do this for the first rule.
How about this?
pfctl -k $int_lan -k $ext_gw1
Simon
--
NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca
STUN/TURN server-- http://numb.viagenie.ca
vCard 4.0 -- http://www.vcarddav.org
Re: Load Balance Outgoing Traffic and Killing Interface-Specific States
On 2010-03-23 19:13, Simon Perreault wrote: How about this? pfctl -k $int_lan -k $ext_gw1 This is so wrong, I am ashamed. Simon -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: How to make FTP work from the firewall system?
On 03/15/2010 11:49 PM, Dave Anderson wrote: I'm configuring a notebook which will use PF to protect itself from the environments in which I use it, and would like to have FTP 'just work' on it -- whether it's from an explicit FTP command, from a browser, or embedded in some other program or script. I see two options: 1. pass out 2. ftp-proxy(8) Simon -- DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: How to make FTP work from the firewall system?
J.C. Roberts wrote: match out on ? proto tcp from ? to any port ftp \ rdr-to 127.0.0.1 port 8021 You can't do that. rdr-to only works on input. Without testing it, I don't know how the potential loop can be avoided, or if it even needs to be avoided (note the match out example for isakmp in the pf.conf(5) man page). That example uses nat-to, which only works on output. Simon -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
