short driver from Linux Device Drivers book - linux-device-driver

I am trying to run short from Linux Device Drivers book, a driver which uses by default the parallel interface of a pc at io address base 0x378. I am specifically using the /dev/short0 device.
Quoting from the book
/dev/short0 writes to and reads from the 8-bit port
located at the I/O address base (0x378 unless changed at load time).
The write operation (on default behavior) essentially does that
while (count--) {
outb(*(ptr++), port);
wmb( );
}
The ptr variable holds a pointer to the data the user has requested to be written to the device. Only the last byte of course survives, as preceding bytes get overwritten. The read operation works similarly, by using inb instead of outb.
Quoting also from the book
If you choose to read from an output
port, you most likely get back the last value written to the port (this applies to the parallel interface and to most other digital I/O circuits in common use)
So when i do
$ echo -n "a" > /dev/short0
$ dd if=/dev/short0 bs=1 count=1 | od -t x1
as suggested in the book, i expect to get back the ascii code for 'a' in hex, but what i get is 0xff:
1+0 records in
1+0 records out
1 byte (1 B) copied, 0,000155485 s, 6,4 kB/s
0000000 ff
0000001
I have verified, adding some printks and using dmesg, that the relevant code of the driver actually gets executed and beyond that, i' m stuck. What are some possible reasons for this not working? Or where should i look next to find out why it is not working?
For what it matters, the io address range 0x378-0x37a is initially allocated from the parport module, so i rmmod it along with a few other modules that use parport before i load the short module. Finally, on my system uname -a gives
Linux Crete 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:31:42 UTC 2014 i686 i686 i686 GNU/Linux

Related

Memory leak (?) using IO::Socket::Async (on FreeBSD 13.1)

In processing a stream of logs (via UDP) in a raku (v2022.07) app, I'm
hitting what appears to be a memory leak using IO::Socket::Async.
I pulled the code out into a simpler program which I've included below
(~ identical to code at https://docs.raku.org/type/IO::Socket::Async):
#!/usr/bin/env raku
#
my $socket = IO::Socket::Async.bind-udp('localhost', 24225);
react {
whenever $socket.Supply -> $v {
print $v if $v.chars > 0;
};
};
It leaks substantial ram - I let it run about 12 hours and
when I checked -- still running (on a 1T ram machine) -- with
ps auwwx [pid]
it showed 314974456 and 20739784 for VSZ and RSS (so, roughly 300G v size and 20G resident).
[btw, the UDP traffic is fairly light - average of 350 (~100 byte) packets/sec (spikes to ~1000/sec)]
So .. I rewrote above in perl5 (after similar leaky results w/
a couple of raku variants) which stabilizes quickly at about 8M resident - that's fine/stable/etc. -
but I'd prefer this process to feed a raku channel (without separate perl process/file
tailing, etc.).
My environment: FreeBSD 13.1-RELEASE-p2 GENERIC amd64 and raku:
v2022.07 built on MoarVM 2022.07 (installed with rakubrew).
I'm guessing this is unique to raku on freebsd but not sure.
I did attempt to upgrade (rakubrew) to v2022.12 to see if problem resolved there -
but in rebuilding modules (zef), too many failed (some issue with
Digest/Digest::HMAC) - so I had to revert to 2022.07.
I'll sure be grateful for any suggestions for addressing the leak or alternative
methods to address reading from a UDP port.
Not exactly a solution to your problem, but you can monitor memory usage from within your Raku code using built-in feature:
use Telemetry;
say T{"max-rss"};
Also remember that Supply by default decodes unicode chars. If your protocol is binary you may add :bin to Socket params to avoid treating binary data as text.

how can I make large number of connections without error at client side

I have written a program in golang to make request about 2000qps to different remote ip with local port randomly selected by linux, and close request immediately after connection established, but still encounter bind: address already in use error periodically
what I have done:
net.ipv4.ip_local_port_range is 15000-65535
net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_fin_timeout=30
above is sockstat:
sockets: used 1200 TCP: inuse 2302 orphan 1603 tw 40940 alloc 2325 mem 201
I don't figure it out why this error still there with kernel selecting available local port,will kernel return a port in use ?
This is a good answer from 2012:
https://serverfault.com/questions/342741/what-are-the-ramifications-of-setting-tcp-tw-recycle-reuse-to-1#434669
As of 2018, tcp_tw_recycle exists only in the sysctl binary, is otherwise gone from the kernel:
https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=tcp_tw_recycle&type=
tcp_tw_reuse is still in use as described in the above answer:
https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_ipv4.c#L128
However, while a TCP_TIMEWAIT_LEN is in use:
https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=TCP_TIMEWAIT_LEN&type=
the value is hardcoded:
https://github.com/torvalds/linux/blob/master/include/net/tcp.h#L120
and tcp_fin_timeout refers to a different state:
https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt#L294
One can relatively safely change the local port range to 1025-65535.
For kicks, if there were a situation where this client was talking to servers and network under my control, I would build a new kernel with a not-to-spec TCP_TIMEWAIT_LEN, and perhaps also fiddle with tcp_max_tw_buckets:
https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt#L379
But doing so in other circumstances- if this client is behind a NAT and talking to common public servers- will likely be disruptive.

Can't use CAIDA Dataset with tcpreplay to simulate network traffic in network

I have a server and I need to simulate real network traffic. I've been asked to do this using a CAIDA Dataset. I have downloaded the public Dataset which can be found here:
CAIDA Public Dataset
I also need to rewrite the source ip address in the .pcap file to be the one of the server. I tried doing it the way it's described at the end of this page: tcprewrite wiki
I run:
tcprewrite --infile=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --outfile=oc48-mfn.dirA.20020814-160000.UTC.anon_rewrite.pcap --dstipmap=0.0.0.0/0:10.101.30.60 --enet-dmac=00:0c:29:00:b1:bd
And I get:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
Fatal Error: From ./plugins/dlt_hdlc/hdlc.c:dlt_hdlc_encode() line 255:
Non-HDLC packet requires --hdlc-address
So after some tries like this I finally run these to get an error free tcprewrite:
tcpprep --auto=bridge --pcap=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --cachefile=cache1.cache
Which gives:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
And then I run:
tcprewrite --infile=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --outfile=oc48-mfn.dirA.20020814-160000.UTC.anon_rewrite.pcap --dstipmap=0.0.0.0/0:10.101.30.60 --enet-dmac=00:0c:29:00:b1:bd --cachefile=cache1.cache --hdlc-control=0 --hdlc-address=0xBF
And I get:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
So it seems like a success, except the warning that shows up in every command.
I open the new .pcap file with tcpdump to check that the destination IP addresses have changed to the one of the server and it has been done.
So then I run tcpreplay:
tcpreplay -i ens160 --loop 5 --unique-ip oc48-mfn.dirA.20020814-160000.UTC.anon.pcap
And I run tcpdump on the server to see the traffic from the .pcap file, but the traffic looks like this:
13:30:50.194780 05:8c:55:6f:40:00 (oui Unknown) > 0f:00:08:00:45:00 (oui
Unknown), ethertype Unknown (0x3406), length 60:
0x0000: ed11 f484 7785 f477 0d79 0050 0487 007c ....w..w.y.P...|
0x0010: e7d5 d203 c32b 5010 27f7 aa51 0000 4854 .....+P.'..Q..HT
0x0020: 5450 0000 0000 0000 0000 0000 0000 TP............
I have tried the smallFlow.pcap from the sample captures of tcpreplay: Sample Captures
and it worked just fine.
So any suggestions on how to properly use the CAIDA .pcap files?
Your stated goal is "I need to simulate real network traffic", but you're using pcaps where "the payload has been removed from all packets" (per the CAIDA web page you linked to).
These two statements are in conflict with each other. All your packets are literally no larger then 48bytes which is merely enough for the TCP/IP header (and then even so, may not be sufficient in all cases). This is what the warning is telling you. You can't put the data back.
You'll need to find a new source of pcaps.

Solaris svcs command shows wrong status

I have freshly installed an application on solaris 5.10 . When checked through ps -ef | grep hyperic | grep agent, process are up and running . When checked the status through svcs hyperic-agent command, the output shows that the agent is in maintenance mode . Application is working fine and I dont have any issues with the application . Please help
There are several reasons that lead to that behavior:
Starter (start/exec property of service) returned status that is different from SMF_EXIT_OK (zero). Than you may check logs:
# svcs -x ssh
...
See: /var/svc/log/network-ssh:default.log
If you check logs, you may see following messages that means, starter script failed or incorrectly written:
[ Aug 11 18:40:30 Method "start" exited with status 96 ]
Another reason for such behavior is that service faults during while its working (i.e. one of processes coredumps or receives kill signal or all processes exits) as described here: https://blogs.oracle.com/lianep/entry/smf_5_fault_retry_models
The actual system that provides SMF facilities for monitoring that is System Contracts. You may determine contract ID of online service with svcs -v (field CTID):
# svcs -vp svc:/network/smtp:sendmail
STATE NSTATE STIME CTID FMRI
online - Apr_14 68 svc:/network/smtp:sendmail
Apr_14 1679 sendmail
Apr_14 1681 sendmail
Than watch events with ctwatch:
# ctwatch 68
CTID EVID CRIT ACK CTTYPE SUMMARY
68 28 crit no process contract empty
Than there are two options to handle that:
There is a real problem with service so it eventually faults. Than debug the application.
It is normal behavior of service, so you should edit and re-import your service manifest, to make SMF less paranoid. I.e. configure ignore_error and duration properties.

mscorjit overlaps mscoree when using windbg

Loading Dump File [C:\Crash_Mode__Date_12-05-2009__Time_15-54-2727\PID-4056__CCNET.EXE__1st_chance_Process_Shut_Down__full_13d0_2009-12-06_00-33-14-734_0fd8.dmp]
User Mini Dump File with Full Memory: Only application data is available
Comment: '1st_chance_Process_Shut_Down_exception_in_CCNET.EXE_running_on_TEST218'
Symbol search path is: srvE:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Version 3790 (Service Pack 2) MP (2 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Machine Name:
Debug session time: Sun Dec 6 00:33:14.000 2009 (GMT+8)
System Uptime: 32 days 12:43:52.414
Process Uptime: 0 days 8:44:37.000
..........................WARNING: mscorjit overlaps mscoree
..............................WARNING: wldap32 overlaps dnsapi
..........WARNING: rasapi32 overlaps dnsapi
...WARNING: tapi32 overlaps rasapi32
.WARNING: rtutils overlaps rasman
..............WARNING: setupapi overlaps winsta
....wow64cpu!CpupSyscallStub+0x9:
00000000`78b842d9 c3 ret
why this happen?
Not related to CLR, instead it's 32-on-64 as described here http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/ -- in short use the following:
.load wow64exts
.effmach x86
With those, kb and !analyze -v will give better results.
I hadve seen the same thing latly, I do not know for sure but it's probably some WOW64 artifact or possibly due to some more aggressive anti-exploitation techniques. At leat on Win32, even though the load address of a DLL may be different on occasion, if a DLL is mapped in antother process (like ntdll/kernel32) when your process start's if it is statically linking these DLL's also, it would always load at the same address until the next reboot.
It seems probable that more recent CLR exe's are able to remap various module's per-execution, I know that this is an issue on MSVC10 and Windows7 but perhaps it's been ported to additonal platforms for CLR applications.