1

I am writing a C# app to communicate with my wireless card using netlink protocol (via libnl library), in Linux.

Basically I am mimicking iw's functionality. At this initial state, I want to make sure the initial ported calls results are the same as when debugging the real linux app.

They are - except for the result I get for acquiring a socket file descriptor, using nl_socket_get_fd. Debugging the app always return a file descriptor valued 3, while my c# app extern call to nl_socket_get_fd always return 26 (even after system boots).

I remember from a while back I tried to do the same - but mimicking iwlist instead (before noticing it is now deprecated). Debugging also always returned 3 (eventually calling libc's socket function), while debugging my C# port always returned 19.

Socket's man page says

socket() creates an endpoint for communication and returns a file descriptor that refers to that endpoint. The file descriptor returned by a successful call will be the lowest-numbered file descriptor not currently open for the process.

I understand a file descriptor is "randomly" assigned, just found it suspicious that it always return the same number when running in this or that way.

Is this something to worry about ? Does this indicate my ported code is already not working as expected and moving on will end up creating unexpected results ?

Veverke
  • 9,208
  • 4
  • 51
  • 95
  • 1
    It says it will return the lowest number that's not already used. So, probably, 0 1 and 2 are used when iw is running, and a bunch more are used when C# is running (e.g. to load C# libraries)... – user253751 Oct 19 '21 at 11:34
  • So I guess it is correct to say that assuming my system boots with the same N processes every time, if I always debug without opening any additional programs I should always get the same file descriptor - and - debugging the real app vs my ported app - will never return the same file descriptors ? – Veverke Oct 19 '21 at 11:52
  • 1
    It is not about other processes, it is about the number of file descriptors opened by your process. – user253751 Oct 19 '21 at 11:59
  • I am trying to elaborate a "deterministic" statement about the nature file descriptor are assigned. Right, not related to opened processes rather the amount of file descriptors opened (by existing processes). So, rephrasing: it seems safe to assume that the number of file descriptors opened at any given time after booting my system, without starting any additional programs - is supposed to be constant (this may not be true for **any** given time, likely there are operations here and there that may change this, but sounds correct generally theoretically ? – Veverke Oct 19 '21 at 12:05

1 Answers1

1

The documentation says:

The file descriptor returned by a successful call will be the lowest-numbered file descriptor not currently open for the process.

So if your process has open file descriptors 0, 1, and 2, but not 3, it will return 3.

If your process has open file descriptors 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, and 25, but not 26, it will return 26.

This is how file descriptors are usually assigned in Linux.

user253751
  • 57,427
  • 7
  • 48
  • 90
  • And if file descriptor 25 is freed later on, that's the next one going to be assigned, despite 26 already being in use. – Veverke Oct 19 '21 at 12:11
  • @Veverke Yes. If 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, and 24 are open, but not 25, it will return 25. – user253751 Oct 19 '21 at 12:12
  • No, I meant - if 1,2,3 are opened - and nothing more, and later on 2 is freed. The next file descriptor going to be assigned is 2, and not 4. Just for completeness (and to make sure my understanding is correct) – Veverke Oct 19 '21 at 12:13
  • @Veverke Yes. Because 0 and 1 are open but not 2, it will return 2 <- I did not say anything about 3. 3 is irrelevant – user253751 Oct 19 '21 at 12:15
  • By the way - could you not have made the list of descriptors smaller for the sake of the example, instead of 1-26 ? :-) – Veverke Oct 19 '21 at 12:16
  • You are right, I can remove my "clarification" remark, because it does not add to your answer. – Veverke Oct 19 '21 at 12:18
  • @Veverke you first mentioned 26 – user253751 Oct 19 '21 at 12:18
  • Ah, I see where you took 26 from and why you went the trouble of going over 1-26. Thanks ! – Veverke Oct 19 '21 at 12:21