When using scapy, how can I set a tcp packet with flow control window bigger than 65535?
I know that writing in scapy:
packet1[TCP].window=65535
will set the window to 65535; But if there is a need to set windows size bigger then 65535, it should be set in a different way because at the tcp header the window field is just two bytes so it can't be greather than 65535 so it should be done in another way. I know it should be possible.
Thanks.
Sort answer is: you cannot set the field TCP.window to a bigger value than 65535, since it is coded on two bytes:
>>> ls(TCP)
[...]
window : ShortField = (8192)
[...]
But TCP window can be higher than 65535, using the "Window Scale" option. The window value is the value of the window field multiplied by 2 raised to the power of the window scale value.
In Scapy:
>>> IP()/TCP(window=65535, options=[('WScale', 10)])
The value is 65535 * 2 ** 10, 67107840.
Related
I am experiencing conflicts between xcos blocks. For example I am not able to connect a real [-2 1] output to a real [1 1] input.
Does anybody know, in general, what negative indices mean for datatype size?
This is explained # https://help.scilab.org/docs/6.1.0/en_US/scicos_model.html :
in
A vector specifying the number and size of the first dimension of regular input ports indexed from top to bottom of the block. If no input port exist in==[]. The size can be negative, equal to zero or positive :
If a size is less than zero, the compiler will try to find the appropriate size.
If a size is equal to zero, the compiler will affect this dimension by added all positive size
found in that vector
If a size is greater than zero, then the size is explicitly given.
I am upgrading an existing retailer software to print a QR code on an EPSON TM 88 V using MS Pos for .Net 1.14.
The PrintBarcode function is straightforward to use for one dimensional barcode, like the Code93, and its size can be adjusted with the width and height parameters.
public abstract void PrintBarCode(PrinterStation station, string data, BarCodeSymbology symbology, int height, int width, int alignment, BarCodeTextPosition textPosition);
However, BarCodeSymbology QRCode (204) size does not seem to be adjustable with these height and width parameters.. The barcode prints fine, but is very tiny (about 5 mm width and height), regardless of the parameters value.
How can I adjust the size of the printed QR code?
The documentation for OPOS(EPSON OPOS ADK) rather than POS for.NET(EPSON OPOS ADK for.NET) has the following instructions:
Probably the same notes apply to POS for.NET.
Please try adjusting the Width parameter value to get the desired size.
3.6.2 Printing Size
Because the width and length of QR CODE are the same, printing is done to the inner part at a size closest to it by using the value specified by the Width parameter.
Therefore, the height of print is not affected by the Height parameter.
If the Height parameter is less than 0, an error occurs.
The print size is determined by the version of QR and the size of the module.
Because the version of QR is determined by the data length and type, you can use the size of the module to adjust the print size. If the two dimensional barcode cannot fit into the print area (depending on the paper width, layout settings, etc.) then OPOS_E_ILLEGAL is returned and at this moment ResultCodeExtended becomes zero.
For QR, it differs from other two dimensional barcodes; if the encoded data result is not known, then the print width cannot be obtained.
If the print width cannot be obtained, the page mode range for 90-degree rotated printing cannot be specified.
Therefore, within OPOS it calculates the number of code words of the encoded data.
Because of this reason, data amount can be correctly verified.
And here is a similar Japanese FAQ.
QR コードを印刷する方法＜EPSON OPOS ADK シリーズ＞
It depends on the amount of text of the data you want to print.
If it is a string like "www.microsoft,com" or "012345678" it will be a small QR printed.
When you extend the length of the data being sent to the printer, you will see the difference.
As you know that ssd should be partitioned ensuring 4k alignment, because the writes may be amplified if not 4k aligned.
But I wonder if the side-effect of non-4k alignment will decrease if the write block size is becoming larger.
For example, if the write size is 4k each time, it will be amplified to actually 2 blocks. But if the write size is 128k each time, then is it related only to 128/4 + 1 = 33 blocks?
The issue only arises on the first part and possibly the last part of the write, where you are writing partial blocks. For example, if you're up to position 2048 and you write 8k, you have to write 2048 non-aligned bytes at the start, one fully aligned bloxk, and another 2048 bytes at the end. If you wrote 16k instead it would be the same 2048 issue at the start, more aligned blocks, and the same 2048 issue at the end.
I have defined multiple constraints with Greater Than or Equal and Less Than or Equal. How does iOS decide which view will change its size when the superview changed its size?
Let's assume I have one view with constraints Greater Than 10 and Less Than 20.
And I got a second view with the constraints Greater Than 40 and Less Than 60.
Now the superview changes its size and the available space will increase by 10 pixel. I need a way to define which constraint is allowed to resize first (and take the 10pixel).
NSLayoutConstraint's priorities tell iOS & OS X which constraints to satisfy first.
If you have a view viewOne that you'd like to expand first, apply a constraint with visual format #"H:[viewOne(==9999#499)]". That will tell iOS that, after the required constraints 10≤viewOne≤20 & 40≤viewTwo≤60 are met, it should attempt to make viewOne 9,999 pixels wide, causing it to expand before viewTwo.
If you don't want to store the magic number 9999,
NSNumber* maxWidthForViewOne = #(20) ;
NSLayoutConstraint* constraint = [NSLayoutConstraint constraintsWithVisualFormat:#"H:[viewOne(==asBigAsPossible#499)]" options:0 metrics:#{#"asBigAsPossible":maxWidthForViewOne} views:views] [0] ;
I tested these in OS X, and I found that 499 (NSLayoutPriorityWindowSizeStayPut - 1) was the highest priority that allowed me to shrink viewOne by resizing the window. Since you're using iOS, you'll want to test what priority behaves as you like.
I have my own video source and using VMR7. When I use 24 color depth, my graph contains Color Space Converter filter which converts 24 bits to ARGB32. Everything works fine. When I use 32 bit color depth, my image looks desintegrated. In this case my source produces RGB32 images and passes them directly to VMR7 without color conversion. During window sizing I noticed that when destination height is changing the image becomes "integrated" (normal) in some specific value of destination height. I do not know where is the problem. Here are the example photos: http://talbot.szm.com/desintegrated.jpg and http://talbot.szm.com/integrated.jpg
Thank you for your help.
You need to check for a MediaType change in your FillBuffer method.
HRESULT hr = pSample->GetMediaType((AM_MEDIA_TYPE**)&pmt);
if (S_OK == hr)
{
SetMediaType(pmt);
DeleteMediaType(pmt);
}
Depending on your graphic you get different width for your buffer. This means, you connect with an image width of 1000 pixels but with the first sample you get a new width for your buffer. In my example it was 1024px.
Now you have the new image size in the BitmapInfoHeader.biWidth and got the old size in the VideoInfoHeader.rcSource. So one line of your image has a size of 1024 pixels and not 1000 pixels. If you don't remember this you can sometimes get pictures like you.