AVR GCC odd (dangerous?) behaviour?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I've been using WinAVR for about a week now and really enjoying it as a refreshing change from some of the more advanced micros I usually work with.

Then all of a sudden, part way through a 'make' of my project my Sygate Personall Firewall popped up to say:

File Description :	C:\WinAVR\libexec\gcc\avr\3.4.3\cc1.exe
File Path :		C:\WinAVR\libexec\gcc\avr\3.4.3\cc1.exe
Process ID :		0xBDC (Heximal) 3036 (Decimal)

Connection origin :	local initiated
Protocol :		Raw Ethernet
Local Address : 	0.0.0.0
Local Port :		0 
Remote Name :			
Remote Address :	0.0.0.0
Remote Port : 		0 

Ethernet packet details:
Ethernet II (Packet Length: 56)
	Destination: 	ff-ff-ff-ff-ff-ff
	Source: 	00-03-47-d3-f2-03
Type: ARP (0x0806)
Address Resolution Protocol (ARP)
	Hardware type: Ethernet (0x0001)
	Protocol type: IP (0x0800)
	Hardware size: 6
	Protocol size: 4
	Opcode: Request
	Sender hardware address: 00-03-47-d3-f2-03
	Sender IP address: 192.9.200.221
	Target hardware address: 00-00-00-00-00-00
	Target IP address: 192.9.200.71

Binary dump of the packet:
0000:  FF FF FF FF FF FF 00 03 : 47 D3 F2 03 08 06 00 01 | ........G.......
0010:  08 00 06 04 00 01 00 03 : 47 D3 F2 03 C0 09 C8 DD | ........G.......
0020:  00 00 00 00 00 00 C0 09 : C8 47 05 04 88 03 50 18 | .........G....P.
0030:  FE 4F F6 DB 00 00 00 00 :                         | .O......        

So cc1.exe is trying to send an ARP packet onto our network ?!?!?

W! T! F! ???

Does anyone have ANY idea what this compiler might be doing sending network packets??

I got my WinAVR (the latest, about a week ago) from the main Souceforge site via the Luasanne, Switzerland mirror (I always use that for SF files cos it's better bandwidth than most other European SF sites)

Cliff ("the concerned!")

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The compiler is very certainly not sending out any network traffic by
itself.

What do the IP addresses mentioned there tell you (besides being
old-fashioned private addresses outside the RFC 1918 range)?

Perhaps you've got some network share active, and the compiler is
accessing them? There's that known issue where the compiler
``remembers'' the CP/M^H^H^H^HWindows drive name it has been built on
(used to be E:, IMHO it's now M:), and tries to access that ``drive''
occasionally (as it's obviously internally configured into some search
path).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

Last Edited: Fri. Jul 22, 2005 - 12:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Source IP (.221) is my private network address, the destination (.71) is one of our Linux dev servers but the fact is that this project has nothing to do with that machine and there's no reason why anything to do with it would involve a Samba share on that machine. Everything to do with this AVR development has all been done on my local C: thouhg it's true that I have a couple of CP/M^H^H^H^HWindows drives mapped to the .71 machine (my U: and V:) so maybe the compiler has some reference to U: or V: built in but it wouldn't be making ARP requests because of this - if it tried to access a net drive that'd all be handled by Windows-Samba anyway wouldn't it?

Oh well, I'm hopeful the Sygate firewall I run on my PC will prevent it doing anything "naughty" anyway.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> thouhg it's true that I have a couple of CP/M^H^H^H^HWindows drives
> mapped to the .71 machine (my U: and V:) so maybe the compiler has
> some reference to U: or V: built in but it wouldn't be making ARP
> requests because of this - if it tried to access a net drive that'd
> all be handled by Windows-Samba anyway wouldn't it?

My guess is that whatever that `Firewall' is seeing is the compiler
process that the lower network layers are sending the ARP request on
behalf of when the compiler attempts to access the drives.

Just unmap those drives, and see if it disappears.

Don't ask me why these access attempts happen, I'm not a Windows guy.
Speculations are that somehow the libraries GCC is compiled upon on
Windows (might be Cygwin, I'm not sure) cause that access to seemingly
unrelated drives. You can be very sure that GCC is not causing
``foreign drive access'' on its own as it is a Unix application that
has not even a remote idea what a windows drive might be.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope, my worry was that the avr-gcc (or rather cc1.exe) that I had installed might be a trojan that someone had "hacked" but hopefully it's nothing serious. It just seemed odd that after several hundred invocations of the compiler it chose this occasion to do something with the network which I wasn't expecting.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI, GCC is a bit strange in that when the source code is compiled, it wants a path where it will be installed, and this install path is hard coded in the software. This make it terribly annoying when the software is then "relocated", i.e. by distributing the binaries and people install it on other paths. AVR GCC will then always look in this hard coded install directory to find various other programs it needs for the compiler before looking in other directories (such as the current directory, the PATH, etc.) The AVR GCC program in WinAVR used to be built to install on the E:\ drive, however, this conflicted with a lot of people's removable media (CD drives, USB drives, PCMCIA drives, etc.). So, the latest version was built and installed to M:\ in the hopes that this would help reduce conflicts. But there have been reports from users that they have conflicts with the M:\ drive. So, this is a known issue, a GCC bug report (feature request) has been filed to disable this automatic search on the install drive, but nothing has been done about it to my knowledge. Eventually this issue has to get fixed. In the meanwhile, my apologies for any hassle.

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the explanation - curiously I have A:, C:, D:, E:, N:, O:, P:, Q:, S:, U: and V: in use but no sign of M: - however I'll just assume that it was trying to access M: and the packet I saw was a side effect of the network looking for "M:".

Cliff