tecepe has quit [Remote host closed the connection]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<cyrozap> rqou, felix_: If you're interested in high-end (i.e., LTE) baseband hacking, the one in the MT6735 in the BLU R1 HD uses a Cortex-R4 and its source code has been leaked on GitHub.
<cyrozap> felix_: also, if you want to RE wifi firmware, the recent abgn/ac stuff from Mediatek has a good GPL'd driver and very small firmware (~100k)
<rqou> in the past Ralink/Mediatek wifi chips had crappy performance
<rqou> is it better now?
<cyrozap> wait, crap
<rqou> there are too many crazy german hackers named felix :P
<cyrozap> Apparently, he's not the same felix (thanks, /whois)
<cyrozap> rqou: But anyways, that video I just posted is where I got this info from.
<cyrozap> I mean, the stuff about the WiFi
<rqou> i think i've seen the slide deck
<rqou> at one point or another
<cyrozap> No idea if performance is good
<rqou> interesting thing re: FCC is that wifi bands overlap ham radio bands
<rqou> so technically as long as I ID I can test whatever I want
<rqou> except encryption
<cyrozap> rqou: Or you could just keep your power low enough on any other band and no one will care :P
<rqou> but I want to be that asshole using HT40 on 2.4GHz :P
<cyrozap> By "low enough" I mean ~1mW or less and keep the devices right next to each other
<cyrozap> HT40 on 2.4GHz isn't any good anyways because of the interference
<whitequark> rqou: huh?
<whitequark> aren't all WiFi bands ISM anyway?
<cyrozap> rqou: I do OTA digital TV broadcasting with my bladeRF every so often and its output is low enough that it has incredible difficulty going through walls.
<whitequark> and can't you do whatever the fuck you want on ISM bands as long as it's quiet enough?
<rqou> i thought FCC Part 15 said that modifying transmitters is not allowed?
<cyrozap> whitequark: Technically you still need a license, but yeah, just stay quiet and no one will bother you.
<whitequark> huh
<rqou> you can also build up to five devices of a particular design for personal use
<cyrozap> whitequark: Sorry, I meant you need to certify your device
<rqou> but i don't know of hacking firmware is included in that
<whitequark> rqou: interesting
tecepe has joined ##openfpga
<rqou> operating under FCC part 97 ham radio rules also allows stupid tricks like using channel -1
<rqou> because the ham and ISM bands don't completely align
<rqou> interestingly the JP-only channel 14 is still forbidden
<cyrozap> rqou: The big things you don't want to interfere with are military/weather radar
<rqou> you don't want your 5G WiFi making huge laserbeams appear on the local airport's weather radar? :P
<cyrozap> Stay away from those and the likelihood of getting a letter/visit from the FCC party van are very small
<rqou> whitequark: iirc HK actually has much stricter radio regulations but much more lax enforcement
<rqou> aka no enforcement at all
<whitequark> wonder if I could make a radar in the ISM part of the 5G band
<rqou> i'm pretty sure hobbyists have done that
<whitequark> there was like a single guy who made a SAR
<whitequark> pretty advanced stuff imo
<cr1901_modern> SAR?
<rqou> synthetic aperture radar
<rqou> *insert math here* :P
<rqou> overall i'm quite disappointed how we don't have more harmonized band plans
<rqou> the chaos of figuring out which frequencies are legal in which region is kinda silly
<whitequark> yeah we need worldgov
<rqou> i thought that was called the united states :P
<whitequark> no thats the worldhell
<cr1901_modern> Is there a difference?
<azonenberg> whitequark: i am very interested in one day making a radar in a ham/ism band
<azonenberg> i was thinking 5 or 10 ghz
<rqou> er, according to arrl's chart pulse emissions are not allowed in 10ghz
<rqou> i don't know if that will matter or not
<whitequark> mmmhm
<whitequark> maybe in extremely distant future
<azonenberg> rqou: i forget if there's an ISM band there or not
<azonenberg> You might also be able to cheat by making the pulses morse with your callsign or something :p
<azonenberg> But 5G is an ISM band so you could avoid all the ham regs that way
<azonenberg> if you stay w/i ISM power limits
<rqou> wikipedia says there's no ism band at 10ghz
<rqou> there is one at 5.8
<rqou> there are ham bands in both
<rqou> the 5.8ghz ham band does allow pulse emissions
<azonenberg> oh interesting
<azonenberg> So you could even do it in the ham bands if you could figure out a way to ID
<rqou> probably
<rqou> of all the 1GHz+ bands, only 10g doesn't allow pulse
<rqou> i wonder why?
<azonenberg> Alternating long and short pulses with your callsign in morse would probably be OK
<azonenberg> Very curious
<rqou> in general the ham band mode restrictions seem to be very curious legacy baggage
<rqou> e.g. the arrl chart has a range in the 220mhz band labeled "Fixed digital message forwarding systems only"
<rqou> 50mhz and 144mhz have tiny CW-only ranges
<rqou> there's also the weird channelized 5.3mhz band
<azonenberg> rqou: the main ones that make sense are limiting bands w/ ionospheric propagation capability to higher class licenses
<azonenberg> just b/c if you screw up you take out a lot more users
<rqou> sure, but I don't really see the point of the split between "RTTY and data" vs "phone an image"
<azonenberg> rqou: that, yes i agree
<azonenberg> the most that i see making sense in other bands is restricting max b/w per emission
<azonenberg> so you dont make one device with a massive spread spectrum output that DoS's the entire 2m band
<azonenberg> or something
<rqou> but afaik there aren't really b/w limits
<rqou> spread spectrum has its own lower power limit though
<azonenberg> rqou: there are implicit b/w limits iirc
<azonenberg> like, analog audio has a specified max b/w
<rqou> yeah, google found a thing stating there are symbol rate limits
<azonenberg> so if you restrict something to analog audio
<azonenberg> that does that
<rqou> according to this guy (http://www.nu9n.com/apologetics_2.html) there's not explicit b/w limits even for analog audio
<azonenberg> oh?
<rqou> tl;dr he experiments with running 6khz ssb instead of the normal 3khz
<azonenberg> i mean it'd be a bit of an a-holeish move if you were to transmit CD quality phone emissions with like 40 kHz b/w :p
<azonenberg> Regardless of whether technically legal
<rqou> sure, but that's covered by various good practice/don't be a dick provisions
<azonenberg> i thought there was a clause in 97 saying that you couldn't use more bandwidth or power than reasonably necessary to accomplish a given communication though
<azonenberg> so that might imply a de facto b/w limit
<rqou> yes, so the guy argues that if you consider that the given communication is to send 6khz of audio bw, then you need 6khz ssb to do that
<rqou> if you define the given communication to be only 3khz, then you only need 3khz
<azonenberg> interesting
<rqou> one of the paragraphs here (http://www.arrl.org/files/media/News/ItSeemsToUs.pdf) seems to also imply that you can bypass the digital symbol rate limits by just using a ton of subcarriers
<rqou> so you can really be an a-hole and fill an entire HF band with OFDM carriers
<azonenberg> Lol
<rqou> the HF bands are so narrow that you can probably even design a radio that floods multiple bands at once :P
<azonenberg> So speaking of broadband stuff
<azonenberg> I would love to build a wide b/w SDR for the ham bands
<azonenberg> Something that can, for example, monitor the entire 2m band at once
<azonenberg> with flags set on half a dozen local repeaters
<rqou> doesn't that exist already?
<azonenberg> and rather than scanning, actually mix the audio together
<azonenberg> So it sounds like i have two radios in the room
<azonenberg> then if i hear something i want to pay attention to on one or the other, just turn down the volume on one channel
<rqou> wouldn't one of the problems with this be higher noise?
<azonenberg> Dont know
<azonenberg> I feel like you could probably reject noise pretty well if you had tone squelch
<azonenberg> Speaking of which, if you had a good buffer
<azonenberg> you could also do ex-post-facto tone squelch
<azonenberg> basically add 100ms or so of latency to the signal and open the squelch as soon as the tone starts
<azonenberg> even if it takes you 100ms to lock to it
<rqou> trolling: the only reason this can't exist is because the old farts don't like computers :P
<azonenberg> i think you're a lot less likely to notice a small lag in the signal than you are to notice the beginning of a signal getting chopped off
<azonenberg> Which is what happens with TSQ now
<azonenberg> since the squelch stays shut during the sync period
<rqou> huh i never noticed that since i don't really operate at all :P
<azonenberg> Another example of something you could do that might be useful (but would require a LOT more signal processing, probably a PC vs a HT - not a problem for HF bands that are typically big and not super mobile due to the antenna)
<azonenberg> Simultaneously RX on say a HF band, local VHF repeater, and UHF simplex
<azonenberg> silently
<azonenberg> with speech recognition looking for your callsign in phone, plus some DSP looking for your call in morse
<azonenberg> and if present, automatically open the squelch for that channel
<azonenberg> or make a beep, or something
<rqou> so one of my infinite pet projects is to duct tape the tegra x1 module thing along with a ham radio
<azonenberg> kinda like an IRC highlight
<rqou> that's probably powerful enough
<azonenberg> while lurking in a dozen channels
<azonenberg> could be quite useful esp in an emcom situation where you have a lot of different organizations you might be trying to keep tabs on
<rqou> the reason i obtained the em7355 wwan module was actually to pair it with a tegra x1
<rqou> but then i discovered that the pcie m.2 keying didn't match
<rqou> and i haven't gotten around to spinning the adapter board yet
<rqou> because the em7355 also gives you gps
<rqou> offtopic: somebody should RE the tegra early boot code
<rqou> the jetson tx1 is completely unfused so you actually can alter the early boot code
sharebrained has quit [Ping timeout: 260 seconds]
<rqou> offtopic: is there a good debugger for linux that is well-suited for RE?
<rqou> e.g. a linux clone of ollydbg?
m_w has joined ##openfpga
<whitequark> lol
<whitequark> expecting linux to have an usable debugger. so cute
<digshadow> azonenberg: interesting
digshadow has quit [Ping timeout: 265 seconds]
sharebrained has joined ##openfpga
digshadow has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
m_w has quit [Quit: leaving]
amclain has quit [Quit: Leaving]
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
<pointfree> rqou: edb is supposed to be a Linux clone of ollydbg https://github.com/eteran/edb-debugger
<rqou> oh wow
<rqou> thanks
<rqou> just needs to gain arm/aarch64 support :P
<digshadow> pointfree: hmm interesting. Have you used it / like it?
<pointfree> digshadow: I haven't used it much yet. I discovered it recently.
<pointfree> rqou: It looks like edb itself won't run on ARM, but debugging ARM executables (and others) should work because it now plugs into capstone.
<rqou> oh interesting
<rqou> that's all i really wanted anyways
<rqou> just need to potentially duct tape in support for gdbserver
<rqou> digshadow: C64 SID got vectorized? when?
<rqou> i'm aware it was decapped a while back
massi has joined ##openfpga
<rqou> didn't realize there was a full vector
Bike has quit [Quit: cyst]
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 250 seconds]
scrts has joined ##openfpga
massi has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 244 seconds]
scrts has joined ##openfpga
<felix_> cyrozap: no, thats not me; haven't made a talk at the big ccc conference yet
<felix_> cyrozap: the lte chip i was poking was some qualcomm one which has an arm core and two hexagon cores
<felix_> i also have some mediatek ac wlan card here, but it's 2x2 mimo only and iirc they don't have 3x3 mimo ones
kuldeep_ has quit [Ping timeout: 240 seconds]
<rqou> offtopic: github thinks my miscellany repo (https://github.com/rqou/miscellany, mostly config files) is 100% shell
<rqou> i wonder how that heuristic works?
<azonenberg> look up the linguist project
<azonenberg> i had to add some ignore properties for it to not think my antikernel repo was 98% kicad
<azonenberg> b/c the graph is weighted by kB of each file type
<rqou> i don't really care what this repo is detected as
<rqou> "config files" isn't a really useful category
<azonenberg> and kicad files were big vs source :p
<azonenberg> yeah
<rqou> anyways, i finally stopped procrastinating on my "how to configure postfix" article
<rqou> it's already got 3k words
<rqou> and it still hasn't started explaining in detail how stuff works in my configs
<rqou> email is ridiculously hard
<azonenberg> lol does it need to be?
<azonenberg> like, not the current tools/protocols
<azonenberg> is there an inherent reason why sending textual messages to a user is difficult?
<rqou> yes, because exchange and lotus notes exist :P :P
<azonenberg> among other things, i think we should remove the whole thing of relaying SMTP in a "mail v2" system
<azonenberg> messages should be buffered clientside if the server is unreachable
<azonenberg> and sent directly to the target user's mail server
<azonenberg> We don't live in the dark ages where you'd go onlnie for an hour a day to move traffic
<azonenberg> even if you're mobile, your mail server is likely online 24/7
<rqou> but mail v2 still needs to have an x.400 bridge just for exchange :P :P
<azonenberg> no, exchange needs to implement support for it :p
<azonenberg> So rather than me connecting to some random smtp server my ISP runs, which later pushes stuff to gmail
<azonenberg> i should just connect directly to incoming.gmail.com
<rqou> like how they added smtp? i heard exchange basically still thinks in terms of x.400 internally
<azonenberg> And the message should be signed with a certificate that proves it was sent from azonenberg@example.com
<rqou> we haven't even gotten this part figured out for web pki, let alone email :P
<azonenberg> (rather than me using user/pass login to the clientside mail server)
<azonenberg> It's quite straightforward, i think
<azonenberg> recipient's server verifies mail signature against my public key it has cached
<azonenberg> If this is the first time i've sent mail to that domain recently, it asks my domain's mail server for my key
<azonenberg> via a HTTPS GET request or something well defined, that returns a public signing cert
<rqou> in theory this should be simple
<azonenberg> If the message was signed by that cert, it trusts that I indeed originated the message and thus it's not spam
<rqou> but what about silly footguns that appear everywhere
<azonenberg> The sig doesnt even have to cover message content
<rqou> like e.g. my email address has a "right-to-left embedding" in it :P
<azonenberg> rqou: it's a sequence of bytes
<rqou> this doesn't solve the phishing problem
<azonenberg> in utf-8 or something
<azonenberg> phishing is a human problem, not a protocol problem
<azonenberg> i can phish someone by smoke signals
<azonenberg> or do you mean email addresses that look identical but arent?
<rqou> iirc there was some weird way that the bidi algorithm interacted with dots such that you could make fake file extensions
<rqou> i presume you can use that to fake tlds as well
<azonenberg> you could solve that *specific* issue by requiring the entire email be either rtl or ltr
<azonenberg> the entire address*
<azonenberg> But in general i think it's better solved by atuhenticating the user
<azonenberg> not the address string
<rqou> but then you can't have <something in hebrew>@latin-name.il
<azonenberg> by means of pgp or something
<rqou> authenticating users is even harder than authenticating addresses, isn't it?
<azonenberg> So, there's a couple of problems
<azonenberg> #1: verify the message came from a valid user at the sending domain (really only useful for anti-spam, like smtp auth now)
<azonenberg> This can be solved by having a client cert that the sender's mail server supplies to anyone who asks
<azonenberg> and signing outbound messages with it
<azonenberg> So an incoming server will discard as spam anything not sent by a valid cert, you can then have blacklists of certs or domains that are known spammy
<azonenberg> #2: verifying the message came from a specific user
<rqou> how does this interact with the typical email monkey wrenches of mailing lists and forwarders?
<azonenberg> Forwarder: strip existing sig, forwarding server re-signs with a cert of its own
<azonenberg> after patching the source address
<azonenberg> ditto for a mailing list, it re-signs the message with the listserv's signature
<azonenberg> the goal here is not to auth the message to a specific account
<azonenberg> only to auth that it came from someone that domain declared is a valid user
<azonenberg> you can then decide via blacklists to trust that domain to make that declaration or not
<rqou> i thought patching the source address was unpopular because (reasons I haven't fully researched)
<azonenberg> Source address, reply-to address, whatever
<azonenberg> you modify metadata as necessary
<azonenberg> then re-sign with the listserv's key
<azonenberg> for each outbound copy of the message
<rqou> iirc the particular interaction of current MUAs and listservs works poorly when rewriting address
<rqou> but this is an implementation problem
<azonenberg> recipient's mail server then verifies that the message was signed by the listserv
<azonenberg> and that it trusts the listserv's domain
<azonenberg> and you're good
<azonenberg> anyway #2 is validating the message came from a specific user
<azonenberg> this would be a signature over a subset of headers and payload (so not list headers etc)
<azonenberg> from the user's key, which may or may not be the same cert they auth for antispam with
<azonenberg> You might be able to combine the two, effectively folding DKIM and PGP into one
<azonenberg> or have one master key per user and subkeys for each purpose
<azonenberg> So now you can bind messages to keys, reject messages not from a specific key, and reject keys from untrusted domains
<rqou> but we've already had PGP+DKIM for a while
<rqou> it's an adoption problem
<azonenberg> and yes, but for a next-gen protocol you'd mandate it
<azonenberg> and not even support unsigned messages
<rqou> it's not clear you really do need a new protocol for this rather than just changing conventional behavior of smtp
<rqou> and maybe introducing some new headers or something
<azonenberg> I'm sure you could bolt it on top
<azonenberg> the question is if we're better off throwing out the cruft like sendmail
<azonenberg> and making something new without all of the 1980s baggage
<azonenberg> just like needs to be done with the x86 ISA
<azonenberg> yes, you can make great things with it
<azonenberg> no, you shouldn't :P
<azonenberg> intel missed their chance to massively streamline it when x64 was designed
<rqou> they tried and got itanic :P
<azonenberg> i know :p
<azonenberg> and amd missed the boat
<azonenberg> what they SHOULD have done was create a new architecture as follows
<azonenberg> In 32-bit mode: behavior identical to current 86
<azonenberg> x86*
<rqou> imho x86_64 is even weirder than 32-bit
<azonenberg> in 64-bit mode: support a small subset of the old instructions, extended to 64 bit pointers, plus some new ones
<azonenberg> If a 64-bit OS wants to context switch to 32-bit mode and run a legacy app, it has all the old insns
<rqou> how did mips do 64-bit?
<azonenberg> but in long mode, they don't work
<azonenberg> So you get full compat with existing apps
<azonenberg> never add new insns to the 32-bit spec
<rqou> i heard that 64-bit mips kernels with 32-bit userspaces are really common
<azonenberg> And announce that in ~10 years, you'll be deprecating the 32-bit mode entirely
<azonenberg> and users will have to emulate any 32-bit binaries they still have left
<azonenberg> (as in, remove them from the CPU)
<azonenberg> and the CPUs will then boot up in long mode
<azonenberg> from the get-go
<azonenberg> this provides an ample transition period and keeps new code cruft-free since all of the old instructions don't work in long mode
<rqou> heh, afaik intel VT was originally only supposed to support 32-bit and 64-bit
<rqou> 16-bit got added back
<rqou> :P
<azonenberg> and i dont know how mips does it
<azonenberg> i've never done 64-bit on mips
<azonenberg> the beefiest mips i've done dev on had 128KB of RAM :p
<azonenberg> And came in a 100-TQFP :p
<rqou> afaik for VT people really wanted to run their old bootloaders and stuff
<rqou> some possibly-false leaked info claims that n64 worked that way where it was mostly 32-bit on a 64-bit cpu
<azonenberg> Don't know
kuldeep_ has joined ##openfpga
<rqou> it seems in general nobody really did a good job of adding 64-bit :P
<azonenberg> lol
<rqou> s390x maybe?
<azonenberg> no point on something with <4GB of usable address space
<azonenberg> (including memory mapped IO and actual system ram)
<azonenberg> so below 1-2GB of RAM no benefit
<azonenberg> except maybe better ASLR
<rqou> hmm i wonder if embedded will ever get ASLR :P
<azonenberg> lol half the embedded stuff i see doesnt even have NX
<rqou> does linux on <generic shitty ipcam or whatever> do ASLR/NX?
<azonenberg> depends on how old the kernel and cpu is
<azonenberg> f.ex i don't think an arm926 can do nx
<rqou> btw you're going to love nintendo's "interesting" aslr on the 3ds
<rqou> it does aslr on physical addresses only
<rqou> with fixed virtual addresses
<rqou> you are free to now wonder wtf is going on :P
<azonenberg> why?
<azonenberg> lol
<rqou> hint: it also only does it with a hardcoded list of games
<azonenberg> wut
<rqou> it turns out that the GPU in the 3ds has a dma command
<rqou> and this command has no bounds checking
<azonenberg> So it's meant to prevent malicious dma's
<rqou> yes
<azonenberg> lol
<azonenberg> no bounds check
<rqou> the more hilarious part is
<rqou> there actually is a bounds check
<rqou> various parts of the kernel code/data are protected with a hardcoded range
<rqou> the hackers who discovered this summed it up as:
<rqou> nintendo realized this dma was an attack vector, but couldn't afford an iommu or something
<rqou> so they added a basic mitigation
<azonenberg> Makes sense
<rqou> that doesn't actually mitigate against anything
<azonenberg> lol
<rqou> iirc what was found was that various kernel heaps were not in the protected region
<azonenberg> Because an iommu is so many gates compared to a cortex-m3
<azonenberg> much less an A9
<azonenberg> or whatever A-series they run there
<rqou> it's an ARM11
<rqou> the 3ds has a ridiculous number of processors
<azonenberg> lol
<rqou> 4x ARM11
<rqou> 1x ARM9
<rqou> 1x ARM7???
<azonenberg> also, i need to get back to bed
<rqou> 1x GPU
<rqou> 1x DSP
<rqou> 1x xtensa wifi thingy
<rqou> 1x uC for PMIC stuff
<rqou> and these are the ones that people have found the ability to poke the code on
<rqou> i'd love to see a block diagram of the whole system just to understand how insane the bus bridges must be
<rqou> because the memory maps change depending on if you are in 3DS/DSi/NDS/GBA mode
azonenberg_work has quit [Ping timeout: 244 seconds]
azonenberg has quit [Ping timeout: 258 seconds]
azonenberg has joined ##openfpga
<rvense> rqou: what, they just like shoved their entire product history in one box?
<rqou> basically
<rvense> sounds grape
<marcus_c> I thoght they dropped GBA compat in DSi and later?
<rqou> DSi dropped it, 3DS somehow got it back
<rqou> as far as anyone can tell they even managed to get Qualcomm Atheros to put some emulation logic for the old NDS Mitsumi wifi into a custom chip
<rqou> old DSi boards just had both an Atheros wifi and a die shrink of the old Mitsumi wifi sharing an antenna
azonenberg_work has joined ##openfpga
<gruetzkopf> well
<gruetzkopf> they put gba game rom area into main ram and map it to the correct address range
talsit has left ##openfpga [##openfpga]
Bike has joined ##openfpga
azonenberg has quit [Ping timeout: 258 seconds]
azonenberg_work has quit [Ping timeout: 252 seconds]
azonenberg_work has joined ##openfpga
tecepe has quit [Ping timeout: 248 seconds]
tecepe has joined ##openfpga
azonenberg has joined ##openfpga
scrts has quit [Ping timeout: 250 seconds]
scrts has joined ##openfpga
azonenberg has quit [Ping timeout: 258 seconds]
openfpga-bb has quit [Ping timeout: 260 seconds]
openfpga-bb has joined ##openfpga
azonenberg has joined ##openfpga
Marex has quit [Ping timeout: 250 seconds]
azonenberg has quit [Ping timeout: 258 seconds]
Marex has joined ##openfpga
openfpga-bb has quit [Ping timeout: 260 seconds]
azonenberg_work has quit [Ping timeout: 260 seconds]
openfpga-bb has joined ##openfpga
digshadow has quit [Quit: Leaving.]
azonenberg has joined ##openfpga
azonenberg_work has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
m_w has joined ##openfpga
<rqou> huh, i just noticed that github has a license autodetection thing, and it's wrong
<rqou> it's detecting 0BSD as ISC
<whitequark> is 0BSD OSI-approved?
<rqou> 0BSD doesn't have the "provided that the above copyright notice and this permission notice appear in all copies." part
<rqou> i don't know about OSI approval
<whitequark> rqou: oh
<rqou> whitequark: yes it is: https://opensource.org/licenses/FPL-1.0.0
<whitequark> good
<rqou> whitequark: I didn't realize how shitty lwip was
<rqou> (from your twitter)
<rqou> why does it still seem popular for random embedded thingies?
<felix_> if it's ok to link against gpl software or to pay some money, i'd rather use picotcp
<whitequark> yes, we use lgpl and so we can't use picotcp
<whitequark> rqou: there are no other real options
<whitequark> there's one unreleased BSD stack of high quality that we'll migrate to
<whitequark> but like I said, unreleasde
<rqou> iirc there's also uIP
<rqou> which is probably also shit
<whitequark> it's completely useless
<felix_> uip is even less useable than lwip