|
Bugzilla – Full Text Bug Listing |
| Summary: | No reason why PacketSocket::SendTo cannot work in STATE_OPEN state. | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Gustavo J. A. M. Carneiro <gjcarneiro> |
| Component: | network | Assignee: | ns-bugs <ns-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Version: | pre-release | ||
| Hardware: | All | ||
| OS: | All | ||
OK with me to align with Linux (In reply to comment #1) > OK with me to align with Linux I think that this is a dangerous statement when it gets to packet sockets because it is pretty much impossible to be _exactly_ like linux in that case: the details of packet sockets are very tightly bound to the OS which is why they are so different from one OS to the other and why the linux manpage is so useless: you always end up reading the linux code to figure out what the semantics are. There is no real standard when it gets to packet sockets: they all behave slightly differently. So, the cost of being _exactly_ like linux is going to be pretty high. Instead, we should focus on having something which is relatively simple to implement and is carefully documented. To summarize, I am ok to remove that limitation if it does not complexify the code and if it _really_ matches the linux implementation better. But, that is going to be a lot of work, and I have a hard time seeing that work as useful given the already existing wide variance in packet socket implementations. Point well taken that saying "align with Linux" is imprecise and not necessarily the goal in all cases. But do you see an impact of removing the check? Keep in mind that PacketSocket _is_ Linux specific. Probably BSD It makes perfect sense to align with Linux because it contains the only other known implementation. Sorry, hit commit too soon. "Probably BSD.." is a half written sentence. I was going to say, Probably BSD also has an equivalent to packet socket, but it is called something else. Packet sockets are not POSIX or otherwise standardized. In this case, the implementation behaviour _is_ the standard. Yes, but there are a variety of ways to do this (bpf, dlpi, libnet, PF_PACKET). OTOH, I agree with you that there is no real reason to diverge from Linux unnecessarily. (In reply to comment #6) > Yes, but there are a variety of ways to do this (bpf, dlpi, libnet, PF_PACKET). > OTOH, I agree with you that there is no real reason to diverge from Linux > unnecessarily. > (In reply to comment #3) > Point well taken that saying "align with Linux" is imprecise and not > necessarily the goal in all cases. But do you see an impact of removing the > check? My imprecise feeling is that trying to align with linux should not be done half way, that is, if we really want to align, we really should review the whole implementation and match it against the linux one, not randomly patch it whenever we find something which is different. Otherwise, we will get something which is just arbitrarily slightly different from linux which I have a hard time seeing as much better than "arbitrarily very different" from the point of view of a user. So, I don't mind this specific change if someone actually spends the time needed to review the whole implementation against the linux one: the reason why I am a bit anal about this is that I suspect that I had pretty good reasons to do this but I can't remember which. Also, the documentation should be updated to very clearly state that the goal is to _match_ the linux implementation. bumping to P1 (changes socket behavior) |
The following code in PacketSocket::SendTo makes no sense to me: if (m_state == STATE_OPEN) { // XXX should return another error here. NS_LOG_LOGIC ("ERROR_INVAL"); m_errno = ERROR_INVAL; return -1; } In linux packet sockets I can send L2 packets without having to bind() or connect() first. OK to remove that limitation?