00:13 <verg> srsly? renaming "bytes" to "octets" in a way that breaks things? great improvement. :/

13:41 <apache2> is verg still here?

13:41 <apache2> 1) a "solver" is a constraint solver used to figure out which packages can be upgraded and which have to be held back.

13:42 <apache2> 2) "bytes" to "octets" in the ipaddr library was to remove the confusion caused by the OCaml compiler introducing a type called "bytes", and the Ipaddr "bytes" functions work on strings.

13:43 <apache2> how/why they settled on "bytes" - no idea.

13:43 <kohi> thanks for the explanation.

13:45 <kohi> this year, every time (so far: 3/3) i try to build a fresh qubes-mirage-firewall i end up running face-first into some opam mess first. X)

13:48 <hannes> .oO(this firewall + nat code, i don't entirely understand (already got it to reassembly ip fragments, but now it can't write the reassembled frames since they're too big for the interface <- and thus need to be fragmented again)

13:49 <hannes> another option would likely be to not reassemble + fragment, but instead do a packet-per-packet forwarding (but somehow this parses full packets -- and it'd only work if the mtu on both interfaces is the same)

13:50 <kohi> not reassembling wont work because you cant really figure out what connection the not-first fragments belong to (the ports info is missing)

13:50 <kohi> so you would need at least some kind of shadow-reassembly-table for mapping even if not reassembling

13:51 <hannes> no

13:51 <hannes> i mean, the ipv4 header contains the ip id which is the same across fragments

13:53 <kohi> and it can do nat-matching based on just that?

13:53 <hannes> i'd assume you can write a nat implementation that uses exactly that.. but then what do i know

13:54 <kohi> i am just applying conventional networking lore there without any clue about the ocaml code involved here.

13:54 <hannes> so, in conventional networking, what would stop you from doing this?

13:55 <hannes> if you receive the first fragment out-of-order, it wouldn't work

13:58 <kohi> afair the problem with mapping just based on ip header is you dont have enough bits (the id is 16 bits) so it might work for smaller setups, but you run into ephemeral-pair-exhaustion much quicker.

13:58 <kohi> whatever works, works. :)

14:00 <hannes> if you assume/require RFC 6864 (use ip id only for fragmented packets), i don't think that's an issue... esp. since mostly there's no fragmented ipv4 frames (i.e. tcp uses path mtu discovery, there are rumours that fragmented packets are broken/filtered across the internet)

14:01 <kohi> as a tdsl-pppoe user i can confirm that pmtudisc is broken on about 1/3 of the interwebs.

14:05 <kohi> btw, mirage-firewall currently breaks pmtu disc entirely. it strips the DF bit.

14:06 <kohi> O_o ... aeh, or not. nope, i guess that got fixed/changed.

14:06 <kohi> sorry. recheck says DF bit stays these days.