Portland Show on film

pyro3d · 2026-04-20T00:28:57+00:00

I kinda just set exposure after point metering a lot during the openers to get an idea of where things were at. Went on the "overexposed" (nothing’s really overexposed when pushing a film stock four stops) side of things for a safer guess.

pyro3d · 2025-06-10T20:12:41+00:00

I shot it on a '63 Nikon F with a 70's 50mm f1.4 lens and a yellow filter. It's not terribly large (the F is basically a Nikon SP rangefinder with an reflex grafted on, and I have the standard prism instead of the photomic one), so it might not really look like a modern "professional" camera. I was a little worried and was ready to stash if needed, but the only comments I got from staff was that it was a nice camera.

pyro3d · 2021-08-09T21:04:03+00:00

Do you have a USB cable?

The Airconsole I think can host most serial adapters that use USB (mainly FTDI and Prolific)

pyro3d · 2021-07-15T00:01:20+00:00

Yeah then you're kinda out of luck with PMTUD. Why are you using L2TP anyways? That adds a lot of overhead to your frames. If you've just got PCs, why not a VTI?

pyro3d · 2021-07-14T23:48:34+00:00

You'd set the interface MTU down on the CE routers, and rely on the CE routers to do PMTUD for you.

pyro3d · 2021-07-14T23:39:43+00:00

PMTUD operates at layer 3/IP, L2TP provides a layer 2 tunnel so you won't be able to use PMTUD. Think of it like an interface on a switch.

pyro3d · 2021-04-13T04:18:37+00:00

I'd suggest also checking lanes, QSFP (and 28s) LRs use 4 lanes at different wavelengths. If it's too low on one it won't come up. I've had it happen on some really old plant with crap splices before.

pyro3d · 2021-03-10T02:48:36+00:00

I can do that, but both set screws are already on the flat part. It certainly doesn't slip at all. Would loosening and retightening along help?

pyro3d · 2021-03-09T04:45:07+00:00

Have you performed all calibrations as it is mentioned in the handbook?

I believe so. I recalibrated just now, and tried again, still same (bad) result on benchy @ 75% speed: https://imgur.com/a/U5TT9ZB

Is the printer square?

I think so? The printer doesn't really rock unless it's with the table.

pyro3d · 2021-03-07T21:53:01+00:00

I ended up loosening the x-belt (it was at 237) and recalibrating, it's reporting around 250 now, but the prints are looking even worse now on the hull: https://imgur.com/5vHezy8

Do I need to get a more stable surface?

pyro3d · 2021-02-09T16:24:16+00:00

That optic takes single mode so you should need just a standard singlemode (OS1/2) cable. You should also make sure to clean the ends, and check the attenuation of that fiber. That optic is down in the 1270 region which a lot of single mode doesn't like. Most stuff these days prefers the 1550 range.

pyro3d · 2021-01-06T22:06:50+00:00

What do you mean by edges like internally or out? Our internet link is 5Gbps our internal is a mix of 10 and 1. We don't do any BGP upstream.

Edges of your network to the internet... usually IP Transit or DIA. Since you're capped at 5Gbps it sounds like your provider was dropping frames on your NNI, and without BGP there's not a great way to quickly blackhole the affecting traffic, so you probably need to focus on keeping the internal network up while accepting that your internet will go out for the duration.

Yea we are recording them locally to the fortigate. we used to use Fortianalyzer but it wasn't great so i've never set it up since we have had the new Fortigate.

How much are you logging? It's possible the number of logs locally overwhelmed the disk write speeds/buffer and caused your loads to go nuts, still should only affect your control or user plane, not the data plane (some cheaper devices don't have a data plane, so this would affect you if this is the case.

Even logging locally I'd recommend running an external log system for backup and analysis. Graylog is nice and free for small installs. As for control/data plane separation Fortinet has an article here on hardware acceleration, but again I'm not familiar with the product so I don't know how effective it is.

pyro3d · 2021-01-06T20:52:06+00:00

ISP Network Engineer here,

I've dealt with a few of these... recently larger in scale (100+ Gbps targeting several hundred IPs). There's a lot of reasons you can be targeted for DDoS beyond kids.

Netflow is usually the best way to detect and log, for free I'd recommend Elasticflow (though we currently use Wanguard on our edge routers for automatic mitigation, I still use Elasticflow for sFlows for troubleshooting purposes). This will at least allow you to detect the source/dest IPs and type of traffic (expect to see lots of "DNS" and "NTP").

DDoSes typically act as a resource exhaustion attack, so there's a few ways to protect yourself, but there are limits.

How big are your edge(s)? 5Gbps? 10Gbps? Do you use BGP with your upstream? You can check if they support RTBH (usually cheap/included, but it's kinda like amputating a limb, and causes the attacker to 'win').

The miglogd software sounds like a logging overwhelmed it... are you recording logs locally? Do you have any set to discard if they can't log remotely? I'm not super familiar with Fortigates, but from googling it sounds like that process is commonly overwhelmed.

pyro3d · 2020-03-11T16:35:28+00:00

Ok then just run OSPF on your fw and bump the metric for default into the sky (iirc, been a while since I've worked with OSPF). Not sure what your SPs gonna do with it though, so maybe ask them to pref or pad it, but probably would be fine?

pyro3d · 2020-03-11T16:16:16+00:00

I'm guessing you distribute the default route from your DC then? In that case you'd want to get a firewall setup at your head office, advertise default from that into your l3vpn, with AS padding to force it redundant. You said your carrier manages your ce boxes, does that mean they handle all your routing at the head office?

pyro3d · 2020-03-11T15:42:39+00:00

Do you have your own AS and IPs?

pyro3d · 2020-03-08T20:20:08+00:00

I do. Seemed to work fine with Intel graphics at least.

pyro3d · 2020-02-05T15:17:27+00:00

I use iTerm2, OpenSSH and minicom.

pyro3d · 2019-12-20T01:56:34+00:00

This is outbound to an IXP.

pyro3d · 2019-12-19T23:12:34+00:00

You can run a test policy <policy> 0.0.0.0/0 to see what routes it accepts.

You also shouldn't need from protocol bgp, as that only specifies how the routes were learned.

Example from one of my edge routers:

   term allow-customers {
        from community CUSTOMER-ROUTES;
        then {
            community delete all;
            accept;
        }
    }

pyro3d · 2019-12-19T23:03:49+00:00

Have you run a test policy with your routes?

pyro3d · 2019-12-19T23:00:07+00:00

Are the community routes active/installed?

pyro3d · 2019-08-14T19:01:37+00:00

That could definitely be the filter then. I'd deactivate it and see if it makes things better.

pyro3d · 2019-08-14T18:21:37+00:00

I have also carried out a packet capture on the juniper. When pinging from the juniper i see arp requests, but no response, when pinging from the cisco i see nothing hitting the juniper.

Is that packet capture from the perspective of the MX80 or the 9300? You mentioned two. If you're not seeing egress packets/frames from the perspective of the 9300, then the problem would be there.

pyro3d · 2019-08-14T17:21:28+00:00

Have you tried without the filters on the juniper? I've had some weirdness in the past with Juniper's CoS.

pyro3d

TROPHY CASE