Sep 30, 2019 03:54
It seems perfectly reasonable to me to be using a disabled parking spot even if the disabled person is staying in the car. Unexpected events could happen meaning the person would need to leave the car. And without the extra space available in the disabled spot the person might not be able to leave the car.
 
Sep 2, 2019 14:31
"start the backup" does not belong on the list. Backups is not something that you only do when you happen to have some time left over. It is something which needs to happen automatically regardless of whether anybody is paying attention to it or not.
 
Feb 22, 2019 07:59
When it comes to the ground connection it's worth noting that though the depicted plug has a ground connection whether you actually get a ground connection when using it depends on the socket. The plug is a hybrid designed to work with both the sockets used in Germany and France. The same plug is commonly found on equipment sold in Denmark, but when it's used in a Danish socket you will not get a ground connection. The plug is in fact so common on equipment sold in Denmark that even most employees in electronic stores aren't aware that it isn't a Danish plug.
 
Feb 5, 2019 23:41
And how any other piece of software decodes protocols is irrelevant to the discussion.
Feb 5, 2019 23:40
All I have said anything about in this thread is how Wireshark decodes traffic.
Feb 5, 2019 23:40
Most of those comments in this thread have been completely misrepresenting what I said.
Feb 5, 2019 23:40
There are lots of protocols that you can mix like that. But that's not what this thread is about.
Feb 5, 2019 23:39
@user71659 But that still doesn't say anything about how Wireshark decodes the traffic. I have put a Host header in SSH traffic to get around some ISPs lack of IPv6 support.
Feb 5, 2019 23:38
@user71659 Finally a comment that actually respond to what I was saying. Yes it turns out that HTTP/1.1 404\n in the response will cause Wireshark to treat the traffic as HTTP, but a well formed GET command in the request won't even if that contains HTTP/1.1. Just goes to show that heuristics aren't accurate. And it is possible in certain scenarios to construct traffic which can be decoded as more than one different protocol, so heuristics will never be accurate.
Feb 5, 2019 23:38
@user71659 What are you even trying to say? What I have been saying all along is that Wireshark does not show HTTP in the Protocol column when the connection goes to port 8060. I just tested myself with the exact query copied from the question, and Wireshark shows me TCP 221 GET /dial/com.spotify.Spotify.TVv2 HTTP/1.1 [TCP segment of a reassembled PDU]. Notice how it says TCP not HTTP.
Feb 5, 2019 23:38
@LightnessRacesinOrbit First half of that post just says look at what's in the packet and apply the decoding which the relevant protocol standard says to use. The rest of the post suggests it will use the information from some of the analyzed packets to deduce which protocol to analyze other packets as and sometimes just try a bunch of different protocols to see which can decode it without producing an error. I have used Wireshark in situations where those two later approaches should have worked, but they didn't. So I doubt that post is entirely accurate.
Feb 5, 2019 23:38
@Ghedipunk I don't expect Wireshark to make such guesses. You can always tell Wireshark what protocol to decode something as. No need to try to make guesses. And if the OP did in fact ask Wireshark to decode the protocol as HTTP, that's something which the question should have mentioned.
Feb 5, 2019 23:38
@LightnessRacesinOrbit That's not my point. My point is that Wireshark decides to decode the traffic as HTTP and shows it as HTTP rather than showing it as TCP and a port number. I wouldn't expect Wireshark to do that if it wasn't on port 80.
Feb 5, 2019 23:38
There is something inconsistent about the output you provided. The summary of the packet doesn't specify port numbers, but given that it says HTTP I'd assume the destination port is 80. However the request sent by the client says Host: 192.168.1.64:8060 which has a different port number. Either the client is sending requests that are inconsistent, or you left out some potentially relevant information.
 
Feb 1, 2019 07:47
Beware of possible confirmation bias. You may be expecting fasting to be causing Charlie to make mistakes. Then you go look if Charlie is making mistakes and you find some. But what's a mistake and what's not is sometimes subjective. And you might not know how many mistakes another employee would have had if they had been assigned the same tasks. This is not to say your assumption is incorrect, it may very well be correct. But you need to look for objective measures of performance. And remember to focus on the performance not the perceived reason, which shouldn't be important to you.
 
Jan 27, 2019 22:59
I haven't heard the term sedecimal before. A search for the term suggests that it is synonymous with hexadecimal.
Jan 27, 2019 22:59
I do not have a 6502 to do any testing on.
Jan 27, 2019 22:49
Even with the presence of BCD instructions I doubt a decimal floating point implementation would achieve the same performance as a binary implementation.
Jan 27, 2019 22:48
The question doesn't ask about the reason for this design choice, neither does it state any assumptions about performance. It makes a statement about the presence of BCD instructions and express a mild surprise that binary floating point was chosen.
Jan 27, 2019 22:30
@Raffzahn How a hardware implementation of decimal floating point would perform is irrelevant to the discussion anyway since I am pretty sure the 6502 didn't have one. The question was about design choices when implementing code for a specific CPU. You were the one to bring performance of a hypothetical piece of hardware into the discussion. And how such a hypothetical piece of hardware would perform is of no importance when designing software for a specific existing piece of hardware.
Jan 27, 2019 22:26
@Raffzahn You say there is no difference. I say it depends on the hardware. I do not have a 6502 to test on. And I made no specific claim about the performance of either on a 6502 other than saying that floating point is likely faster than decimal. What I did say is that there is a difference on a modern CPU. I just tested on an i3 CPU and found floating point calculations to be at least 100 times faster than decimal. An actual measured difference of a 100-fold slowdown does not match your claim of no difference.
Jan 27, 2019 22:26
@Raffzahn There are architectures which have instructions to operate directly on numbers stored as two digits per byte, which is 20.4% overhead not 50%. But those instructions don't give you a decimal datatype just like integer instructions aren't floating point. In the end performance matters and it depends on the hardware. And I don't know of any architecture where decimal performs better than floating point.
Jan 27, 2019 22:26
@Raffzahn Not sure where you get the 50% storage overhead from. log(16)/log(10) is only 1.2041. And if you are a just a little bit creative about storage then log(1024)/log(1000) is only 1.0034. In the end the performance of each will depend on what features the hardware has to help you. And the question is about the choice of representation on a specific CPU, and there is likely an inherent difference in their performance on that CPU.
Jan 27, 2019 22:26
Wasn't floating point faster than a decimal datatype back then just as it is today? In that case it's not really surprising that they chose floating point. Neither datatype can accurately represent rational numbers, and the few use cases which care about exact representation of decimal values and not about exact representation of other rational numbers just aren't common enough to justify the slowdown.
 
Jan 22, 2019 11:25
But the difference between routing table entries with and without gateway is just how they do neighbor discovery. As such both kinds will behave identically on interfaces where the kernel doesn't do neighbor discovery in the first place.
Jan 22, 2019 11:24
Routing table entries can be local to the link or have a next-hop/gateway specified.
Jan 22, 2019 11:24
When I have written software using a tun interface my software has itself configured the interface after creating it. Sometimes I have just needed to configure a link prefix on the tun interface. Other times I have needed to add one or more routing table entries pointing to that interface (on at least one occasion I just needed a default route).
Jan 22, 2019 11:21
But I haven't yet had a need for that myself.
Jan 22, 2019 11:20
I can see how router solicitations and router advertisements would still make sense on tun and point-to-point interfaces.
Jan 22, 2019 11:19
As for router advertisements on such an interface, I haven't actually given that much thought.
Jan 22, 2019 11:19
And for that reason I wouldn't expect anything to show up in the neighbor cache for such interfaces, which matches your observations.
Jan 22, 2019 11:18
@WoodyWu Neighbor solicitation is never needed on tun interfaces or on other interfaces which the kernel sees as point-to-point interfaces.
Jan 22, 2019 11:16
@WoodyWu Even if there was some way to get the kernel to send neighbor solicitations on a TUN interface (which I don't think there is), those neighbor solicitations would serve no purpose. Nothing the kernel is going to do with the packets on a TUN interface depends on the neighbor advertisements, which is why the kernel doesn't send neighbor solicitations in the first place. If the protocol layer implemented by your code depends on the neighbor advertisements, your code should be generating the neighbor solicitations.
Jan 22, 2019 11:16
@WoodyWu If you use a TUN interface the kernel will hand over all packets destined for that interface to your code. If the underlying protocol you are implementing in your code isn't a point-to-point protocol and needs additional information to route the packets you always have the option to implement that part of the routing in your own code. Whether to use TUN or TAP depends on the protocol you need to implement, and I don't know enough about the specific protocol you are implementing to answer that question. Does that layer use MAC addresses?
Jan 22, 2019 11:16
@RonMaupin In that case I am not sure what your question is.
Jan 22, 2019 11:16
@RonMaupin TAP is intended to be pretty much exactly like Ethernet. It's similar enough that bridging between TAP and physical Ethernet should work. You could use the TAP interface to implement an Ethernet VPN and on each end bridge it to a physical interface such that you could make a single Ethernet segment span different locations far apart. And to the rest of the network the only giveaway that it isn't a direct connection is the higher latency. TUN is nothing like Ethernet. It is either plain IP packets or IP packets with an extra 4 byte header consisting of flags and a protocol field.
 
Jan 16, 2019 19:45
@Nzall What you are saying is mostly correct. But at least according to Wikipedia you can both find non-compliant products with a CE mark and compliant products with a misprinted version of the CE mark. So one shouldn't rely on the typography of the mark as a signal on whether the product is compliant.
Jan 16, 2019 19:45
It looks like something intended to be sold in a country with a compatible socket (such as Germany) for tourists who forgot to bring a real travel adapter when visiting that country. And if that's the case then the for export only label is the worst excuse ever.
Jan 16, 2019 19:45
It's funny that this is marked as a travel adapter as it's not even very usable for travel. Notice how it's designed to work with lots of different equipment but only in very specific sockets. Looks like it's designed to work in German sockets. It will probably work in Danish sockets but not provide ground connection. It might work in French sockets. But the legs are not thin enough for a Swiss socket. And I don't think you'd get it into a British socket even with a considerable amount of force.
 
Jan 13, 2019 14:50
Ok. I have given you all the information I can. If you want to try out those workarounds you are welcome to do so. The workarounds should work on this VPS, but they will still only be workarounds. My recommendation is to use a provider who will give you an actual routed /60 or shorter. Personally I'd rather pay for a proper solution than having to rely on these workarounds.
Jan 13, 2019 14:45
But if you try to use a single tunnel and have that single tunnel serve a few devices on a LAN, then you'll probably be relying on SLAAC.
Jan 13, 2019 14:44
That is you can have a large number of devices with a tunnel each.
Jan 13, 2019 14:44
Notice that it might only work if each device run their own tunnel.
Jan 13, 2019 14:43
So, it's a workaround. It will mostly work. But it doesn't support everything. And it can break at any time if the provider change their configuration. If that's all fine with you, then you can move ahead.
Jan 13, 2019 14:41
And it worked great until they turned on ND snooping without any warning.
Jan 13, 2019 14:41
I have used the same workaround myself on VPS at Hetzner.
Jan 13, 2019 14:41
But be aware that it will break if the provider turns on ND snooping.
Jan 13, 2019 14:41
If you do all of that, then it will work.
Jan 13, 2019 14:40
And to work around that you need to use a daemon which can respond to neighbor discovery.
Jan 13, 2019 14:40
It explains how to split the range in half. But would require the provider to make the same change on their end to make the upper half be a routed prefix rather than a link prefix.