<heat>
but it creates a pcap file for what you send out/what qemu sees from your side
<heat>
you can then debug
<heat>
using wireshark, etc
<clever>
yeah, if you do that, then qemu will log the packets from the internal network, before the rewriting
<clever>
ive written code before, that will log that in CI, and allow downloading the pcap files after failure
<sortie>
ebrasca, if you're using SLIRP networking (the default), then from the outside you will see whatever qemu does. You want to capture packets if you want to see what your OS does. If you want your OS to be directly on the network, rather than being proxied by qemu, you can use bridge networking
<clever>
or have qemu log the internal packets directly
<heat>
gosh do not do bridged networking
<heat>
that's the worst idea
<sortie>
I should clarify
<sortie>
I use macvtap instead of a traditional bridge. It's much better for this purpose without the normal risks
<heat>
you *can* and *should* once your network stack is up and running
<clever>
you can also use tap without a bridge
<heat>
it is _much_ harder to debug on a real network
<heat>
qemu handholds you a whole lot
<ebrasca>
Why is bridge bad?
<heat>
much harder to set up, you get real traffic
<clever>
tap without a bridge, is basically just plugging the VM into a 2nd NIC on your machine, and it has no access to the main LAN
<heat>
why is the router rejecting your dhcp requests? dunno, qemu doesn't know either, wireshark is probably clueless to
<heat>
the end
<sortie>
^ What clever said. That's why macvtap is so useful, you can basically put your OS on your LAN as if it was a real machine
<ebrasca>
I like to see things in wireshark as my OS sends it!
<heat>
then use what i told you
eddof13 has quit [Quit: eddof13]
<clever>
ip tuntap add dev "tap0" mode "tap" user "clever"
<clever>
if you run something like this as root, then you get a tap0 interface on the host
<heat>
well, i'm bailing
<clever>
and its setup so qemu can use tap0 without root, if you run qemu as "clever"
<clever>
there is no bridging or dhcp
<heat>
i can't help out if you're out here giving unrelated suggestions that work more like pandora's boxes
<clever>
so you just configure a static ip on both ends
<sortie>
For sortix.org; I create a macvtap as such: if=macvtap && user=sortix_org && if [ ! -e /sys/class/net/$if ]; then ip link add link enp0s31f6 name $if address 00:50:56:00:7C:4C up type macvtap mode bridge; fi && dev=/dev/tap$(cat /sys/class/net/$if/ifindex) && chown $user:$user $dev
<sortie>
Where that is the ethernet address assigned to your VM. Allocate your own. This one is mine and used for a special purpose related to DHCP
<clever>
sortie: ah, thats fairly similar to the example i just gave
<sortie>
Then I start the virtual machine as such: tap=/dev/tap$(cat /sys/class/net/macvtap/ifindex) && qemu-system-x86_64 ... -device e1000,netdev=net0,mac=00:50:56:00:7C:4C -netdev tap,id=net0,fd=10 10<>$tap
<clever>
thats a bit more complex then i was expecting
<sortie>
The end result is that my sortix.org VM is put on the network as if it was a real machine. My data center is configured to serve that ethernet address the IP of sortix.org and the VM goes online on the actual internet, with my own network stack
<sortie>
So if you connect to sortix.org or irc.sortix.org, those IPs communicate directly with the Sortix VM's and their native network stack, no qemu proxying :)
<sortie>
This is all overkill for most uses, but it's handy tech, and I like it because I can say my OS is actually on the internet
<sortie>
ebrasca: But if you're just debugging your stack, you might just want to capture packets like you were suggested :)
<sortie>
Just sharing it all here because macvtap is a very neat trick that people in here might find useful :)
<clever>
sortie: for me, half the time, i'm writing an application that takes qemu's place in the stack (a vpn, or an emulator), so i have to interface with tap directly
<bslsk05>
github.com: mini-rv32ima/mini-rv32ima/network_tap.c at nix · cleverca22/mini-rv32ima · GitHub
<clever>
virtio-net interfaces with the guest, and network_tap interfaces with the host
<clever>
split into 2 files, so i could replace network_tap, when targeting another host OS
<sortie>
Neat :)
<ebrasca>
I don't know why but this time I was able to see FIN packet send by my OS and ACK responce in wireshark.
<sortie>
You're seeing FIN sent by qemu (or rather the linux kernel or whatever host OS you use), after it proxied your connection. That means qemu understood your FIN correctly in this case. Some of your packets may be malformed when they are received by qemu, or perhaps some of the packets got lost. qemu will probably not shutdown(2)/close(2) (causing FIN) the connection until it has received all of your outgoing data leading up to the FIN. Make sure the counters
<sortie>
and windows are all appropriate and such
<ebrasca>
heat: I replaced my network with your line, I don't know if that fixed my thing or it was other reason but thanks!
<ebrasca>
heat: How does qemu handholds you?
<heat>
it is more tolerant of weird shit, it hides you from everyone else's weird shit
<heat>
it does magical things. like a plain old RFC793 tcp implementation on the guest maxes out your bandwidth no problem
<heat>
latency? doesn't exist
<heat>
packet loss? doesn't exist
<zid`>
heat: We forgot to connect, heat. You will not have the drink.
<zid`>
packet loss*
<heat>
zid`: SYN
<heat>
zid`: SYN
<heat>
zid`: SYN
<heat>
zid`: SYN
<ebrasca>
I am implementing rfc9293
<heat>
that's a good idea, but 9293 doesn't include the high speed extensions
<heat>
which are absolutely pivotal for like, 1MBps+ speed when you have a good amount of latency
<ebrasca>
After I end 9293 , what do you recomend todo next?
<heat>
depends on your goal?
<heat>
for network performance, rfc1323 is a must (window scaling), rfc2018 is a must (selective acks)
<ebrasca>
I like at the moment to have a 100% compliant TCP/IP that can work with 100mbps
<heat>
then you have other stuff like: do you want to do lots of sending and not clog up the network? slap a good tcp congestion control algorithm on it
<heat>
100% compliant is impossible
<heat>
not even linux is 100% compliant
<heat>
(100% compliant is also, for several reasons, not fast)
<ebrasca>
I have plan to use Reno and then see from there
<heat>
there is a lot of residual knowledge that the RFCs won't tell you
<heat>
like "when should I send out ACKs", where the RFCs give you a very simplistic and poorly performing algorithm
<ebrasca>
I relly use the RFCs a loot to know what todo
<ebrasca>
I asume 9293 is at least a good start
neutrino777 has quit [Quit: WeeChat 4.6.1]
<heat>
well, yes, you implement the base TCP functionally
<heat>
so it will work compatibly, or at least try
<clever>
i stumbled upon this recently, `Why do downloads look like waves?`
<clever>
its to do with tcp window scaling
<heat>
it has more to do with congestion windows
<heat>
you bump the congestion window up while you can, then lose some data, so you take it down a notch, then you bump it up again, then lose some data, repeat
<clever>
been a while since i saw the vid, but it seems to ramp up rapidly at first, backs off hard on the first lost packet, and then ramps up slowly
<heat>
where "lose some data" is the natural effect of either a fully saturated link or (commonly) the router dropping your packets because you ran out of bandwidth
<heat>
if you don't ever see a wave it's probably either because your TCP window size is too small, or you have infinite bandwidth (congratulations)
<clever>
and this leads to buffer bloat, where old crappy routers would buffer too many packets, and then drop packets on the lan-rx side, and slowly trickle them out to the ISP
<clever>
which causes your latency to spike when your saturating the link
amadaluzia has quit [Ping timeout: 244 seconds]
amadaluzia has joined #osdev
netbsduser has quit [Ping timeout: 244 seconds]
nyah has quit [Remote host closed the connection]
amadaluzia has quit [Ping timeout: 248 seconds]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
simjnd has joined #osdev
simjnd has quit [Ping timeout: 252 seconds]
\Test_User has joined #osdev
amadaluzia has joined #osdev
<zid`>
heat: I have infinite bandwidth, by which I mean the other end does
<zid`>
compared to me
<heat>
50 years of networking: hmm yes congestion is really hard how about we do all these fancy algorithms to attempt to control it
<heat>
zid: haha i have inifinte bandwidth just send le packet!!!
<zid`>
Their end can drop it and they can sort it out
<zid`>
from my end I just have to download packets as fast as I can, ez
<zid`>
If they don't show up or they show up with timing gaps, that's their fault not mine
<nikolar>
obviously
freakazoid332 has joined #osdev
simjnd has joined #osdev
<heat>
btw mptcp goated
simjnd has quit [Ping timeout: 260 seconds]
amadaluzia has quit [Read error: Connection reset by peer]
amadaluzia has joined #osdev
<zid`>
mr. portugal tcp
<heat>
YES
<zid`>
I'm in a spaceship mood
<zid`>
let's see if I can remember how to play elite
<nikolar>
heat: what's an mptcp
Turn_Left has quit [Read error: Connection reset by peer]
Fingel has quit [Ping timeout: 252 seconds]
<gog>
when did i get here
<gog>
this is not my beautiful house
<nikolar>
you turned left instead of right
<nikolar>
a rookie mistake
Fingel has joined #osdev
<pog>
letting the days go by (let the water hold me down)
gog has quit [Quit: byee]
simjnd has joined #osdev
simjnd has quit [Ping timeout: 260 seconds]
simjnd has joined #osdev
Lucretia has quit [Remote host closed the connection]
svm is now known as msv
[Kalisto] has quit [Quit: No' vemo']
<heat>
nikolar: multipath tcp
<nikolar>
ah
[Kalisto] has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]