Socket options can be set using setsockopt() function.
The corresponding options are present in the below link:
https://linux.die.net/man/3/setsockopt
Does this API allow to set the dscp value for the socket?
I don't find any such option in above link.
Most socket options are defined in other manual pages -- generally in section 7.
See the ip(7) man page https://linux.die.net/man/7/ip -- you would use IPPROTO_IP/IP_TOS in the setsockopt.
Also, that page references a "protocol-independent" way from socket(7) https://linux.die.net/man/7/socket (SOL_SOCKET/SO_PRIORITY).
Not sure there is anything to recommend one over the other -- it's unlikely you'll be using an underlying protocol that isn't IP.
I had a hard time finding out how to do this, until I finally stumbled upon this page.
For IPv4, you need to use IPPROTO_IP/IP_TOS, and for IPv6 you need to use IPPROTO_IPV6/IPV6_TCLASS. You also need to pass in the DSCP value bit shifted to the left 2 places, since DSCP is a 6 bit field, but IP_TOS and IPV6_TCLASS are 8 bit fields.
Related
I recently renamed all of the URLs that make up my blog... and have written redirects for almost every page... using wildcards where I can... keeping in mind... all that I know is the * wildcard at this time...
Here is an example of what I have...
/season-1/2017/1/1/snl-s01e01-host-george-carlin -> /season-1/snl-s01e01-george-carlin 301
I want to write a catch-all that will redirect all 38 seasons of reviews with one redirect entry... but I can't figure out how to get rid of just the word "host" between s01e01- and -george-carlin... and was thinking it would work something like this...
/season-*/*/*/*/snl-s*e*-host-*-* -> /season-*/snl-s*e*[code to remove the word "host"]-*-* 301
Is that even close to being correct? Do I need that many *s
Thanks in advance for any help...
Unfortunately, you won't be able to reduce the number of individual redirect entries using the redirect features that Squarespace has to offer, namely the wildcard (*) and a single variable ([name]). Multiple variables would be needed, but only [name] is supported.
The closest you can get is:
/season-1/*/*/*/snl-s01e01-host-[name] -> /season-1/snl-s01e01-[name] 301
But, if I'm understanding things, while the above redirect appears more general, it would still need to be copy/pasted for each post individually. So although it demonstrates the best that could be achieved, it is not a technical improvement.
Therefore, there are only two alternatives:
Create a Google Sheet (or other spreadsheet) where the old URLs are copy/pasted in column one, a formula using arrayformula and regular expressions to parse the old URL and generate the new URL is added in column two, and in column three a formula is written to join the two cells with -> and 301. With that done, you could click, drag and highlight all cells in column 3, copy, and paste them in the "URL Shortcuts" text area in Squarespace.It can be quite time consuming to figure out, write and test the correct formula, but it does avoid having to manually type out every redirect. Whether it is less time/effort in total depends on the number of redirects and one's proficiency with writing spreadsheet formulas.It could be that using the redirect code above would simplify the formula that'd need to be written in the spreadsheet, which may save some time.
Another alternative would be to remove your redirects and instead handle the redirect via JavaScript added to the 404/Page-not-found page. Because it sounds like you already have all of the redirects in place but are simply trying to reduce the overall number, I wouldn't recommend changing to a JavaScript-based approach. There are other drawbacks to using JavaScript, in any case.
I noticed that
(Get-NetIPConfiguration).InterfaceIndex
always seems to return the index's in interface binding order for me. is this the way its suppose to function, always returning in interface binding order or it is just a fluke that it always returns in interface binding order for me in this case?
You could try
(Get-NetIPConfiguration).InterfaceIndex | Sort [int]
ok, got this figured out. Starting with windows 10 the preferred IP Address enabled (either IPv4 or IPv6) interface is the one with the lowest sum of the IPv4 (or IPv4) route metric and the interface metric (route metric + if metric). This may not be the one with the default route 0.0.0.0/0 depending on if you have multiple interfaces set up or not with multiple default routes. That interface will bind to the one with the next lowest lowest sum on the same route ...and so forth and so on. This also, it turns out, may not be the order of the interface GUID's in the registry value at 'HKLM:\SYSTEM\Currentcontrolset\Services\TCPIP\Linkage\bind\
But...how they appear in a list, including other methods, is determined just by the interface metric. So in Windows 10 there is (i'm gonna call it) 'route binding order' and the list order. Although this may seem to match up sometimes because most people don't have multiple interfaces in their systems it becomes important if you are going to start playing around with setting interface and route metric to ensure the interface you want to be used is the one being used for a particular route. So you want the actual binding order and not the list order.
so, in windows 10, to get correct route binding order (vs list order) you have to examine the route table and do the 'math' for sum of route metric + interface metric to get actual binding order, and use that same 'sum' methodolgy to set up interfaces if you are going to do it yourself.
Below is an example of this method usage that i threw together quickly. I have one Windows 10 machine with two hardware interfaces, one for hard line connection and the other wifi. I also have OpenVPN with a TAP adapter installed on this system, so i need to know which hardware interface that OpenVPN was binding to through the TAP adapter. The TAP adapter is a virtual (software) interface. When the TAP is installed/connected it uses a interface metric less than 10 because windows minimum automatic interface metric is always no lower than 10 (although you can manually set it lower) , and the tap uses a route metric of 0. So the tap is going to be the lowest 'sum' Ip enabled interface in the system. So all this info and using the below code I got the hardware interface the Open/VPN/Tap is binding to (code thrown together quickly, will refine later when I have the time)..
$route = (Get-NetRoute); $rtmetric = $route.RouteMetric; $ifmetric = $route.InterfaceMetric; $index = $route.ifIndex;
$sumarray = #(); $indexarray = #(); For ($i=0; $i -lt $rtmetric.Length; $i++)
{
$sum = $rtmetric[$i] + $ifmetric[$i]
$sumarray += $sum
$indexarray += $index[$i]
}
$sumsort = $sumarray | sort -unique; [int]$sumlowest = ($sumsort | measure -Minimum).Minimum;
$pos = [Array]::indexof($sumsort,$sumlowest) + 1; $sumget = $sumsort[$pos]; $posA = [Array]::indexof($sumarray,$sumget); $ifindexbind = $indexarray[$posA];
(Get-NetAdapter | ? ifIndex -eq $ifindexbind)
so, that's the long way around it to get the route binding order vs the list order. If you do this:
(Get-NetAdapter).InstanceID
you will get the binding in list order as they are in the registry key starting from the bottom and working your way up. But.... if you do this
(Get-NetIPConfiguration).NetAdapter.InstanceID
you will notice that as interfaces are disabled or enable the order given will also change, and that's because '(Get-NetIPConfiguration).NetAdapter.InstanceID' is giving the route binding order and not the registry list order. Disabling an interface removes it from the route table but just disabling an interface does not remove its binding to another interface but the priority changes so the previously bound interface now becomes the preferred interface in the route so moves to the top. When that disabled interface with the binding to the enabled interface, is enabled again it takes it place in the route binding on top. The one on top will be the preferred adapter (the one with the lowest 'sum' value), the one under that will be the 'next prefered' (the one with the next lowest 'sum' value) and if on the same route is the interface bound to one above it, thus binding order. So using (Get-NetIPConfiguration).NetAdapter.InstanceID the needed route binding order for enabled and connected interfaces can be had without resorting to reading the registry.
I'm attempting to create a Suricata rule that will match a packet if and only if all content is found and in a specific order.
The problem with my current rule is that it will match even if the packet content is test2 test1.
Is there a way to achieve this functionality without using pcre?
alert tcp $HOME_NET any -> $EXTERNAL_NET [80,443] (msg:"Test Rule"; flow:established,to_server; content:"test1"; fast_pattern; content:"test2"; distance:0; classtype:web-application-activity; sid:5182976; rev:2;)
I figured out that the method I was using to test the Suricata signatures was duplicating the tested data at some point causing for the signature to always fire.
As to answer my own question, content order can be enforced by adding a distance modifier after the first content match.
As seen in:
content:"one"; content:"two"; distance:0; content:"three"; distance:0; . . .
As far as I can tell, the fast_pattern keyword can be omitted.
Is is possible to configure the sap.m.TimePicker to display only 15 minute intervals?
At the moment the user can enter any time they like.
It's possible now with version 1.40.+
There was incorrect information in the API documentation and it wasn't possible even on version 1.38
Change it to a DropDownBox with a value range of 00:00, 00:15, 00:30, ... 23:30, 23:45? This makes the limitation to specific intervals clear at a glance, is easy to implement and avoids entry of undesired values altogether.
While #vwegert 's answer is function I think there is a better way where you you still get the look and feel of the TimePicker.
In the source of the control there is a property minutesStep. If you can set this in the xml or js definition I think you could be onto a winner.
In fact there is a setter (yay) setMinutesStep.
oTimer.setMinutesStep(15); should be a winner for you.
Hope that helps,
Nigel
I am developing embedded firmware to communicate with the Multi-Tech's MTSMC-H5 GPRS Modem. I am unclear the use of AT+CGDCONT command. In the H5 modem's Reference Guide, it states the command format is
>AT+CGDCONT=[<cid>[,<PDP_type>[,<APN>[,<PDP_addr>[,<d_comp>
>[,<h_comp>[,<pd1>[,…[,pdN]]]]]]]]]
>...
><APN> Access Point Name. String parameter that is a logical name used to select the
>GGSN or the external packet data network. If the value is empty (“”) or omitted,
>3GPP TS 27.007 AT COMMANDS then the subscription value is requested.
>...
What effect would that be if I leave the APN field blank? It seems I can connect to the cell network while leaving the APN field blank. I tried several SIM cards and they all seem to work without specifying the APN field. However, I'd like to know for sure that what I do is appropriate. Because I have very limited UI capability (no real keypad on the device that the modem is attached to), it is highly desirable if an end user does not have to enter any APN information.
The APN was probably stored on the SIMs that you used. In most cases, it will be OK as you found out. There are a few edge cases where you might run into problems, such as an APN changing (rare), or arrangements between individual operators, or between operators and certain customers.
Even these cases can be mitigated by some operators as they automatically correct a wrong APN (APN redirection).
Note that this is not behaviour that is mandatory under the 3GPP standards, so it may vary from operator to operator.